Mark wrote:
'authenticate' the identity on "pass"
| Verify (i.e., establish the truth of) an identity claimed by
| or for a system entity.
'authorized' to use the identity
| (1.) An "authorization" is a right or a permission that is
| granted to a system entity to access a system resource.
| (2.) An "authorization process" is a procedure for granting
| such rights.
| (3.) To "authorize" means to grant such a right or permission
Definitions found in RfC 2828.
LMAP - Lightweight MTA Authentication Protocol
draft-irtf-asrg-lmap-discussion-01 (expired 2004-08-03) said:
| LMAP attacks the forgery problem by checking that the host
| from which the message was sent is authorized to send mail
| using the a domain in the message's envelope.
| SMTP recipients can look up the authentication data when a
| domain name is used in EHLO/HELO and/or MAIL FROM.
| This verification scheme is weaker than cryptographic systems
| but stronger than the current SMTP model.
A "fresher" acronym: MARID - MTA Authorization Records In DNS.
find a way to make it clear to publishers that they must
assume responsibility if they authorize an MTA.
"v=spf1 +all" is a perfectly valid and honest sender policy.
Probably I don't understand the question.
The old megwong-01 version had also a fine PASS definition:
| 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.
The Marid-protocol-03 PASS was minimalistic and very elegant:
| Pass (+): the <ip> is in the permitted set
What "pass" really means/implies touches upon the very core
of SPF.
When "something" / "somebody" sends MAIL FROM xyzzy resulting
in a PASS then it's 100% my problem if that was spam or abuse.
But it's not guaranteed to be spam or abuse from me personally,
it can be the known cross-user forgery case. I'm responsible
to fix it on my side (e.g. talk to abuse@ my ISP)
instead of ruling on it immediately, we decided to bounce the
issue back to the spf-discuss forum
HARDPASS vs. PASS has been discussed here in numerous threads.
A complete chapter in the draft addresses cross-user forgery.
An additional draft defining op=auth "HARDPASS" is ready to
be submitted in the same hour when the SPF Council wishes it.
Bye, Frank