-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Jon
Kyme
Sent: Friday, June 25, 2004 1:27 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Possible New Mechanism Prefix
So, now we add "Permitted".
Permitted (>): the message was sent from a sender permitted by the
domain. MTAs
proceed to apply local policy and MAY accept or reject the message
accordingly.
Surely that's what 'pass' already means. There's nothing about SPF that
requires that we don't apply local policy to a message that gets a 'pass'
from SPF is there? Using something like SPF is a part of local policy, not
a replacement for it. Or am I very old-fashioned?
Yes, you may and should apply local policy, but that's not the distinction
I'm seeking here. I want to be able to say that yes, this is a permitted
sender for my domain, but I don't vouch for 100% of the e-mail that comes
from this sender. The spec says:
Pass (+): the message meets the publishing domain's definition of
legitimacy. MTAs proceed to apply local policy and MAY accept or
reject the message accordingly.
I can't say that for certain about an MTA that is not under my
organizational control. In the example I used, if I have
include:verizon.net in my spf record, then anyone who is a Verizon customer
can now forge my domain.
People are acting on the view that SPF Pass == Not a forgery. For
organizational MTAs, I think that's safe and reasonable. For those of us
that outsource the MTA (for me, e-mail is a tool, not a business), this
isn't safe and reasonable.
As I said, in SPFv1 I can (and have) used ?include:verizon.net to avoid the
risk of being blamed for e-mail I didn't send, but I'd like to be able to be
more positive than that.
Scott K