I don't have Dave Crocker's excuse of travelling in China, so I'll just
say "mea culpa" for not getting this out sooner.
Introductory Remarks
We had a number of goals in mind when we designed Caller ID. One of the
most important was ease of adoption. We have tried to design CAller ID
so that the fewest number of software changes are required, and so that
we don't require upgrades at both ends of the conversation in order to
gain some benefit.
This led us to examine various scenarios under which mail gets sent:
Direct interpersoanl mail, mailing lists, web applications generating
mail, outsourced email, and of course the thorny business of forwarding.
Looking at these together, and considering also the experience of end
users who are the ones directly affected by spam and spoofing led us to
look at the RFC2822 headers as a mechanism for identifying the purported
responsible domain (PRD) of a message. We did actually have the RFC2821
MAIL FROM at the top of our list in initial designs. However, as we got
farther into looking at the scenarios and what we could actually do on
the basis of a check of the MAIL FROM we found it was not helpful in
several cases. So we removed it. Now in my post last night ("A
proposal on identities") I've suggested a modification to our algorithm
that adds MAIL FROM back in, mainly to help with mailing list servers
that today do not insert a Sender header.
Q&A
1. Without checking any 2821 information, this doesn't save any
bandwidth. How does this save time, money, etc?
This is a hot topic! Our view is that ultimately we will not be able to
reject much mail at all solely on the basis of a 2821 spoof check.
Spammers will register their own domains, or they will move to domains
that don't publish outbound MTA info. In the end, in order to make an
accurate determination, you'll have to take the message over the wire
anyway. So the idea that you can save alot of bandwidth by rejecting at
MAIL FROM is, I believe, false ... as much as I might wish it to be
otherwise.
2. If we have a DNS based authorization scheme for domain names that
are part of email addresses, does it really matter where we apply them
to? Especially since the RFC2822 is as easy to fake as the RFC2821
addrress.
Messages can for legitimate reasons travel different routes and arrive
with 2822 headers different from the 2821 header (List servers are an
example). Because we're tying the check to the IP address over which
the message is recieved, we have to match the two together. We start at
the 2822 From address because that's the one the end user sees. And if
we're to help restore confidence in email, I think we need to start
there.
3. You discount checking MAIL FROM for the reason that that you don't
want to require changes on mail forwarders (to implement SRS). The
proposal, however, requires forwards to add Resent-* headers. How is
this consistent?
Forwarders are going to have to do something. Forwarded mail today is
indistinguishable from forged mail. We believe that adding a Resent-
header is a simpler, less burdonsome change than adopting SRS and the
subsequent burden of handling bounce messages. Also, if as we believe,
we're going to end up having to inform the user about which identity was
validated, the SRS address is simply unintelligible.
4. Does RFC2822 allow an email forwarder to modify/add the Resent-* and
Sender:headers?
Resent- headers are trace records, they get added to the top of the
headers just as Received headers do. I'm not sure about Sender headers.
I think there's only supposed to be one per message, but I've seen
examples that have > 1.
Full Jabber log at:
http://www.xmpp.org/ietf-logs/marid(_at_)ietf(_dot_)xmpp(_dot_)org