Mailing List Archive

On Wednesday 10 October 2007 04:39, Per Jessen wrote:
> I've just "met" the 2nd Swiss provider rejecting emails purely based on
> SPF. The first one was back in july, and they switched it off fairly
> quickly. The most recent one is looking into exactly what they want to
> do about it.
>
> I was just wondering - does anyone have a feeling for how common it is
> for a provider to reject emails purely based on an SPF check?
>
This is how SPF was meant to be used (RFC 4408 is unfortunately wishy washy on
this). Every open source SPF checking implementation (distinguishing from
stuff like SpamAssassin that includes SPF checks, but only as part of a
larger anti-spam effort) that I'm aware of defaults to do this.

The major risk associated with this is rejecting transparently forwarded mail.
For many (dare I say most) users this is not significant. There are a
variety of solutions. Whitelisting forwarders from SPF checks is I think the
best. One of my design goals for the Postfix policy server I'm developing is
to provide tools to do this via database on a per user basis so it will scale
better.

Scott K

-------------------------------------------
-----------------------------------------------------------------------
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
Powered by Listbox: http://www.listbox.com

On Wed, 10 Oct 2007, Scott Kitterman wrote:

> The major risk associated with this is rejecting transparently forwarded
> mail. For many (dare I say most) users this is not significant. There are a
> variety of solutions. Whitelisting forwarders from SPF checks is I think the
> best. One of my design goals for the Postfix policy server I'm developing is
> to provide tools to do this via database on a per user basis so it will scale
> better.

Since rejecting transparent forwards is something a receiver does to
themselves, this is more of a buggy implementation risk than an SPF risk.
It is simply incorrect to reject your own forwarded mail. For in-house
mail, this type of implementation error is unlikely and easy to fix.

Where it usually comes up is when an email service provider decides to
implement SPF without end-user cooperation (to identify forwarders set up
by the end user). Since end users often forget about their forwarders
anyway, one solution is to reject SPF fails with a 551 Mbox moved; try
<...@...>. If the end user has forgotten about their forwarder, they
probably want the sender to use their new address anyway. If 551 was more
common, email clients would start offering to automatically update address
books.

For my own domain, I reject SPF fail with 550 because I implement SRS on all
my forwarders.

Rejecting SPF fail with 551, or implementing a per user database such as Scott
suggested, requires delaying SPF checks until RCPT TO. This has some pros
and cons. The pro is that you can skip the SPF check altogether if the
RCPT is invalid. The con is that a spammer can keep trying RCPTs. The pro
is that if they do, you can blacklist the IP (a feature I added to the
latest python milter), and reject immediately at connect the next time.
I have a list of about 500000 ips that engage in dictionary attacks.
It reduced my spam bandwidth considerably to reject 'em immediately.
It is too big a list, unfortunately, to put in the firewall.

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

-------------------------------------------
-----------------------------------------------------------------------
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
Powered by Listbox: http://www.listbox.com