Michael Deutschmann wrote:
if "example.org" is a forwarding service, they might have a very
lax SPF record so that their customers are not forced to use them
as a smarthost
Okay, a "v=spf1 a ?all" variant, some IPs PASS, all others NEUTRAL.
they would want a tight TENBOX record so that customers cannot
take advantage of the "super whitelisting" to spam each other.
I'm not sure what that means. How can the "neutral" SPF policy be
abused in conjunction with the forwarding from user(_at_)fwd(_dot_)example to
user(_dot_)next(_at_)hop(_dot_)example ? Any user2(_at_)fwd(_dot_)example
sending via other
routes will get a NEUTRAL, but that's no problem wrt the forwarding.
opinion on the list seems to be overwhelmingly in favor of folding
the extra meaning into the ordinary "v=spf1" records. I suppose
it might be doable if we specify that only "PASS" is good enough for
TENBOX, since such domains will probably use "?all"...
Adding syntax for an op=tenbox is trivial, defining the semantics is
the difficult part. For a now long dead idea compare op=trusted in
the 3rd "options" draft (the current version is 10+2=12):
The "trusted" property is only used by trusted forwarders.
This trust has to be pre-arranged between clients (forwarders)
and affected servers (destinations).
If a receiver recognizes the FQDN of a trusted forwarder in a
HELO or EHLO, it verifies its IP as specified for the similar
"helo" property (6.3.1). If the "trusted" property is present
in the corresponding sender policy, all further SPF checks for
the SMTP session are disabled.
A forwarder specifying the "trusted" property MUST implement
SPF checks for all forwarded mails. It MUST NOT forward mails
to destinations without prior arrangement, if that could
result in a SPF "Fail".
Without prior arrangement forwarders with a "trusted" property
MUST either use a sender rewriting scheme, or reject the mail
with error code 551. For details about error 551 see [STD 10]
and [RfC 2821].
If a forwarder with the "trusted" property is also a MSA, then
it MUST enforce submission rights as specified in [RfC 2476].
That idea was killed because no decent receiver would believe a
single word of it without a white-list, and as soon as there's a
white list it's pointless to note this in any *_sender_* policy.
The requirements however are still a MUST, nothing less will do
from my POV as alleged "original sender" with an SPF FAIL policy.
Frank
-------
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/?list_id=735