Re: Mail Server Registries and Foreign Sender Authentication: A Proposal
"william(at)elan.net" <[email protected]> Wed, 28 Mar 2007 07:03:40 -0800 (PST)
| Newsgroups | gmane.ietf.mxcomp |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 28 Mar 2007, Randy Smith wrote: > The biggest problem, IMO, is not the open system but the anonymous > one. One reason spam works so well is that its so very easy to lie > about who the sender is. Hence we have SPF and proposals such as DKIM and others. > I don't think there's any reason why a mail > admin couldn't setup their own registration server but as the > recipient, I need to have some way of knowing that I can trust the > registry, hence the web of trust built around server keys. One of the issues is that SMTP is not fully client-server but rather store-forward protocol. When you communicate with someone over SMTP as a client you do not know if its true end-user or not. > What I'm thinking of would be an extension to SMTP rather than an > entirely new system. As the main admin for an ISP, the last thing I > want to do is build a second system to handle a new protocol that > hardly anyone uses (at least, until the rest of the Net migrated). SMTP is built in such a way that extensions to SMTP that any serious extensions only you support are to large degree exactly like a new protocol. > I think the hand shake could be complete wrapped within the SMTP > conversation. We have that in a way - EHLO provides list of capabilities of the server. keywords issued during RCPT and MAIL FROM provide list of capabilities of the client. Even with additional EHLO-like keyword that client would issue the issue is that it could "lie" if it does not want to list certain capabilities based on what it saw capabilities of the server are - so its all volunterily in the same way MAIL FROM and RCPT keywords are when client wants to advertise and turn on certain protocol functions. > It may be necessary to add a capabilities keyword similar to IMAP or > specify that the EHLO response include a list of supported keywords. EHLO is already basicly list of supported extensions where each one can be further subdevided (this is rarely used) into support sub-extensions/parameters > Thank you for taking the time to respond to my ramblings. :-) No problem, that's what we're still here for :) >> -- >> Hector Santos/CTO >> Santronics Software, Inc.