From: william(at)elan.net
Sent: Wednesday, June 02, 2004 4:10 PM
<...>
- DomainKeys seeks to be a mailer-to-mailer solution operating on a
per-domain level, while S/MIME is an end-to-end solution whose
result the end user interprets
Correct. Another big point here is that S/MIME requires end-user
to support
it for in order to read the email (so if you send s/mime to somebody who
does not support it, he'll not be able to read your message). While domain
keys only puts small signature and email is still readable by end-users
who don't know about it.
That would be an advantage. I believe that S/MIME support is pretty broad,
though, just like PGP and variants.
- DomainKeys puts the domain public key in the DNS, while
S/MIME puts each
author's public key in a certificate in the PKI
Which is kind of both good and bad feature.
Similarities include using a RSA-based PK crypto system and
signing of most
headers plus the message body.
S/MIME is not usually used to sign headers, it signs message body (MIME
content), and that is good choice.
I don't know whether or not it actually signs the From: header, but it does
enforce the fact that the address in that header is the same as the address
on the signing certificate. I thought it actually signed the From: and
Date: but not Subject:, though I could be all wet on that.
Signing of the headers is DK's biggest problem because if you sign all
headers and message goes to intermediate MTA that does not know about DK
but that modifies headers (almost every mail list is like that) and then
to recepient MTA that does know about DK, the end-result is that message
would be rejected because recepient MTA would see different hash of
message body that does not correspond to original message DK signature.
I didn't look at the details of the DK signing, but that sounds like a real
problem. Do you know exactly which headers DK signs?
Though I haven't looked at the
implementation details, both of the differences listed above
make DomainKeys
suitable as an automated forgery rejection mechanism.
Not really forgery rejection, but mechanism to make sure the email is not
changed in transit and that it corresponds to certain domain that provides
the holding place for public key.
Since the MTA that signed the message has to have the private key, that MTA
is by definition a designated sender (i.e. you gave it your private domain
key). This is exactly the same forgery protection you get on the first hop
with SPF.
Back to the original question: how far could/should a designated sender
scheme go into sender authentication? The easy answer, for me,
is as far as
it can without hindering it from accomplishing its original goals. With
that in mind, let's ask what, exactly, does DomainKeys offer
the mail system and its end users?
1) It signs some of the headers with the private domain key.
This proves origination by a designated domain MTA.
The sender can use "me(_at_)domain(_dot_)com" in his "From:" header and
different
email addresses in "Sender" and other headers. The DK knows nothing
about that and does not say anything about sender being authorized to
use such email address. But when message is then sent through MTA
example.com and that MTA supports DK and signs the message, what it does
tell us is that this user who says he is me(_at_)domain(_dot_)com is
authorized to
send messages through MTA that correponds to set of servers for
example.com.
I guess I'm confused here. If DK doesn't care about From: and Sender:, it
wouldn't add anything to what SPF already does. If, as you say, the MTA
makes sure the user is authorized to send mail from a particular domain,
what fields does it use to determine who the user is?
<...>
What does a typical email user really need in the way of sender
and message authentication?
1) Trust that the mail is from who it says it's from. This means the
RFC2822 From: and Sender: headers.
That is what SPF is trying to do.
Actually, SPF validates MAIL FROM: on the first hop and RFROM (or whatever
current sender parameter we eventually settle on) for subsequent hops. At
present, SPF does nothing to validate From: or Sender:.
<...>
The question I ask is: _could_ we do better, within the
confines of an SPF
system, without jeopardizing our original goal of lightweight
checking the
designated senders at each hop? I think we can, and here are a
couple of thoughts.
1) We could require that the originator's MAIL FROM: appears in From: or
Sender:. I have been trying to think of something this breaks,
and so far, I come up empty.
MAIL FROM: is designed email address to recepive bounces per RFC2821.
It tells very little about the real sender and has no requirements to
correspond to it (and doesnt for many formwards and email lists).
The biggest problem is that MAIL FROM: address is abused in such a way
that wrong people receive bounces from spammer emails and these people
get very angry as a result (and this includes myself:)
You are correct that RFC2821 defines MAIL FROM: as the address to receive
DSN's. While there is currently no requirement for it to match any other
address in the headers, what I was asking was why _couldn't_ we require it
to match the From: or Sender: header? In legitimate email, it very often
does match one of these headers. I was trying to think of a legitimate case
where it would need to be a different address, and I can't think of any. If
we could require this, an SPF pass on the first hop would mean a lot more
than it currently does.
Mailing lists are handled differently as explained in the RFC. They
preserve the original From: address, put their own address as Sender: and
set MAIL FROM: to be their bounce address. Forwarders, on the other hand,
are not supposed to change MAIL FROM:, From: or Sender:. They typically
just change To:, prepend another set of Received: headers and resend the
message.
--
Seth Goodman