spf-discuss
[Top] [All Lists]

Re: SPF+SRS vs. BATV (was: SPF Stats)

2005-07-05 06:53:45
On Tue, 5 Jul 2005, David Woodhouse wrote:

The second statement is patently false.  If you don't want to deal
with your forwarding mess, simply don't check SPF, or don't reject on fail.
End of story.  You can still publish SPF, SPF still works great for
those who are fully participating.

I cannot publish SPF (with -all) today because I know there are
recipients out there who would reject valid mail after it's been
forwarded. To publish '-all' would be saying that no valid mail from my
users would ever come from IP addresses other than my own, and I _know_
that to be false, because SRS isn't ubiquitous.

Any recipient who rejects your mail because they forwarded it somewhere 
else first is badly broken.  (Remember, it is *their* recipient address.  They
did any forwarding to some other address.)  Of course, many recipients are
badly broken, but not usually in their SPF implementation.  Your argument
amounts to "Gee, some people might not implement SPF checking properly,
so I have to gut my SPF record to try and compensate for some of 
the stupid mistakes they might make."  

I've had 15 years of experience dealing with braindead mail software
and ignorant admins.  I can assure you that at least for now,
the kind of mail admin who would make that kind of stupid mistake
will not have heard of SPF.  I deal with mail delivery problems constantly,
all the domains I manage have published SPF with -all for a year, and there has
never been a problem with delivery due to the incorrect SPF checking you fear.
Until SPF hits the threshhold where everyone does it whether they understand it
or not, your imagined problem does not exist.

In anticipation of that threshhold, we need more FAQs on your to avoid
common mistakes.  Rejecting fails without accounting for your
forwarders could turn out to be one of those common mistakes.

I cannot reject for failure today because I know I cannot feasibly keep
track of all the various hosts which may forward mail to my servers, and
I _know_ that there'll be false rejections because SRS isn't ubiquitous.

Great!  Your implementation is not broken.  You do not account for
your forwarders, but you don't reject on fail either.  Good job.

SPF only 'works great' if you don't mind throwing the baby out with the
bathwater. I'm sure there are people at verizon who claim that blocking
all non-US IP addresses 'works great' too. And there are ex-customers
who disagree. Go figure.

SPF only throws out what I the publisher tell people to throw out.
My SPF records apply until my messages are accepted by the MX for
the RCPT TO addresses.  Once it is accepted by the recipient MX,
they can do whatever with it, including forward to some other address,
but my SPF record has nothing to do with it.  Once the recipient MX
accepts the message, it no longer Sender Policy, but Reciever Policy.

All the alleded problems you are complaining about have nothing to do with
sender policy or SPF records.  They all have to do with receiver policy -
and the possibility that some nimcompoops might decide to use external
SPF records for their own internal receiver policy.  Sheesh, what some
people will do to screw things up.  

Are you saying that such broken recipients exist now?  What is an example of
such a broken domain?

-- 
              Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


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