Frank Ellermann wrote:
Alessandro Vesely wrote:
| A "Fail" result is an explicit statement that the client is not
| authorized to use the domain in the given identity. The checking
| software MUST reject the mail outright.
No, the checking software might be not in the position where it
still can reject the mail. It's at best a SHOULD in a not yet
existing "receiver policy" RFC.
A "SHOULD" is weaker, but it can handle a transition period nicely.
For SPF it's actually a feature
that spammers cannot simply probe who rejects FAIL,
Why would that be an advantage?
there might
be also receivers moving FAIL silently into a trash folder.
Hmm... If the client (relay host) is a spammer, rejection is
appropriate and saves bandwidth. If it is an innocent forwarder,
a bounce may be useful for diagnostic purposes.
As long as spammers must fear that SPF FAIL never makes it they
can't abuse FAIL protected addresses anywhere. With your proposal
they could abuse SPF FAIL protected addresses at all receivers
not rejecting FAIL outright.
I assume that by "never makes it" you mean "is never delivered".
Still, I have some difficulty understanding what you mean. Do you
mean that if rejecting were the mandatory behavior, spammers could
easily argue that not rejected messages will be delivered?
At any rate, I've seen spammers getting more cautious over time.
While they used to play like crazy, mixing FROM and MAIL FROM
addresses with no apparent reason, today's spam quite often shows
the same address in both headers, effectively masquerading as a
human2human message. I guess it is just easier for spammers to
play correctly.
There are no false positives, since the domain owner is the
direct origin of such "explicit statement".
Right, but the domain owner isn't always the same as the domain
user,
They have to trust each other, anyway.
and the receiver mailbox can be a user forwarding his mail
to an address at a third party checking SPF. Arguably that is a
kind of "false positive", and in that case I really hope that a
FAIL is rejected, and doesn't vanish silently in a trash folder.
Agreed. And the RFCs never mention silently dropping messages,
AFAIK.
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=83051516-ab0d00
Powered by Listbox: http://www.listbox.com