I use SPF to indicate the only places where legit mail could originate
from my domain.
To me it is not so much to prove that a mail from my SPF PASS is not
forged, but to be explicit that a mail that is NOT SPF PASS for my
domain *IS* beyond a shadow of a doubt forged.
For me (but not for vanity domains) it also asserts that the email is
authentic (because I trust my MTA's).
But it certainly does not for my personal vanity domain and other users
of outsourced MTA's.
Therefore my vote is #2: "authorized"
Terry Fielder
Mark wrote:
There is an issue regarding "pass" that we, the SPF Council, would like to
have your opinion on.
2.5.3. Pass
A "Pass" result means that the client is authorized to inject mail
with the given identity. Further policy checks, such as reputation,
or black and/or white listing, can now proceed with confidence in
the identity.
In a nutshell, we would like to solicit your position on whether SPF can
be said to 'authenticate' the identity on "pass", or wether the connecting
client can only be considered 'authorized' to use the identity. Where
"authentic", in this context, means: "not forged".
Roughly, there are two main positions:
1): If the cross-user forgery thing is the only issue that keeps us from
asserting authenticity, we should instead find a way to make it clear to
publishers that they must assume responsibility if they authorize an MTA.
Therefore, the following wording remains applicable:
"can now proceed with confidence in the identity".
2): Even if a publisher chooses to authorize an MTA patched to prevent
cross-user forgery, then, without adding to the spec, there is still no
way for a receiver to know this; so that "pass" can really only mean:
"can now proceed with confidence in the legitimate use of the
identity".
In the same vein, we would also like to know whether the domain owners
among you assumed that receivers would take SPF-verified identites as
'authentic' (position 1) or just as 'authorized' (position 2) when they
published their policies.
We feel the issue is important; especially so if reputation-checks are to
become a more pronounced part of SPF.
What "pass" really means/implies touches upon the very core of SPF.
Therefore, instead of ruling on it immediately, we decided to bounce the
issue back to the spf-discuss forum, along with the cordial request for
you to speak out on the matter at your earliest convenience. Preferably
before Monday.
The matter was discussed by the SPF Council itself; and you can review the
log of the last Council meeting at:
http://www.schlitt.net/spf/spf-council/2005/06/02_irc_log.html
Thank you for your cooperation.
- Mark
System Administrator Asarian-host.org
---
SPF Council member
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
--
Terry Fielder
terry(_at_)greatgulfhomes(_dot_)com
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085