> ... I also don't see any particular utility in authenticating either > the source IP address or the mail from address, and a fair amount of > disadvantage to both; I think we need a different token to > authenticate the sender. knowing the intent of the owner of the host is important. we can't tolerate any more hosts which become open proxies or open relays by virtue of having swallowed an ms-outlook script-cookie pif-file. if a host hasn't made its intent to send e-mail known through a trusted framework, then there's no reason for me to accept a tcp session from it. (credit goes to margie arbon of maps for proving this to me.) > 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. the fact that any of the requirements which fall out of the new design are incompatible with or inconvenient when viewed from an rfc821 or rfc822 context should probably be viewed as neutral, or a feature. using (e)smtp as a bearer channel for ibcs(*) might be expedient. or not. > I don't share your opinion that everyone will want to switch completely. i know. however, it doesn't matter. you and a lot of people are free to remain with the current system. noone will stop you. perhaps if you become a small enough eyeball market, the spammers would leave you alone. > significant numbers of users will need fallback, at least for a > transition period. 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. (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 can imagine a fair number of mta authors deciding with you that they ought to try ibcs first and then fall back to smtp if there is no _ibcs._tcp SRV RR for the destination. however, i expect that most remaining smtp servers will be rejecting so damned much e-mail by that time that the actual value of such fallback will be indistinguishable from nil. (ymmv.) > even if we had to retro-fit something very different onto port 25, it > would probably be more attractive to negotiate the new protocol within > ESMTP than to have a different protocol on a different port. there's some small possibility of negotiating this on top of tcp/465, but not tcp/25. there's too much i need to know before i'll accept a command, even a helo command, from an initiator. --- (*) ibcs = interpersonnal batch communication system -- Paul Vixie