[Top] [All Lists]

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

2005-05-22 11:04:38

In <QpDnMfnubmjCFAas(_at_)highwayman(_dot_)com> Richard Clayton 
<richard(_at_)highwayman(_dot_)com> writes:

In article <x4zmup7j6p(_dot_)fsf(_at_)footbone(_dot_)schlitt(_dot_)net>, wayne
<wayne(_at_)schlitt(_dot_)net> 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 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.  When the email reaches
bob(_at_)final-destination(_dot_)com, it for some reason fails the SPF check and
the explanation string from is used.  This DSN is then
sent back to, which returns it to 

In this case, if 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 domain that could see

* But, if 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.