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/