spf-discuss
[Top] [All Lists]

Re: SPF and Responsibility

2004-07-22 02:31:57
On Thu, 2004-07-22 at 04:05, David Beveridge wrote:
On Thursday Mark wrote:
On Wed, 2004-07-21 at 22:31, David Beveridge wrote:

For one, your interpretation would mean a PASS result would be of little
use practical use to anyone:  It would mean that the only useful result
from the point of view of recipients would be "FAIL:  This message is
not authentic."

Pass isn't very useful as I see it, how does the SPF tell me whether the ISP
has setup their mail server as you've described.

Uhm, err, with the "+" character, which tells you that the sender is
willing to stand behind messages from his domain from this server,
putting his reputation on the line.

Is that what you're asking, because, uhm, I think you're asking the
wrong question really.

Asking how an spf record will tell me as a recipient that a mail server
is set up in a particular way is not the right question, because, to put
it bluntly, recipients don't care about those details of the setup, just
about the end results.

For a sender to tell recipients to please trust that mail from a certain
server (claiming to come from his domain) really is from his domain,
means the sender has to trust that that is true too.  (To misquote
Jonathan's wording.)

How the sender makes that determination is his problem, not the
recipient's problem, just as it's the webmaster of www.example.com's
problem to make sure that the webmaster of competitor.example.com can't
edit his web pages.

In both cases, if the recipient/reader finds out that a forgery has
occurred anyway, the positive reputation the domain/business will have
built up by standing by their claims can quickly erode.

And in both cases, if the recipient/reader finds that the domain can't
ever state what's a forgery and what isn't, ("Yeah, our web page gets
hacked a lot, so don't put much stock in what we say--but please order
our products anyway"), well, the domain or business won't ever build up
much of a reputation to begin with.

There are pluses and minuses (pun unintended) of both situations.

To put it all another way and step back a bit:

o  If you want to tell me that messages from that server that claim
   to be from your domain really will be, then use "+".

o  If you want to tell me that messages from that server (that claim
   to be from your domain) might be from your domain, use "?".

In either case, I'll believe you, and act accordingly.

This means:

O  I'll trust messages with PASS results more than messages with
   NEUTRAL results, but if I get PASSing messages that turn out
   to be spam, your domain will of course quickly get into
   domain-name-based block lists.

o  I'll not trust messages with NEUTRAL results to be from you as much,
   which means your domain-name won't get blocked listed as easily
   because of abuse of someone else, but...I'll do more content 
   filtering on those messages and I'll absolutely migrate to
   competing businesses that send mail with real PASS results.

Note that as a recipient in the above two cases it never crosses my mind
how your mail server is set up internally.  I just go by your
statements.

Fail is by far the more
useful
response because we know it isn't authentic.

Look at the code in the postfix perl policy

  if    ($result eq "pass")  { return "DUNNO"; }
  elsif ($result eq "fail")  { return "REJECT " . ($smtp_comment ||
$header_comment); }
  elsif ($result eq "error") { return "450 temporary failure:
$smtp_comment"; }
  else                       { return "DUNNO"; }
  # unknown, softfail, neutral and none all return DUNNO

That's a pretty sensible default.

I would guess that practically everyone would want to reject FAIL's
immediately, but they might want to do more easily tunable local-policy
checks on the rest.

Under your interpretation, all the other results would boil down to "the
message might or might not be authentic", and so there'd be no point in
any sending domain bothering to describe servers with "+" versus "?".

I've got to say I like this idea, but the existing domains out there that
published spf already wouldn't conform to this.

As spf becomes more popular and used, I'm guessing that people and
businesses with awful, untrustworthy ISPs will move to more trustworthy
email service providers so they can honestly make "+" claims safely.

A lot seems to have been removed from that latest memo such as the
description of the meaning of + - ~ and ?.
I thought that once we identified that the mail was coming from the correct
mail server then we could look up the ip address in a trust database to find
out the reputation of the server.  If the server belongs to a spammer it
will appear in an rbl somewhere pretty fast.

Nah--for an SPF PASS messages, I'd want to eventually forgo the IP based
RBL lookups altogether, and just look up the domain in a right-hand-side
domain block list.

The reason being that if the mail really is from a particular domain,
and if the domain is reputable and non-spammy according to domain-name
block lists, then I don't care about what else occurs with that
mailserver.

Even if that mailserver is continually spewing spam from another domain,
once we can authenticate sources of email there's no need to make an
honest, non-spammy domain suffer for the actions of one of the mail
servers spammy customers, unless we have reason to suspect that most all
of the mail server's customers or the mail server itself is spammy.

(We have to do that now, because of the lack of authentication
meta-information available to us now, but over time if spf takes off,
that sort of broad stroke handling of the situation won't be as
necessary except for the more extreme areas, (such as the spamhaus rosko
list.)  Then everyone can breath easier all around.  Well, maybe not the
fraudsters and spammers.)

-- 
Mark Shewmaker
mark(_at_)primefactor(_dot_)com


<Prev in Thread] Current Thread [Next in Thread>