[plug] re: Email rules

[Peter Wright]

On 21/02 10:40:48, Bret Busby wrote:
> On Wed, 20 Feb 2008, Patrick Coleman wrote:
[ snip ]
>> I think SPF does something similar to this - you specify using a
>> special DNS record on your domain what mail servers are permitted
>> to send mail for your domain. If your system receives a message
>> from a mailserver that is not listed in the From: address domain's
>> SPF record, it will do something with it.
[ snip ]
> I see two problems with that solution.
>
> From what I understand, the solution that you have proposed, is what
> is known as whitelisting - specifying which sources of email are
> accepted.
[ snip snip snip ]

I think you've seriously misunderstood both whitelisting (or at least
how whitelisting is generally used) and SPF.

Whitelisting (with respect to email) is usually used only as _part_ of
an overall anti-spam solution. The idea is that emails coming from
whitelisted senders do *not* go through the usual anti-spam hurdles.

For example, at the company I work for, we have a bunch of clients.
Our mailserver uses greylisting[0] _and_ RBLs (blacklists) _and_
SpamAssassin to filter email after it's been accepted.

Email coming from client mailservers is whitelisted. All that means is
that it doesn't face the unpredictable delays of greylisting, nor the
chance of being silently spambinned by SpamAssassin, nor the more
remote possibility of being rejected due to their mailserver being
listed by an RBL.


SPF is something quite different, and it's more an anti-forging
technique than an anti-spam technique. You can read up on it here:

http://en.wikipedia.org/wiki/Sender_Policy_Framework

> Bret Busby

Pete.

[0] It's worth noting that greylisting (as implemented by, eg.
postgrey) can have its own whitelisting component - this is
specifically to work around the problem of SMTP server farms or
unusual mailservers that don't respond well to greylisting.
-- 
A debugged program is one for which you have not yet found the conditions
that make it fail.  -- Jerry Ogdin