... 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