In
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0611021924210(_dot_)21607-100000(_at_)bmsred(_dot_)bmsi(_dot_)com>
"Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com> writes:
On Thu, 2 Nov 2006, wayne wrote:
One clear error is that he postulates that messages are checked at
the MDA and in the MUA both. That lets him double everything.
But the SPF records *could* be checked both places, and at each
forwarder hop.
Forwarders are configured by the receiver.
So? An attacker can set up to be the receiver, or the attacker can
discover the recievers with long chains of forwarding. Checks on the
attacker's SPF record could help discover them.
checking SPF for a given domain more than once is a
braindead checking implementation.
How would each forwarder know that the SPF record had already been
checked by the previous forwarder? Most forwarders, be it
universities, companies forwarding for ex employees, companies paid to
forward email, or ISPs, are set up in a way that assumes they are the
first to recieve the email and they need to do all appropriate
anti-spam checks, and that they are forwarding on to the final
destination.
Yeah, a spam-check, along with SPF checks, at each hop can be
redundant, but I wouldn't call it braindead.
Now, if there were a large number of incredibly stupid SPF checking MTAs,
and forwarders that *also* check SPF, but don't do SRS (even though the
recipient is going to check SPF for the same domain again), and the attacker
could get a list of all these bozos, then we could get some amplification
beyond the 100 A queries that MX provides. If that is the scenario -
then the solution is to help/convince the owners of the stupid MTAs to
get their software fixed.
Right, that's what I'm talking about, basically. But, the point is
that each hop will usually be an independant organization and it would
be very hard for them to coordinate so that only one spam check is
done. I suspect that each one would object that their software needs
to be "fixed" because spam checking is critical.
-wayne
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com