In
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0612022003480(_dot_)21891-100000(_at_)bmsred(_dot_)bmsi(_dot_)com>
"Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com> writes:
On Sat, 2 Dec 2006, Julian Mehnle wrote:
Look, the problem is that everytime this comes up, after a while I get
tired debating it, but it always comes up again later because I just can't
get this "Pass means I authorized the message, but don't blame me for it!"
concept into my head. It doesn't make sense to me. Not. Make. Sense. To.
Me. :-(
A Modest Proposal: Intensifiers for SPF Results
[a funny complaint about the "I REALLY REALLY MEAN IT" problem]
OK, I think both Julian and Stuart have a point here, but I think they
are also somewhat missing stuff.
One useful thing that has come out of my participation in the DKIM WG
is that I now have a clearer idea of what I think needs to be
discussed when dealing with things like SPF results.
SPF (like DKIM) is a protocol, a way of communicating. It happens to
be a one-way communication, which simplifies some things. So, SPF is
all about the domain owner providing information to the email
receiver.
In order to be useful, SPF results need to have accomplish three
things:
1) The information must be something that the receiver can't already
know.
2) The information must be something useful for the sender to say.
3) The information must be something useful for the receiver to hear.
Now, there is a little wiggle room in these three criteria. Some
receivers might be able to get information other ways, and you don't
need to have the information be useful for everyone.
Let's look at two extensions to SPF that I've heard discussed quite a
few times, a "HARD PASS", and a "I really mean FAIL".
For a "HARD PASS", the sender is saying that they don't allow
cross-user forgeries.
Let's check this out compared with the above three criteria:
This passes the first criterion since knowing that there aren't any cross-user
forgeries is not something a receiver can easily tell.
For the second criterion, I guess that is something that senders might
want to say. After all, it does require extra effort to do.
For the third criterion, is this something that a receiver really
wants to hear though? I'm not so sure. I suspect that the vast
majority of receivers will assume that any cross-user forgeries are
the sender's problem anyway.
My conclusion: I'm not so sure that that a "HARD PASS" is that
useful.
For the "I really mean FAIL", there are quite a few different cases.
This seems to be pushed mostly by folks like paypal who get phished a
lot. As Stuart's parody points out, it is easy for the sender to say
"I REALLY REALLY REALLY MEAN FAIL", but saying this isn't useful for
the receiver.
My proposal for a "I really mean FAIL" is: If you, as the email
receiver reject an otherwise legitimate email due to an SPF Fail, then
the blame can be put on me, as the domain owner. As a sender, I have
taken the steps necessary to make sure that the email I send will
never Fail, which may include things like never sending to email
addresses that get forwarded and such.
Legitimate email, like all good forms of communication, is something
useful for the teller to say and the listener to hear. Any time an
email is blocked, there is always a battle about who's fault it is and
the support costs of resolving the issue can be very significant,
compared to the normal costs. By shifting the support costs from the
receiver to the sender, this gives the receiver a reason to listen.
So, how does this proposal stack up to the three criteria?
This passes the first criterion because the receiver can't know that
they can shift the blame for an incorrect rejection.
This passes the second criterion, at least for heavily phished
companies where the cost of phishing might easily outweigh the extra
support costs.
This passes the third criterion because the receiver can safely reject
email that fails an SPF check without adding to their support costs.
My conclusion: An appropriate "I really mean FAIL" policy could be
useful.
Now, for fun, you might want to ponder whether "SoftFail", something I
lobbied Meng to get put back into SPF, actually passes the above three
criteria.
-wayne
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735