On Thu, 2004-09-23 at 13:24 +0400, Peter Savitch wrote:
> Could somebody kindly summarize the MARID, SPF, DomainKeys, SenderID,
> <whatever>?
>
> Though some information can be searched through archives, it's still
> hard to understand what technology to expect as a de-facto standard for
> the near future.
That's a little off-topic here, but I'll try to summarise since it may
be of general interest.
MARID (MTA Authorization Records in DNS) was a working group set up to
pursue the potential standardisation of such things, starting from
Microsoft's SenderID and Meng Weng Wong's SPF drafts.
SPF works on the SMTP reverse-path, while Microsoft had an algorithm on
which they applied for a patent, which identifies the 'Purported
Responsible Address' (PRA). Basically From: <= Sender <= Resent-From:.
They're both essentially the same concept but one applies to the RFC2821
address and on to the RFC2822 address.
The idea was that you could declare that mail bearing a given address
shall come only from certain IP addresses. That is to a certain extent
true but the assumption is flawed in many ways in the real world, with
forwarding, virtual domains and alias files etc.
So each scheme had their own 'fixup' which they needed the whole world
to implement. SPF has the 'Sender Rewriting Scheme', SRS, where a
forwarding mail host would rewrite the SMTP reverse-path on forwarding.
So if my machine received a mail from you to a user at a virtual domain
whose mail was forwarded elsewhere, it would need to rewrite the
reverse-path to something like 'SRS0+xx+yy+t-sys.ru+x765y@???'
because it wouldn't be 'permitted' by SPF just to send it on using the
correct original reverse-path as it's been doing for years. The +xx+yy
parts are a crypto hash and a timestamp, because obviously I have to
relay bounces back to you and I don't want to be an open relay.
Microsoft's PRA would have us all adding a 'Resent-From:' header at the
local domain when forwarding, instead.
So we have a way of checking that the mail server sending the mail is
really allowed to send mail 'from' that address, be it the RFC2821 or
RFC2822 address.
This is done in conjunction with domain-name blacklists or whitelists. A
simple 'pass/fail' isn't enough because spammers publish SPF records for
their own throwaway domains too. It _has_ to use a trust-database of
some kind.
Now, both of these 'rewriting' schemes allows the sending mail host to
'take responsibility' for the mail they're sending -- whomever it
actually came from in the first place.
So if someone sees a MAIL FROM:<SRS0+xx+yy+t-sys.ru+x765y@???>
they don't really have a way of knowing if it really same from you; all
they can _really_ do is tell how much they trust _my_ mail server.
This is an important point -- by the time you've introduced the 'fixups'
to deal with the original flawed assumptions, all you've really achieved
is a way of determining how much to trust _individual_ mail servers.
It's a hop-by-hop method of determining trust, not really a full
end-to-end trust model.
Given that it's only really effective for determining the trust level
appropriate for a single hop, there were much _better_ ways of doing
that. You could do it on the HELO greeting, for example -- with similar
TXT records in DNS to say which IP addresses may use which 'HELO'
greeting. Or you could use the signature on a TLS certificate. Or any of
_many_ alternatives which let you achieve the same thing without all the
forwarding breakage, and without requiring the whole world to upgrade.
No meaningful conclusion was reached and the two original 'scopes' which
were being considered ('mailfrom' based on SPF and 'pra' from Microsoft)
were fundamentally flawed, and the working group was eventually
terminated because it wasn't really making any real progress. There were
political issues with Microsoft's silly patent, too.
As Tony says, another working group was formed to investigate true
end-to-end authentication. DomainKeys is one of the options, and there
are others -- Cisco have published an 'Identified Internet Mail' draft,
and there are other proposals around too (for more see the partial list
at
http://www.imc.org/ietf-mailsig/mail-archive/msg00000.html)
The new working group is called 'STRIVERS' (Signatures for Transport
Recognition of Imposture in Viral Email and Repugnant Spam) and the
mailing list is called ietf-mailsig.
Hopefully they'll be able to come up with a coherent merger of the best
parts of the various proposals, which can be adopted widely and quickly.
> Does it mean Exim will have intrinsic Domain Keys support, like DNSBL
> (formerly RBL)?
>
> Should one expect that Domain Keys will be wide-spread?
Something based on DomainKeys and the other input documents will
probably become widespread, yes. Hopefully it won't take _too_ long. And
when it's deployed, it will certainly be possible to use it with Exim
somehow.
In the meantime, if you want to stop getting bounces to mail you didn't
actually send, you may be interested in experimenting with SES / BATV
(
http://brandenburg.com/CSV/draft-levine-mass-batv-00.html), which is
based on an idea I outlined on the SPF mailing list in February --
http://archives.listbox.com/spf-discuss@v2.listbox.com/200402/0900.html
The idea behind that is you send _only_ messages 'signed' in the way I
described above (SRS0+xx+yy+infradead.org+dwmw2@???) and then
you never accept _bounces_ to the basic address dwmw2@???.
Apart from its interaction with ezmlm mailing lists (which look at the
SMTP reverse-path instead of the From: address) I haven't really had any
problems with it since I implemented it 7 months ago. It's really simple
in Exim --
http://david.woodhou.se/eximconf/include/routers-ses and a
ACL which is trivial but which you'll also find if you poke around, to
reject bounces to addresses in 'always-srs-senders'.
--
dwmw2
