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".
If you're asking for a vote on 1 vs 2, I'd definitely go for 2. But even
that is too strong a statement. At best you can assume that the address
is being used in email coming from authorized source as it applies to
that identity....
The issue is that you don't want to make a confusion by making it appear
that just because the identity being used in email is authorized, that
email message itself is authentic. There is no way to tell that - its
quite possible for another user on the same network (read for zombie
host on the same network ...) to have sent the email, etc.
Please also note that the same issue exist for cryptographic approaches
unless signature is created directly by email sender in his/her MUA or
his/her SUBMIT system (rather then domain MTA as in meta, dk, iim, etc),
which means really its only PGP and S/MIME that provide true authenticity.
But for both path and cryptography you can kind of get around to authenticity
by making special assertion that on the sender side all outgoing emails
originate at servers that require to use AUTH and verify that sender identity
used in the email is the one corresponding to who the email comes from (based
on internal AUTH database mapping of usernames to valid email addresses, etc)
or the mail server is 100% controlled only by the sender (which is quite
possible in corporate world)
Note that such assertion would have to be identity-specific (i.e. one such
assertion maybe made for MAILFROM for SPF but that does not necessarily
imply that same restriction and check during AUTH is done for From and
Sender header fields). Having recieved this assertion you can assume
authenticity and use that for reputation - although it does imply having
to also trust the actual mail server where message is coming from (i.e.
that its not compromised and that its doing all these checks as said, etc)
My feeling is that these assertions will have to be made and we should
provide for way to do with with special modifier. Its also not for nothing
that I brought up my equivalence modifier - in practice if somebody is
doing proper verification of email during submission, they can likely
make sure that Sender is set to be same as MAILFROM or use the same
domain). So whoever needs to use these stronger assertions - most likely
banks & other financial institutions to combat phishing will probably be
able to add equivalence assertion and that would make it easily possible
to extend SPF to cover not only bounce-attacks but phishing protection for
those who need this and where their reputation is very important.
On Thu, 2 Jun 2005, 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
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net