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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In article <[email protected]>, wayne
<[email protected]> 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 [email protected] sends email to [email protected] and
>forwarder.org rewrites the MAIL FROM to
>alice#example.org#[email protected], 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

   [email protected] sends an email to [email protected]

naive.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 [email protected]

BigIsp have indeed heard of SPF and take one look at the incoming email
and see that foulmouth.org's policy is very restrictive. They refuse the
email because naive.org is not a suitable place for it to come from. The
MTA at naive.org 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: [email protected]
                 they said:     OK
                 we said        RCPT TO: [email protected]
                 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 naive.org 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
>[email protected], it for some reason fails the SPF check and
>the explanation string from forwarder.org is used.  This DSN is then
>sent back to forwarder.org, which returns it to [email protected].

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
introduction:

   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
anything.

- -- 
richard                                              Richard Clayton

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

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBQpHyMpoAxkTY1oPiEQLoKACg/3UqC6Y4WmkuR5Wpzfn3nxRCE+oAoPXD
TQlE0XYtbnFhovnQ8Ib3KclI
=qyMP
-----END PGP SIGNATURE-----