Re: [Exim] SPF

Pàgina inicial
Delete this message
Reply to this message
Autor: David Woodhouse
Data:  
A: Tony Finch
CC: D.H.Davis, exim-users
Assumpte: Re: [Exim] SPF
On Thu, 2004-01-29 at 10:05 +0000, Tony Finch wrote:
> However, I think it may be possible to accommodate traditional forwarding
> in an SPF world, with a little modification. If you VERP the return-path
> when a message is forwarded, you can then send the bounce to the message's
> originator (as with traditional forwarding) rather than losing it as
> with naive implementations of SPF. You have to be very careful of the
> implementation of the VERP: it must be nestable, to accommodate multiple
> forwardings; and it must be unforgeable (e.g. using a cryptographic MAC),
> so that it can't be used to relay spam like the % hack.


And ideally it'd also be fairly resilient against replay attacks --
perhaps each VERP'd reverse-path could be valid only for a week or so?

But even without that, you're talking about something fairly
complicated, which needs to get rolled out very widely, even to
forwarding servers which aren't participating in SPF by either using it
for filtering _or_ publishing records.

In a world where even ESMTP isn't spoken everywhere yet, I really can't
see that happening.

What I'd rather see, I think, is a cryptographic signature of the mail
itself, which must match a pubkey available in a TXT record in DNS.

At its simplest, imagine a record which advertised that _all_ mail from
the address dwmw2@??? will be signed by a given PGP key -- and
hence that you can reject anything which _isn't_. Obviously I'd also
make a new insecure key and have my mail boxen auto-sign mail which I'd
sent with SMTP AUTH.

But GPG signing is cumbersome, and we could do better than that and put
a cryptographic hash of the mail into its headers somehow.

Obviously the mail headers (and even the text perhaps) get changed along
the way, so you need to be careful about precisely _what_ it is that
contributes to the signature, but something like this should be
significantly more feasible than SPF, and require effort only by the
sender and the recipient, not anyone in between.

--
dwmw2