RE: Re: [spf-help] SRS for Exim

> From: Tony Finch
> Sent: Thursday, April 29, 2004 5:33 AM
>
>
> On Wed, 28 Apr 2004, Stuart D. Gathman wrote:
> >
> > In fact, always rewriting is often called SES - and if receivers
> > implement CBV, you don't need SPF.
>
> You should distinguish between routine sender rewriting and only signing
> the sender address at the source. Both of these are enough to detect
> forgeries without assistance from SPF. However, SPF+SRS implements a
> hop-by-hop security chain which is inherently weaker than the end-to-end
> model.

A very good point which is often overlooked.

Another related point is that SPF+SRS also can only validate the domain, or
at best that a given local part is valid at that domain.  It cannot validate
that the sender had the rights to use that local part.  SES can do that when
implemented properly.  If the hash secret is different for each user
(ideally the user's login password), the MSA can check the claimed return
path to match the local login account and then sign the return path using
the user's hash secret.

>
> It would be good to add a mechanism to SPF that allows a domain to state
> that it signs its sender addresses; these addresses should not then be
> rewritten when forwarded and should be verified by the recipient using
> callouts or perhaps public key crypto (if that can be made to work).

This is an excellent idea that Meng should seriously consider.  In addition,
since SES addresses can be much simpler than SRS addresses, we would ideally
allow for the alternate address format in the case that the domain declares
in it's SPF record that it SES signs all outgoing mail.  That one sounds
like a win-win.  Let the domain owners decide which verification mechanism
they wish to use.


> > However, SPF is better because TCP connections are comparatively
> > expensive.  With only SES, anyone could easily DOS your system by
> > propagating lots of spam with your return address. Millions of recipient
> > systems calling your system to check whether the sender is valid is not
> > something you want to suffer through.
>
> A nice way to solve this problem would be to use asymmetric cryptography
> to sign sender addresses and publish the public key in the DNS.
> Unfortunately there's only space for about 100-200 bits of signature in an
> email address, which is too small for most asymmetric cryptosystems.

Yes, this is an issue.  I'll work on it to see if there is some way to deal
with it that is cryptographically "strong enough" for the purpose.  However,
this would shift the burden of validation to the recipient rather than the
sender and that deserves some comment.

Meng has produced and published slides which correctly, IMHO, argue that the
some of the cost burden of email needs to be shifted from the recipients to
the senders.  At the same time, he has argued that CBV's are too costly and
that major providers would likely not buy into any scheme that relies on
CBV's.  Since the incremental cost to senders of a system relying on CBV's
is much higher than the incremental costs to recipients, this seems at odds
with the idea of cost shifting to senders.  The position is further
confounded by the fact that Meng's organization, Pobox.com, does sender
callouts.  If sender callouts are so expensive, why would PoBox do them,
even in the absence of SES where you don't get much information by doing
one?  I respectfully ask Meng to clarify his position on this issue (and I
do mean respectfully, as my knowledge of email is puny compared to Meng's
and yet he has always replied to my questions in a helpful manner).  If I
have misconstrued or misrepresented Meng's position, I apologize in advance
and ask that he point out any errors in my thinking.

--

Seth Goodman