----- Original Message -----
From: "Andre Grueneberg" <andre@???>
To: "James P Roberts" <punster@???>
Cc: "David Woodhouse" <dwmw2@???>; "Matthew Byng-Maddick"
<exim@???>; <exim-users@???>
Sent: Saturday, May 22, 2004 8:39 PM
Subject: Re: [Exim] Yahoo DomainKeys...
> > > 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. ;)
> > 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?
>
> How do you define "sufficiently close"? 1 hour? 12 h? 1 day? 4 days? 1
> week? 1 month? In any case, a spammer is likely to get hands on a valid
> "header" -- they do read mailing lists.
>
> Timestamp comparison are only practical in p2p connections with well
> syncronized clocks.
My point was simply to use a "reasonable" time difference, so that the
header would effectively "expire" soon enough to make it not worth a
spammer's while to copy it.
Furthermore, it is ridiculously easy to synchronize clocks on internet-
connected computers these days, to within fractions of a second.
I suspect something like a 10 or 15 minute timeout would be adequate.
I would further suggest any such proposal mention an allowable range.
>
> > If the sending MTA
> > retries, it should delete/replace the previous header with a new one at
each
> > retry, just prior to encrypting.
>
> SMTP is a store and forward protocol. We do have multiple steps (backup
> MX, DMZ relays ...) in the delivery process without access to the
> private key.
Precisely. The idea is to "store" the required data in the headers of the
email itself.
All I am saying is, just apply the "domain keys" idea to a specialized
portion of the
headers, in order to avoid all the problems with changing headers,
re-writing of
domains by mailing lists, etc. etc. It is not intended to replace PGP or
any of the
existing digital signature techniques for validating that *contents* have
not been
tampered with (nor should it try).
Thinking about my original idea again, I realize it would only be necessary
to
re-write the X-Domain-Key: header iff the sender domain were modified, but
then one needs a way for intermediate MTA's to be able to say (in a
trustworthy
fashion), "I checked the header when this thing came in, and it was valid."
Perhaps an idea would be to prepend a timestamp to the encrypted sender
domain
data, and encrypt that with a different key, this one keyed to the MTA host.
The
public key would again be published in DNS records. So you would have a way
for the originating domain owner to sign outgoing emails, and for each MTA
along
the way to sign it, too, as it passes through. Much like a postage
cancellation mark.
>
> > 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...
>
> It sounds quite awkward and complicated. I won't try to understand your
> plan completely as the starting points are not well thought out.
Of *course* they are not well thought out! That is pretty much the
definition
of a "brain-storm." ;) But thanks for at least reading it. :)
Regards,
Jim
