spf-discuss
[Top] [All Lists]

RE: Forwading/Redirecting: The problem as I seeit....

2005-07-08 12:56:13
From: David Woodhouse
Sent: Friday, July 08, 2005 4:13 AM


On Thu, 2005-07-07 at 17:16 -0500, Seth Goodman wrote:
Now, I know the body hash in not a complete panacea in all
cases, but it is
for all the important ones.  The only cases it doesn't handle well are:

1) authenticating the original sender after remailing through a mailing
list, and

2) authenticating the original sender if any forwarders alter
the message body.

Neither of those are serious limitations.  Let me give a little
more detail as to why I believe this.

You omit the one which really turns me off the idea, which is that the
recipients have to know to check it in the first place. Although that's
not really a technical limitation, I suppose. It certainly doesn't
_hurt_ to include the digest.

I'm glad you agree this is not a valid objection.  Plenty of people sign
their mail with PGP yet the majority of recipients don't have the means to
validate the signatures.  No damage is done to anyone by signing mail with
PGP, but some benefit accrues to those who check it.  SES as an adjunct to
SPF is exactly the same.


But I'm still wondering why we're talking about authentication in such a
fashion anyway.

The extra assurance you get from this body hash can be seen as vaguely
equivalent to the difference between SPF 'unknown' and SPF 'pass'
results.

Yes, that's exactly the point.  When you are not talking to the originating
gateway MTA (i.e. you are talking to a forwarder), you can still tell if the
2821 MAIL FROM originated from an MTA designated to send mail for that
domain.



Let us assume that the forwarding problem gets solved, because RFC4821
mandates SRS and everyone obeys, and that I start to use SPF.

That's a perfectly dreadful scenario, as it defeats the primary purpose of
SPF.  You can validate that the mail came from the forwarder, but you have
no assurance that the originating domain is authentic.  Why?  Because with
straight SPF, even if you trust this particular forwarder, only the first
forwarder in the delivery chain can validate the originating domain.  You
then have a chain of trust that is only as good as its weakest link.  Even
if you knew the whole delivery path, do you want to maintain a rating of how
much you trust each potential forwarder?  I think not.

It makes a lot more sense for SPF to allow the recipient, in cases of
forwards, to directly validate the originator identity with the original
sender.  This avoids the entire issue of sender rewriting, which is just a
another type of forgery.  SES can solve the forwarding problem in SPF
without requiring any change at forwarders.


What am I
supposed to tell from an SPF 'pass' that I cannot tell from an SPF
'unknown' result? I know that I can't safely reject the mail; what
_more_ am I supposed to infer?

An SPF pass, assuming either no forwards or forwards + SES, tells you that
the originating domain is authentic, i.e. not forged.  You can use that for
domain-based rejection from local or third-party DNSBL's.  I think that is
valuable.  An SPF unknown, on the other hand, tells you nothing.



Is my bank manager supposed to act upon instructions which appear to be
from me and which have an SPF 'pass' result? Do I abandon my current use
of GPG for that purpose?

Not unless you are willing to give everyone in your domain access to your
accounts!  SPF stops domain forgery for direct delivered messages only.  In
the presence of forwarders, SPF + SES stops domain forgery, period.  Neither
solution authenticates an individual sender (though SES is capable of that)
to a degree that a third party should trust.  The originating domain may
assert that each user has a unique signature key, and thus SES validation is
authentication of the claimed sender.  But should your bank trust your
domain's assertion of its sender policy?  I think not, even with a waiver
from you permitting it.

So be happy and keep using GPG!  If enough people used it, we wouldn't need
any of this, but sadly, things didn't work out that way.

--

Seth Goodman


<Prev in Thread] Current Thread [Next in Thread>