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
forwarder.org 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 forwarder.org is used. This DSN is then
sent back to forwarder.org, which returns it to
alice(_at_)example(_dot_)org(_dot_)
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