[119901] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: AT&T SMTP Admin contact?

daemon@ATHENA.MIT.EDU (William Herrin)
Thu Dec 3 14:59:39 2009

In-Reply-To: <073D5290-1115-4AA5-8B7D-E4D8695BB833@hubris.net>
Date: Thu, 3 Dec 2009 14:58:35 -0500
From: William Herrin <herrin-nanog@dirtside.com>
To: Chris Owen <owenc@hubris.net>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

On Thu, Dec 3, 2009 at 1:25 AM, Chris Owen <owenc@hubris.net> wrote:
> On Dec 2, 2009, at 9:52 PM, Valdis.Kletnieks@vt.edu wrote:
>
>> It only stops forgery if the SPF record has a -all in it (as hubris.net =
does).
>> However, a lot of domains (mine included) have a ~all instead.
>
> I guess I've never really seen the point of publishing a SPF record if it
>ends in ~all. =A0What are people supposed to do with that info?
>
> Spamassassin assigns it a score of 0.6 but that is low enough it
>really doesn't have much since it doesn't assign any negative
>points for SPF_PASS.

Chris,

In addition to pushing the spam assassin score a little more towards
tagging it as a spam, I use SPF to suppress backscatter from my
confirmation system. When I receive a message whose spam probability
is ambiguous (spamassassin score between 3 and 8), I generate a
confirmation request to the sender. This allows the sender to put the
message in front of me anyway if it turns out to have been a false
positive, as it occasionally does.

If you publish SPF records (even with ~all) and the source doesn't
match, I won't generate that request. You've given me sufficient
forward knowledge to detect the forgery so that I can silently drop
the spam and still comply with RFC 2821's "must."

Regards,
Bill Herrin



--=20
William D. Herrin ................ herrin@dirtside.com  bill@herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


home help back first fref pref prev next nref lref last post