----- Original Message -----
From: "Andre Grueneberg" <andre@???>
To: "James P Roberts" <punster@???>
Cc: "David Woodhouse" <dwmw2@???>; "Matthew Byng-Maddick"
<exim@???>; <exim-users@???>
Sent: Friday, May 21, 2004 2:08 PM
Subject: Re: [Exim] Yahoo DomainKeys...
> --
> James P Roberts wrote:
> > Why bother signing the message DATA at all? Do we really need to verify
> > unchanged contents? Aren't we just trying to confirm that the
connecting
> > host is legitimate to be sending it? Why not only sign the headers?
>
> To prevent replay attacks?! Otherwise a spammer could take the signed
> header lines and add another body. At least I would, if I were a
> spammer. ;)
>
> Andre
So, include a time/date header, to be added by the sending MTA just prior to
sending it, and have the receiving MTA check it after decrypting to make
sure it is sufficiently close to the current time? If the sending MTA
retries, it should delete/replace the previous header with a new one at each
retry, just prior to encrypting. For that matter, why not have the sending
MTA encrypt only this time/date header? All we are really trying to do here
is verify that the sending MTA knows the private key associated with the
public key published via DNS, for the sender's domain, right? Have I
missed something?
Heck, for that matter, include the sending MTA IP address, a copy of the
original sender's domain, and the original sender's IP address, in the
encrypted time/date header. Call it a "domain key header" or something.
Just brainstorming...
X-Domain-Key: encrypt[current-date-time {rewritten-}domain MTA.host.IP
received-date-time sender-domain sender.host.IP {original encrypted
X-Domain-Key: header, if any}]
where encrypt[...] means encrypted with the private key for
{rewritten-}domain.
If this is received from a "Domain Keys"-enabled sender, there will already
be such a header, and it should be retained, in both crypt and decrypt
forms, as part of the new (replacement) header. In this way, anyone
downstream can verify the entire chain, if they like.
If received from a non-participating MTA or MUA, there would be no encrypted
string included, but the raw info on when/where the email was injected from
(and the original un-rewritten sender domain) should be added by any MTA
using the feature. Thus, the chain is initiated by the SMTP server of the
ISP responsible for the originator's domain. (Which should be using SMP
AUTH and so forth to authenticate the source).
Each MTA along the way looks up the public key for the domain claimed by the
sender, decrypts the contents of the X-Domain-Key: header, verifies that:
(a) the first time stamp is reasonably close to the current time, (b) the
"MTA.host.IP" field matches the actual sending host IP, and (c)
"{rewritten-}domain" field matches that claimed in the normal unencrypted
headers. Continue the process iteratively, using the remaining encrypted
string and comparing to the unencrypted data included by the sending MTA,
until you either hit a recursion limit, or run out of strings to decrypt.
At delivery time, regardless of destination (user inbox or another MTA),
replace the incoming X-Domain-Key: header with a new one. As noted above,
the new one should include the old one, so anyone downstream can verify the
entire chain.
What this means is, a forwarder can forward if they either (a) know the
private key for the claimed sender domain, or (b) have their own private
key, and rewrite the sender domain accordingly. Note that the original
sender domain remains available to the recipient, unless the forwarder drops
it. (For example, a mailing list).
OK, that probably has a million holes in it, because I am no expert. Feel
free to pick it apart.
Jim
