[Top] [All Lists]

Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt

2005-05-23 08:11:12

Hash: SHA1

In article <x4psvj2l70(_dot_)fsf(_at_)footbone(_dot_)schlitt(_dot_)net>, wayne
<wayne(_at_)schlitt(_dot_)net> writes

  To put it another way, the
  only people who see malicious explanation strings are people whose
  messages claim to be from domains that publish such strings in their
  SPF records.

the other people who will see them are people who know nothing of SPF
but forward them to a machine that applies SPF to the forwarded email;
their MTA will display the SMTP conversation in the DSN generated, which
they will receive. Text that was misleading could then mislead :(

Ok, I'm not entirely sure what you are saying here.  Let me rephrase
it as an example and see if my understanding is right.

Say alice(_at_)example(_dot_)org sends email to bob(_at_)forwarder(_dot_)org 
and rewrites the MAIL FROM to
alice#example(_dot_)org#crypto-token(_at_)forwarder(_dot_)org, and forwards it 
on to
where Bob directed it to go.  

I was specifically assuming that the mail would not be forwarded with
fancy new things like # marks and crypto-tokens...

I meant a scenario like this

   alice(_at_)foulmouth(_dot_)org sends an email to bob(_at_)naive(_dot_)org have never heard of SPF (so who can say who really sent the
email? just trust me, it was probably Alice herself). They accept the
email. However, when they decide where to deliver it they find that they
should forward all of Bob's email automatically to 

BigIsp have indeed heard of SPF and take one look at the incoming email
and see that's policy is very restrictive. They refuse the
email because is not a suitable place for it to come from. The
MTA at now generates a DSN, and manages (huzzah!) to deliver
this to Bob (who they know from internal state was "responsible" for the
forwarding and hence is the right person to receive the DSN; forwarding
systems _can_ get this sort of thing right and not back-scatter!)

Bob receives:    We said:       MAIL FROM: alice(_at_)foulmouth(_dot_)org
                 they said:     OK
                 we said        RCPT TO: bob(_dot_)brown(_at_)bigisp(_dot_)com
                 they said:     SPF fail: not handling email for idiots

Bob is one of insulted, confused, and potentially entirely misled. With
some thought I suspect you could do some interesting social engineering
with URLs...

If you're really unhappy about where the DSN goes then consider the
postmaster at receiving it instead of Bob...

The deep problem here is that you're getting one machine to repeat a
message on behalf of another. This is always risky and arguing that only
the recipient sees it is not really fixing it all that much. Everyone
thought that having badly constructed HTML reflected back to people
wasn't a problem until people discovered "cross-site scripting" :(

When the email reaches
bob(_at_)final-destination(_dot_)com, it for some reason fails the SPF check 
the explanation string from is used.  This DSN is then
sent back to, which returns it to 

in a world where forwarding has been souped up maybe it does go back to
Alice ... I rather think your document needs to explain what can happen
in this world as well

BTW: whilst I'm being helpful, I'd suggest you the third sentence of the

   While this feature is desirable in some circumstances, it is a major
   obstacle to reducing Unsolicited Bulk E-mail (UBE, aka "spam").

and perhaps the next one as well.

I think the sentence is unnecessarily contentious and adds nothing to
the rest of the document. You're proposing a scheme to tackle
impersonation, no more no less -- I don't think you need to go out of
your way at all to provoke an argument as to whether it is good for

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

Version: PGPsdk version 1.7.1