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

In <[email protected]> Richard Clayton <[email protected]> writes:

> In article <[email protected]>, wayne
> <[email protected]> writes
>
>>There is a new I-D for the SPF email anti-forgery system available for
>>review.  This draft tries to document the current practices of the
>>~1,000,000[1] published SPF records and ~10,000[1] deployed SPF
>>systems that are checking 20-100million emails per day.
>
> not that I'm not impressed, but this isn't a huge amount yet :)

As Frank mentioned, these numbers aren't intended to convince people
that SPF is universally used, just that it is used enough that it is
not really experimental or a theoretical system.  I wasn't very clear
on this though.


>>I realize that the whole subject of SPF (and similar systems) has a
>>certain amount of controversy to it, but for the purposes of this
>>draft, I am very reluctant to try debate these issues.  The goal is to
>>document a de-facto standard.
>
> OK .. to be helpful then
>
>>10.5.  Untrusted Information Sources
>>
>>   When the authorization check fails, an explanation string may be
>>   included in the reject response.  Both the sender and the rejecting
>>   receiver need to be aware that the explanation was determined by the
>>   publisher of the SPF record checked and, in general, not the
>>   receiver.  The explanation may contain malicious URLs, or it may be
>>   offensive or misleading.  This is probably less of a concern than it
>>   may initially seem since such messages are returned to the sender,
>>   and the source is the SPF record published by the domain in the
>>   identity claimed by that very sender. 
>
> OR a domain that the check is redirected to

You are correct, there could be more than one record published, but
that really don't change the point that it is the domain owner who
controls this.

I've changed this with:
  s/the SPF record published/the sender policy published/


> assuming I've understood 6.2 correctly. BTW: the note at the end of 6.2
> has the concept "target domain" in it. Uniquely. I suspect this is the
> concept defined in 4.8 that is to be called "<target-name>"

Good catch.  Fixed.  Thanks.


>>   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.  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 this case, if forwarder.org creates a misleading explanation
string, Alice will see it.


If this is what you are saying then:

* You are correct, the text quoted above is wrong because it isn't
  *only* the folks who use the forwarder.org domain that could see
  it.

* But, if forwarder.org was evil and wanted to create a misleading
  DNS, they wouldn't need SPF explanation strings to do that, so this
  really isn't a security hole or anything.


Please let me know if I'm on target here.  If so, I'll update the text
to correct this.


-wayne