SPF record

[hci]

Directadmin appears to support SPF records.

I see records like so in: /var/named

domain1.com. IN TXT "v=spf1 -all"
domain2.com. IN TXT "v=spf1 ~all"

Does it refuse mail based on it as well? What is the difference between "-all" and "~all"? And how does it work on domains that I have on a static IP since all there email will be delivered from x.x.x.7 but there DNS points to there static x.x.x.9 or something?

Matthew

 

[nobaloney]

All the records should be ~all .

If you've got some records with -all they need to be changed to ~all .

The current exim.conf file does not use spf to reject or flag emails because doing so at this time would probably block over 99% of the legitimate email on the internet.

DA currently uses the SpamBlocker exim.conf file I wrote, and I can't see adding spf checking directly to the exim.conf file a this time, but you can add checking for it to SpamAssassin (though I don't rely on SpamAssassin and I've no idea how).

Of course DA is welcome to make changes to the file themselves. If I like the implementation I'd probably add it to SpamBlocker exim.conf and the forthcoming VirusBlocker exim.conf file as well.

Jeff

 

[Andrax]

SPF records and companies that block users sending that dont have a matching spf record are foolishly blocking tons of legit emails.

Many major ISP's are now actively blocking all access to third party SMTP servers. This means any customer with a hosting account on a shared server that cant use their sites SMTP has to use the ISP SMTP to get email out. Anyone setup with SPF filtering will not be getting that email.

Sorry, just a pet peeve of mine.... *sigh*

 

[nobaloney]

The biggest problem is that with a strict interpretation of SPF on the recipient server all mail sent with your domain email address from your ISPs server may be blocked.

The ~all should prevent that from happening, but we've already gotten word of some idiots^h^h^h^h^h^hpostmasters who don't accept email from servers identified by ~all .

Jeff

 

[adriaan]

A default of

domain2.com. IN TXT "v=spf1 ~all"

just means: "nobody is allowed to send mail with a sender domain of domain2.com, but we'll allow it anyway because we don't want to have any trouble"

A better default would be (IMHO):

domain2.com. IN TXT "v=spf1 a mx ptr -all"

This means:
"the hosts that are listed in the A, MX and PTR records of domain2.com are allowed te send mail with a sender domain of domain2.com, anybody else is rejected"

Or, when you also want to allow the SMTP server of the domain owner's ISP:

domain2.com. IN TXT "v=spf1 a mx ptr ip4:ip-address-of-ISP-SMTPhost -all"

If you still don't like the -all part, a safer default would be to replace the -all by ~all.

This way, most SPF records would contain reasonable information, but still no mail should be rejected because of the ~all part.

Just using

domain2.com. IN TXT "v=spf1 ~all"

won't get us anywhere in the long run, because the objective of SPF, the publication of hosts that are allowed to send mail for a certain domain, is completely ignored.

I just saw that this subject has been discussed before:
http://www.directadmin.com/forum/showthread.php?s=&threadid=3770
and as i look into
/usr/local/directadmin/data/templates/named.db
I see a default of
|DOMAIN|. IN TXT "v=spf1 a mx ip4:|SERVER_IP| ~all"

so apparently DA has a better default setting now.

regards,
Adriaan

 

[nobaloney]

A default of

domain2.com. IN TXT "v=spf1 ~all"

just means: "nobody is allowed to send mail with a sender domain of domain2.com, but we'll allow it anyway because we don't want to have any trouble"

That's not quite what the inventor of SPF says on his website.

He says:

SPF queries that do not match any other mechanism will return "softfail".
Messages that are not sent from an approved server should still be accepted but may be subjected to greater scrutiny.

(Highlighting is mine.)

A better default would be (IMHO):

domain2.com. IN TXT "v=spf1 a mx ptr -all"

This means:
"the hosts that are listed in the A, MX and PTR records of domain2.com are allowed te send mail with a sender domain of domain2.com, anybody else is rejected"

This also means (as you do point out below) that if the user, like many, is using his ISP to send email, either because he wants to, or because his ISP doesn't allow outbound email through port 25 except through their own mailservers, or because (like some including AOL) all outbound email on port 25 is transparently redirected through their own mailservers) the user's mail will be rejected by anyone using SPF. These exceptions, many of which are hard to figure out and create a major support headache, are why I recommend "~all".

Or, when you also want to allow the SMTP server of the domain owner's ISP:

domain2.com. IN TXT "v=spf1 a mx ptr ip4:ip-address-of-ISP-SMTPhost -all"

Which works fine if your ISP has only one mail server. None of the big ISPs have only one mail server and with most of them you don't know which mail server you're getting so you need to get a list of all of the mailservers they may use, by IP# (not an easy task for most ISPs, who want to keep them as secret as possible for security). Since ISPs hardly ever have MX records pointing to their outgoing mailservers, also for security purposes, you can't depend on mx for the list of IP#s either.

If you still don't like the -all part, a safer default would be to replace the -all by ~all.

This way, most SPF records would contain reasonable information, but still no mail should be rejected because of the ~all part.

Just using

domain2.com. IN TXT "v=spf1 ~all"

won't get us anywhere in the long run, because the objective of SPF, the publication of hosts that are allowed to send mail for a certain domain, is completely ignored.

I'm the person who originally recommended ~all to DA before they offered any support for SPF at all, and I recommended it as a temporary solution.

It shouldn't be necessary to do anything else yet, because SPF won't be successful (because of the many points I've brought up above) until a fundamental change is made in the RFCs as to how outgoing email is handled.

Some suggestions have already been made (I believe I've already written about them in other posts on these forums) to use other ports for all email to be relayed through email servers. implementation is actually fairly easy on exim, but it requires that all your clients switch to SMTP AUTH on another port.

I just saw that this subject has been discussed before:
http://www.directadmin.com/forum/showthread.php?s=&threadid=3770
and as i look into
/usr/local/directadmin/data/templates/named.db
I see a default of
|DOMAIN|. IN TXT "v=spf1 a mx ip4:|SERVER_IP| ~all"

so apparently DA has a better default setting now.

The mistake was mine; I was in error when I originally asked DA to use "-all"; that was an error that lasted a very short time as I informed them promptly of my mistake. But at least one version of DA was installed with the "-all" default by mistake.

All that said, here's what I use:

"v=spf1 a mx ip4:12.34.56.78 ~all"

where 12.34.56.78 is replaced by the main IP# of the server in question.

I suppose that's what DA should be using as a default now. What do you think?

Thanks for your thoughtful comments.

Jeff

 

[adriaan]

All that said, here's what I use:

"v=spf1 a mx ip4:12.34.56.78 ~all"

where 12.34.56.78 is replaced by the main IP# of the server in question.

I suppose that's what DA should be using as a default now. What do you think?

Thanks for your thoughtful comments.

Jeff

That's exactly what I'm using right now, as a default.

However, many ISP's such as Wanadoo and AOL have their SMTP A record (e.g. smtp.wanadoo.nl) pointing to multiple IP's. These IP's reverse to smtpX.wanadoo.nl with X being a number.

So, if a customer has Wanadoo as their ISP, the setting could be:
"v=spf1 a mx ip4:12.34.56.78 a:smtp.wanadoo.nl ~all"

Perhaps it would be best to ask the user for the outgoing mailserver they're using (provided to him by his ISP). That information could also easily be gotten from the headers of a confirmation mail the customer is asked to send.

regards
Adriaan

 

[macro_mote]

You can also do it like this to account for an ISP =>
"v=spf1 a mx ip4:12.34.56.78 include:aol.com ~all"

This adds all the ips aol.com lists in its own SPF record as allowable for the user's domain too.

I agree. This should be user configurable, but it's far easier to call those who don't want to accept a record (ie v=spf1 ~all) that's really no better than having none at all idiots.

 

[nobaloney]

Adriaan's post, well thought out as it is, puts a lot of pressure on your support staff as well as your clients. Maybe this scales well if you have ten or a hundred clients. At thousands it doesn't.

Nor does it when your user travels and uses a mailserver he's not familiar with.

Perhaps macro_mote's suggestion to use "include" is a bit better, but you'd be surprised how many folk have no idea what their ISP even uses as their domain for outgoing nameservers.

For example, SBC uses both sbc and yahoo domains for outgoing email; how many of their users know that?

To expect the user to understand how to create an SPF record is a sure recipe for disaster. To expect your customer support to have or to be able to easily find all the information you need for each of your clients just doesn't scale.

Even the author of SPF points out that no server should block mail based on using the ~all record.

So yes, anyone who does, is an idiot^h^h^h^h^huninformed luser.

Thanks for pointing out even more reasons why SPF will never work as is for the Internet at large.

All that said, I'm certainly happy if DA staff moves on from my admittedly simplistic approach.

Jeff

 

[adriaan]

To expect the user to understand how to create an SPF record is a sure recipe for disaster.

I wouldn't expect the user to understand how to create an SPF record, I just would like to ask the user a simple question when she signs up:

What company provides your internet access?

This could generate:

"v=spf1 a mx ptr ip4:$SERVER_IP include:$PROVIDER ~all"

This would be a better default the previous ones, making the chance of bouncing e-mail even less.

People with laptops on the road should use the mail hosting company's SMTP server with SASL or POP-before-SMTP.

Of course, this doesn't make life any easier, but neither did the introduction of an access rights system in Windows. Still this was a step in the right direction compared to the rediculously bad and unsafe designed Win95.

I guess the caveman would think it's very complicated to lock the front door and close the windows when he's out, thinking: what is the world coming to ;-)

 

[Geffy]

apparently AOL blocks emails where the SPF uses the ~all instead of the -all

are there any particular reasons for using ~all over -all

also can I easily convert the bind zone files to use the -all instead of the ~all

 

[nobaloney]

What company provides your internet access?

This could generate:

"v=spf1 a mx ptr ip4:$SERVER_IP include:$PROVIDER ~all"

This would be a better default the previous ones, making the chance of bouncing e-mail even less.

It would help for some ISPs; it wouldn't help for many, where their mail addresses are not the same as their main domain name.

But I do like it.

People with laptops on the road should use the mail hosting company's SMTP server with SASL or POP-before-SMTP.

Which won't work for most ISPs, because they block all port 25 traffic off their network.

At a Conference session yesterday at ISP.CON over 70% of the attendees affirmed that they block all outgoing port 25 traffic except through their mailservers.

I learned a lot attending a few of the sessions this week, and I'll be in touch with Mark and John to discuss how we can best implement spf.

Jeff

 

[nobaloney]

apparently AOL blocks emails where the SPF uses the ~all instead of the -all

are there any particular reasons for using ~all over -all

Yes. "-all" means "Hard Fail" and "~all" means "Soft Fail". Though the specifications and best practices are such that no one should be blocking on Soft Fail, a few ISPs are doing it. Soft Fail should only add points in a spam filter, at least according to Meng Wong, the author of SPF.

Certainly anyone who's brain-dead enough to block on Soft Fail will most likely also block on Hard Fail.

also can I easily convert the bind zone files to use the -all instead of the ~all

Sure. Move a copy of the dons zone template to the custom directory, and change it as you wish.

Jeff

 

[adriaan]

apparently AOL blocks emails where the SPF uses the ~all instead of the -all

are there any particular reasons for using ~all over -all

also can I easily convert the bind zone files to use the -all instead of the ~all

That would be something like:

cd /var/named
for i in `ls *.db`
do sed -e 's/\"v=spf1 a mx ptr ~all\"/\"v=spf1 a mx ptr -all\"/g' $i > $i.new
mv $i.new $i.db
done

plz check syntax and backup /var/named (don't blame me!)

Adriaan