Re: [webmin-l] SPF bind appears wrong and doesn't update slave

[John H. <web...@ew...>]

Unknown Questions wrote:

> ----- Original Message ----- From: "John Hinton" <web...@ew...>
> To: <web...@li...>
> Sent: Saturday, December 17, 2005 8:13 PM
> Subject: Re: [webmin-l] SPF bind appears wrong and doesn't update slave
>
>
>> Unknown Questions wrote:
>>
>>> Hi
>>>
>>> i've come across a problem with the SPF records in Bind - not sure 
>>> when it happened, because it was OK before
>>>
>>> i've just upgraded from Webmin 1.230 to 1.250 but that hasn't solved 
>>> the problem
>>>
>>> basically i'm trying to stop AOL bouncing e-mails back because the 
>>> domain doesn't have an SFP record
>>
>>
>> A couple of things. First, AOL is not bouncing based on no spf 
>> record. The record you have is worse than no record at all and can 
>> land you on several blacklists. Basically you've told the world is 
>> that any spammer can use your domain name to send spam and that's 
>> alright with you and not only alright, but proper use of your domain. 
>> Therefore blacklisting.
>>
>
> thanks - at least that's 1 version of ~all Vs. ?all as explained by 
> John Hinton below :-)
>
>> AOL does bounce for several reasons, the biggest of which is no 
>> reverse dns. Blacklisting would be the second largest reason that I'm 
>> aware of.
>
>
> John you're correct - the AOL bounce was because of a potential 
> reverse DNS problem
> <<< 421-:  (DNS:NR)  http://postmaster.info.aol.com/errors/421dnsnr.html
>
> but this started me off looking at the SPF records i'd created the 
> last time i had an AOL "error"
>
> i've since sent the same e-mail to the same AOL account without the 
> bounce back occuring
>
>
>>
>> A better example of a record
>>
>> "v=spf1 a mx ptr mx:mail.ew3d.com ip4:209.145.89.235 
>> ip4:209.145.89.234 ip4:64.203.174.0/24 ?all"
>>
>> gives two allowed IP addresses and one class C. ?all vs ~all is sort 
>> of arguable at the moment, but I chose ?all because of so many 
>> malconfigured mailservers out there that are rejecting when they 
>> shouldn't be (admin just turning stuff on in a GUI instead of 
>> 'reading' about it). ? just gets 'some' more of them through.
>>
>
> the problem here is that my customers use their ISP's outgoing SMTP 
> record to cut down on my server's processing strain and bandwidth
> so -all is not a practicle option
>
> plus i've not found any sane / simple explaination of the ~all V.s 
> ?all pros & cons

? is basically, I'm trying, but don't really pay a lot of attention to 
me (which also could be translated to, I'm not sure you've got it right, 
and I don't trust your system well enough to put up a more hardline 
record). ~ is ok, I think I've got it right, but please still go pretty 
easy on me and be sure to send me a bounce message. - means this is 
written in stone and don't bug me with bounce messages because if it 
doesn't match up, it didn't come from me. There was actually a lot of 
agument during the building of the spec for spf about the ? and ~. Not a 
lot of difference between the two.

This is AOL's spf record

"v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 
ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 
ip4:64.12.138.0/24 ptr:mx.aol.com ?all"

Remember, what you do on your end isn't really what lands you in hot 
water. It's what the other end does with the record and many admins 
aren't getting it right on their end. Really, to me, it's too early to 
do any mail filtering based on SPF. I like to let the big boys make use 
of RFCs, such as rev dns.

I had a - in place for a while. Heck I was positive! So what happens? My 
mail gets rejected by some dumb admin who has all email received by an 
email provider then forwarded to his local server. Then he enables SPF 
checking on his local server. So, my record says it has to come from my 
IP... which was delivered to his mail service, which forwarded it to 
him... to which his box said this didn't come from that IP but instead 
came from 'mail service' IP which does not match so fail this email. 
BLAHHHHH!!!!

Yes, the most troublesome issue with SPF is exactly your situation... 
which is the same as mine. Many of our clients use their ISP for 
outgoing email. This means 'someone' would have to keep up with IP 
addresses and/or SPF records. There is a nifty tool however which can be 
used right inside the SPF txt record, which basically says to import 
that ISP's SPF record for this domain. I don't right off know what the 
format is, but I think it's too early to use these as well. If the 
client is a AOL customer, or one of the other large providers who are 
embracing SPF, it 'might' be safe to do the inclusion.

What I have decided to do at the moment, is to wait for the rest of the 
world to catch up a bit more and in the meantime only add SPF records 
for those clients that I 'KNOW' are using our mail services exclusively. 
The mix is just a little too new for me to trust someISP's SPF record 
for mail delivery on a domain that they likely don't even know exists. 
There's going to have to be some real togetherness on this.

The upside? Blacklisting will be reliable. Zombie spammers will no 
longer be successful. Spam will be dealt the biggest hurdle since the 
first anti-spam software. I would much rather do a SPF check on the way 
in, just like I do a DNS check and immediately handle that mail before 
it runs through clamAV, SA, sometimes hitting the backup mailserver... 
just using up horsepower. I noticed one of my boxes bounced 125,000 
messages yesterday and I have pretty open policies for receiving! The 
same box had 100s of virus delivery attempts.. likely 100% of which 
would never had made it thru to clamAV if SPF was fully enacted world 
wide. It seems each year we need a lot more horsepower to deal with the 
spam loads.. we need something simple like SPF.

But, go slow and be VERY sure in this world, yet try to do what you can, 
as the more domains which have SPF grows, the more it will be put to 
use, until a time when you'll have to have a SPF record in order to send 
mail.. again.. just like rev dns. At that point, it'll be clear to 
everyone that SPF needs to be dealt with.

Best,
John Hinton