I think the most common two instances I've seen on my mailservers both fall
loosely into this category:
* Legitimate email being rejected due to being sent from the wrong
location. (aka the traveling mailman problem, or the roaming/home
user problem.)
1) It's been difficult to get email through to our secure mailserver from
all ISPs when users are travelling. Some of the dial up ISPs seem to grab
the email packets and make them go through their own servers instead,
regardless of how "outgoing mailserver" is set on the email client. This
results in some of their mail to 3rd parties that check SPF getting blocked
as coming from an illegitimate IP. We've had some success getting around
this using alternate ports but when users are on the road they are often not
highly receptive to spending lots of time on the phone screwing around with
their mail settings to work it out.
2) We've had some problems with legitimate autogenerated mail from websites
that have put our users' names as the "from". For example when we first
started publishing SPF records some of our users couldn't get the shipping
delivery alerts on the FedEx site to work with SPF-checking recipients
because FedEx placed the package sender's email in the "from" instead of
FedEx's own. FedEx has since fixed this.
We also had an isolated incident falling into one of these categories:
* Legitimate email being rejected due to SPF records not containing
all IP addresses that they should
* Legitimate email being rejected due to SPF records having syntax
errors.
3) This was a case of certain legitimate email from eBay not arriving. The
problem seemed to be limited to email alerts regarding question and answer
messages sent by other eBay users. These alerts were coming from addresses
of the form ebayapp(_at_)sj-v3conta*(_dot_)sjc(_dot_)ebay(_dot_)com were getting blocked
(ebayapp(_at_)sj-v3conta01(_dot_)sjc(_dot_)ebay(_dot_)com for example) as not being permitted
senders. My users found this a rather urgent matter so I found it most
expedient at the time to get around the problem using whitelisting.
Therefore I do not know if eBay has since resolved the problem.
We have not had any problems with outgoing mail that was successfully sent
through our secure mailserver, as far as I have heard.
Hope this helps.
--Kaas
From: "wayne" <wayne(_at_)schlitt(_dot_)net>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Saturday, August 06, 2005 12:28 PM
Subject: [spf-discuss] Survey: When does SPF cause legitimate email to be
rejected?
A question for those who have spent a lot of time helping point solve
problems with SPF failures.
What are the most common failure cases for SPF? (Please indicate
which is the most common.)
For example:
* Legitimate email being rejected due to forwarding.
* Legitimate email being rejected due to being sent from the wrong
location. (aka the traveling mailman problem, or the roaming/home
user problem.)
* Legitimate email being rejected due to mailing lists not rewriting
the MAIL FROM address
* Legitimate email being rejected due to SPF records not containing
all IP addresses that they should
* Legitimate email being rejected due to SPF records having syntax
errors.
* Legitimate email being rejected due to SPF records being used for
PRA checking instead of MAIL FROM checking, or similar cases where
the SPF record is not being used as intended.
* Other cases
While it is fairly easy to detect when SPF is rejecting email, it is
much harder to distinguish between legitimate emails being rejected,
and when some spammer has forged email and the rejection is exactly
what we want.
Looking through the SPF-Help RT reports, it looks like the roaming
user problem is actually roaming user problem is the most frequent,
but I haven't studied the reports closely enough to be sure.
-wayne
-------
Sender Policy Framework: http://spf.pobox.com/
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/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com