On Thu, 3 Feb 2011, Michael Deutschmann wrote:
The root problem is that the original designers of SPFv1 arrogantly
assumed that SRS deployment would quickly outpace receiverside SPFv1
deployment, hence there would be no need to make the distinction.
If it is not clear in the spec that you SHOULD NOT reject on -all
when not actually evaluated on an MX for the original RCPT TO domain, then we
should make that clear.
This *does* make -all not very useful to a receiver when the incoming border
MTAs are not clearly defined (since alias forwarders are the MXs for the
original RCPT TO domain).
I do not support adding "rawfail" simply to clarify the meaning of "fail".
I am open to adding "rawfail" for its own sake, as a request to reject
mail rather than deliver via alias forwarding.
Some of the arguments used to support always rejecting on SPF fail apply to
rawfail: the reject DSN contains the real address, and a savvy sender can
simply resend, possibly updating his address book. So rawfail could be
a useful option for a Sender Policy. (In addition to the already mentioned
feature of requesting direct delivery.)
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/
[http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/2183229-668e5d0d
Modify Your Subscription:
https://www.listbox.com/member/?member_id=2183229&id_secret=2183229-a7234b15
Unsubscribe Now:
https://www.listbox.com/unsubscribe/?member_id=2183229&id_secret=2183229-98aa0fe6&post_id=20110204111144:8B4D628E-3079-11E0-972E-75ACF559ED1D
Powered by Listbox: http://www.listbox.com