on 5/31/2003 5:43 PM Keith Moore wrote: > but I also don't see any particular utility in authenticating either > the source IP address or the mail from address, One of the potential benefits of binding IP address to the host identity would be enforcement. A spammer may be able to crank millions of identities into thousands of domains, but they will only ever have a handful of servers and that smaller subset would be significantly easier to enforce against, at least until they move. The principle benefit of binding sender identity is forgery prevention while preserving mobility. Folks can argue that the optional mechanisms for doing this today are adequate towards this, but as long as they are optional they will be limited. There are also benefits for binding the "return-path" identity at the transfer level, specifically for features like header encryption, as well as for control messages (transfer headers without message headers or a message body). > disadvantage to both; I think we need a different token to authenticate > the sender. a lot of the problems with some of the existing proposals > is that they try to overload the existing from or mail from addresses > too much. even RFC 822 recognized that Sender is different than From > is different than Return-Path. Just as a point, the 822 separation between Sender and From has become largely irrelevant in modern usage, and a modernized equivalent would likely need to use a different metaphor (not that I want to argue over what that metaphor should be right now, just pointing out that the 822 model isn't particular relevant anymore). I agree that there needs to be a distinction between the ~entity who authored the message and the ~entity who is responsible for the message being transferred. I also think they need separate identitifiers when they are different. > I don't share your opinion that everyone will want to switch > completely. significant numbers of users will need fallback, at least > for a transition period. There will certainly be a need for SMTP for a long time to come. Lots of sites won't be able to switch for some time to come, for whatever reasons, and this will be especially true the further you get from the G8 world. However, that doesn't mean that everybody will need to run SMTPng gateways. There is also the ability to run SMTPng and SMTP as separate transfer networks, with gateways in between them at critical points (such as at ISPs). For example, Hotmail and AOL exchange mail directly already, and they could use SMTPng for these exchanges and immediately start to take advantage of the available features, regardless of what they use to talk to the rest of the world. Meanwhile, these same benefits would motivate the telco ISPs to setup an SMTPng gateway that talked to those sites, and these same features could motivate corporates and governments, and so forth. As this spread outwards, the primary communication for the majority of the site-to-site exchanges would move to the SMTPng network. Once the smaller sites decided they wanted to participate in direct transfers, they could just switch over with no loss in connectivity (except to places on export-control lists, perhaps). At some point it might even be possible to route legacy messages through the SMTPng network somehow, for those remaining sites who haven't upgraded. As a radical approach, ISPs could do this by making all DNS lookups for MX RRs answer with their SMTP-SMTPng gateway address. Anyway, my personal thinking is that we can probably reach a tipping point with just a few thousand servers, if they are the right ones anyway, and after that the upgrades can spread outwards independently. My guess is that the 80/20 rule probably applies to email, in that 80% of the messages are probably routed through 20% of the mail servers, and getting a sizable portion of that 20% would likely be enough to capture most of the messaging network. BTW, this is the same reason why we don't need to worry about ~100 million users. We only have to worry about the site-to-site external servers. We don't have to worry about their internal servers. > I would far prefer a solution that lets mail > recievers turn a knob that pessimizes handling of unauthenticated > messages more and more (as more and more legitimate senders start > authenticating messages) than one which forces receivers to maintain > separate servers. There are two reasons I have for not trying it. First of all, each change request would be measured by the cost of that change in comparison to the cost of modifying existing codebases. Several elements might be declared as necessary but would still be rejected as unjustifiable. Some of the big changes -- like splitting the transfer and message headers, which would require new mailstore services for most systems -- would get tremendous pushback, and might not even make the cut. Secondarily, antyhing that did get through would be the proverbial square peg, which would have to be encapsulated, converted, and bit-stuffed into the proverbial round hole. All of this would make implementation much more difficult, and would in turn make SMTP/821 more fragile. My feeling is that the whole effort would be much more likely to succeed if it were a from-scratch design. In fact, trying to do this inside SMTP seems like a pretty good strategy for making sure that it either doesn't happen at all, or that whatever gets through would be watered down and not have been worth the effort. > (I'd also rather avoid the "how do we design a new > mail protocol" pandora's box - the amount of second-system effect would > be huge, and it would take years to sort it out) I competely agree with this sentiment, but that can be dealt with by turning feature requests into architecture requests, and keeping the features themselves out of the core specs. As an example, I want a "recall" feature that lets me rescind an unread message from a recipient's mailstore. That kind of feature has certain requirements (end-to-end option encapsulation and verifiable identities), but that particular feature should definitly not be in the spec. I can think of about 10-20 core architectural elements, but after that everything else probably should be part of another spec. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/