In <200407212110(_dot_)19731(_at_)totor(_dot_)bouissou(_dot_)net> Michel
Bouissou <michel(_at_)bouissou(_dot_)net> writes:
Funny enough, when I post to this list, when my message gets forwarded by
listbox server, I quite quickly receive a number of SPF DNS queries which do
NOT originate from listbox's server (that would be logical), but OTOH
originate from other machines, surely MTAs at recipient's domains.
This definitely should *not* happen, as SPF should check the "MAIL FROM:",
which is
Return-Path:
<listbox+trampoline+111+2222222+33333333(_at_)v2(_dot_)listbox(_dot_)com>
I think you may be overstating things when you say what should or
should not happen with SPF lookups. While you are correct that
SPF-classic implemenations should not be doing the stuff you listed,
there isn't anything stopping people from using the SPF records for
other purposes.
For example, I have been playing with the idea of verifying the 2822.From:
header by whitelisting the exceptions. So, while your email sent to
this list would fail such a check, the fact that the 2821.FROM is
v2.listbox.com would let me safely ignore this failure.
Now, I'm not actually doing these checks right now, but someone
certainly could be doing something similar, or they could be doing
stuff that is radically different. They could be developing a new
implementation and it has bugs that are being fixed. Who knows?
It is a mantra in the anti-spam community that having your email
accepted by the receiver is a privilege, not a right. "My server, my
rules." If someone wants to reject email because some email address
in the body of a message fails an SPF check, that's the receiver's
problem, not yours.
So, I guess this stuff is, indeed, interesting, I wouldn't be too
concerned about it.
-wayne