What does PASS mean and what can you do with it? FYI, this is not a new
concern for me. Here was my first post to spf-help:
http://archives.listbox.com/spf-help(_at_)v2(_dot_)listbox(_dot_)com/200405/0035.html
The current spec says:
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.
Now this is easy for dedicated MTAs, client is authorized = domain owner
authorized. For shared MTAs that do not have technical measures in place to
prevent cross customer forgery (and that's virtually all of them except
webmail), client is authorized <>= domain owner authorized. The message might
be domain owner authorized and it might not (could be a forgery from another
authorized user of that MTA).
Because of the idea of automated domain based blacklists:
http://spf.pobox.com/faq.html#churn
I have stayed away from marking mail from shared MTAs that don't prevent cross
customer forgery with PASS. I have also advised others to do that too. If
Meng's new philosophy is right (see excerpt from the last council meeting
below), then those of us on shared MTAs are in trouble.
Now that we have HELO checking as a standard tool in the SPF box, I would
suggest that this approach be modified. The mail server is really where the
reputation (RBL) impact should be assigned. It will encourage mail server
operators to police their users. Here's what I suggest:
If HELO/EHLO = PASS and Mail From = PASS, bad reputation goes to HELO/EHLO
domain.
If HELO/EHLO <> PASS and Mail From = PASS, bad reputation goes to Mail From
domain.
This would let shared MTA users whose MTA sends a good HELO/EHLO to use SPF
PASS with confidence that they wouldn't get burned. And yes, this is very
similar to what I proposed last year.
Here's a snipped excerpt from the last meeting:
21:19 <freeside> had a chat with mark lentczner a few months ago about
what we would've done differently.
21:20 <freeside> one thing he mentioned was that it might be a good
idea to leave out the "-all" completely.
21:20 <freeside> in other words, if we, the spf community, had just
focused on making assertions for when you do know
it's from the sender --- ie. all the positive
mechanisms, like ip4, mx, a, etc.
21:21 <freeside> and then remaining mum about explicitly denying
forgeries --- eg. "if it didn't match, well, we're
not saying it's from us, and we're not saying it's
not, so you draw your own conclusions"
21:21 <MarkK> Is not the whole point of SPF to determine 'fails'?
21:21 <freeside> i agree that most of the community prefers "-all",
but the small very vocal minority of objectors have
seized on the forwarding problem as a major flaw in
spf.
21:21 <Julian> I guess that's a matter of perspective.
21:22 <freeside> two years ago i would've agreed that determining
"fails" was the #1 feature of SPF. now i'm thinking
it would've been less controversial to say that the
whole point of SPF is to determine passes, and allow
people to draw their own conclusions about the rest.
21:22 <Julian> We won't change a thing if we see to it that every
legacy behavior from 20 years ago stays legitimate.
21:22 <freeside> that would've quieted the detractors.
21:23 <freeside> and done more for advancing the project as a whole.
So, as it stands, I (and other shared MTA users) will have a hard time getting
to a PASS if we are worried about our domain being blacklisted.
This doesn't directly require a change in the spec, but a statement of policy
(and an update to the web site when such things are being done again) would
likely be enough. The most I would suggest would be a sentence added to 10.1,
perhaps:
"Additionally, it is possible that a malicious sender is an authorized user for
the MTA in question, but not authorized to send for by the domain owner."
Scott Kitterman