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

[Unknown Q. <web...@un...>]

----- 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

>>
>> the domains i'm using all have SPF records on the Master server's Bind 
>> set to
>> domain.tld. IN TXT "v=spf1 a mx ~all"
>>
>> and these used to get pushed across to the Slave Bind on the 2nd server
>>
>> however, none of the domain's slave bind records now show the SFP / TXT 
>> field - it's just blank
>>
> This is however something that needs to be looked into as it should work 
> for your entry as well as any other entry with what would be considered a 
> better spf txt record.
>

Yes - i think i've spotted an error in the way the SLAVE record is displayed 
/ implemented by Webmin's Bind module

>> i've tried to force updates etc but nothing will push the record from the 
>> master to the slave
>> (i've created extra A & MX records to test that other fields get pushed 
>> across OK and they work OK)
>>
>> STOP PRESS
>> looking at the slave bind record via
>> https://slave IP:10000/bind8/edit_slave.cgi?index=NNN
>> it only shows the TXT record field as being empty
>>
>> but looking at the slave bind record via
>> https://slave IP:10000/bind8/view_text.cgi?index=NNN&view=
>> does show the line
>> TXT    "v=spf1 a mx ~all"
>>
>> so now i'm really confused as to what is the correct live data being 
>> output to the world
>>
>> normally i manually create the bind record on the master server and 
>> include the line
>> domain.tld. IN TXT "v=spf1 a mx ~all"
>> but i see now that you've got the editable fields for the SPF records
>> but i think you've also got one of the field options WRONG
>>
>> looking at https://master 
>> IP:10000/bind8/edit_recs.cgi?index=24&view=&type=SPF
>>
>> you've got a drop-down box for the Action for other senders
>> it gives these options
>> Disallow (-all)
>> Disallow (~all) i think this should say DISCOURAGE

Jamie i still think this IS a wrong description of the option

>> Neutral (?all)
>> Allow (+all)
>> Default
>>
>> looking at http://www.openspf.org/mechanisms.html
>> it appears that the settigns should =
>> - fail
>> ~ softfail
>> + pass
>> ? neutral
>>
>> but 
>> http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/ 
>> explains it as
>>
>> +all = Yes; mail may legitimately originate
>> from IP addresses not identified above.
>>
>> -all = No; this domain sends mail only from the
>> IP addresses identified above.
>>
>> ?all = Neutral; this domain makes no statement
>> about whether mail may legitimately originate from IP addresses
>> not identified above.
>>
>> ~all = Discouraged; mail may legitimately originate
>> from IP addresses not identified above, however,
>> use of such IP addresses is discouraged and may
>> not be permitted in the future.
>>
>>
>> there also appears to be a potential problem on the horizon with the 2 
>> versions of SPF
>> spf1 & spf2
>> should Webmin's bind be able to produce records for both types of SPF 
>> record?
>>
>> whilst i'm looking at this i've also come across another minefield
>> http://antispam.yahoo.com/domainkeys
>> Jamie - do you have any plans to implement tools for this into Webmin / 
>> Virtulamin
>>
>> sorry to have rambled on so much
>
> Also of note, the IETF or ISEG or whoever it is, has recently announced 
> that SID is in direct conflict with other RFCs, so it looks as though 
> Microsoft is going to have to make some big changes to SID or else, as 
> they do so often, just force non-standards upon the world. RFCs however 
> are apparently never retracted but only built upon... this is an 
> interesting spot for MS. So, be careful about what you read on 
> microsoft.com. You may get bad information based on a bad RFC submission.
>
> http://www.openspf.org/
>
> still contains the best spf wizard, although it has many shortcomings as 
> well.
>

thanks John. i'm even more confused about what to do
perhaps we can encourage AOL & Micro$oft & YouHoo to stop messing us 
around - fat chance :-)

> Best,
> John Hinton
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> -
> Forwarded by the Webmin mailing list at 
> web...@li...
> To remove yourself from this list, go to
> http://lists.sourceforge.net/lists/listinfo/webadmin-list
>