SPF records default to "v=spf1 -all"

[wKkaY]

the default SPF record that DirectAdmin adds is "v=spf1 -all". this effectively means that, "no hosts are authorized to send mail for this domain"!

this really isn't what you want. something along the lines of "v=spf1 ~all" would be much better. please check the following page for configuration options: http://spf.pobox.com/wizard.html

 

[nobaloney]

I may actually be responsible for this error; I may have misread a "~" as an "-" when I read about the all option, and the wizard you point to really doesn't clarify the function of "-all" as well as it should .

So I'm going to immediately bring this to John's attention.

However, looking now, I can't find "~all" anywhere; can you point out to me where you get that from?

The FaQ for SPF specifically says "?all" to allow all mailservers to send email.

Please help us correct this problem by letting us know where you found the "~all" reference from.

Thanks.

Jeff

 

[wKkaY]

i got it from their setup wizard linked above.

after reading the RFCs, i think ?all will be a better default option than ~all

 

[nobaloney]

I've already discussed this with John, and for the moment he's going to default to ?all.

However, I'd like to know more, and it seems you've done the research.

So...

Please explain what in the setup wizard got you ~all, and the differences you found between ~all and ?all.

Thanks.

Jeff

 

[wKkaY]

Please explain what in the setup wizard got you ~all, and the differences you found between ~all and ?all.

quote SPF RFC http://spf.pobox.com/draft-mengwong-spf-01.txt

Neutral (?): The SPF client MUST proceed as if a domain did not
publish SPF data. This result occurs if the domain explicitly
specifies a "?" value, or if processing "falls off the end" of
the SPF record.

Softfail (~): the message does not meet a domain's strict
definition of legitimacy, but the domain cannot confidently state
that the message is a forgery. MTAs SHOULD accept the message
but MAY subject it to a higher transaction cost, deeper scrutiny,
or an unfavourable score.


the wizard tacks on ~all if you answer "no" to the question 'Do the above lines describe all the hosts
that send mail from xyz?'

 

[nobaloney]

Thanks, wKkaY.

So then the question is asked, "which should webhosting companies use so our clients can continue to send email out through their ISPs and when they travel?

Since it's unlikely our clients will know the names of all the servers their ISPs might be using, and in addition will typically "forget" that they sometimes log in to send mail at the airport, and perhaps from their local Starbucks (coffee shop), we can't expect this to work unless we either give them the proper record that allows all[/b] mailservers to be used, or to require them to reset their outgoing email servers to us a secure connection to your system, unblocked by any ISP, for all outgoing email, no matter from where they log in.

My first recommendation is that John use the "~" character for now, as some ISPs may soon begin to block email from domains that do not publish SPF data, and it looks to me as if that is what the "?" will be interpreted as.

My understanding is that all domains should continue to publish "~" data, because that's the only way that forwards, mailing lists, and Form-to-Email programs will continue to work.

But I'm also going to recommend authenticated smtp over the authenticated smtp port as the method by which we allow our clients to use our servers for outgoing smtp.

John, are you watching the thread?

Jeff

 

[DirectAdmin Support]

~, check.

John

 

[macro_mote]

The whole purpose of SPF is to identify a limit on the IPs your domain's outgoing email originates from. Many users have problems with spammers, viruses, etc spoofing their addresses. Yet, you want to turn a system which is trying to help overcome this extremely annoying problem into a pretty useless one for every DA user?

Your argument is that clients will probably not know the names of all their ISP's mail servers. I agree most people have no clue. If their ISP is already listed in the SPF database, the line just needs an include w/ the ISP's domain name. For those not in the database, what's wrong with these people contacting their ISP for a list of IPs or asking them to join it. AOL has over 25 million users in the US with mail servers on only seven IP ranges. Earthlink has about 5 million users on three IP ranges. The other ISPs are probably only using a few ranges too.

If this system ever catches on (MS plans to start 1 Oct and AOL sometime in the near future), the forging slimeballs will gravitate to domains with no SPF records or ones without a strict definition. Plus all our own mail will be treated as spam.

Why not offer two settings to the user instead of forcing a one solution on everyone. The basic one can be for those who want to be able to send email from any mailserver. The advanced one which allows a user to tailor the setting in adding a, mx, ptr, includes, and/or IP ranges with the -a stricter setting.

 

[nobaloney]

Why not offer two settings to the user instead of forcing a one solution on everyone. The basic one can be for those who want to be able to send email from any mailserver. The advanced one which allows a user to tailor the setting in adding a, mx, ptr, includes, and/or IP ranges with the -a stricter setting.

Thus creating a support nightmare, as your clients, who have no idea what SPF is, or how to create one, create SPF records that at best don't work and at worst bring down your server, all in the name of sending outgoing email.

Do you really think that companie sare going to start refusing mail with wildcard SPF records that soon? If they do, their users won't be able to get mail from well over 99% of their correspondents.

While I remain firmly against SPF as creating more problems than it solves (and this is just one example), I don't think allowing our users to create their own SPF records is a viable solution.

What I'd rather do is allow our users to send mail through our servers, probably through SASL.

But the SPF record is a temporary bandaid.

Jeff

 

[Dax]

"v=spf1 ~all"

It would seem to me, that a better default value to use would be "v=spf1 a mx ~all". That would correctly identify the authorized servers in many cases, while still leaving it non-strict.

I also think it is important to let users set their own SPF records, should they have the knowledge and desire. Would it be difficult to add TXT records to the DNS menu?

 

[nobaloney]

The problem I see with your first idea is that for outgoing email, the mailserver will alwaysl send email from the main IP# of the server, so the "a" will result in a setting which will never be used in many cases, unless the domain uses the main shared IP# of the server.

The same problem occurs by default for the mx setting, since by default the mx in DirectAdmin points to the main domain name, which for many sites doesn't use the shared server IP#.

So there are many cases where the a and the mx are completely superfluous.

However, in thinking about it, I feel pretty sure about both your ideas, as long as your mx servers are also outgoing email servers. If they're not, then I'm not sure I'd want them listed.

Jeff

 

[Dax]

Adding the a and mx to the default SPF will be appropriate for some significant percent of users. Plus, their addition will normally do no harm for those where they aren't used; since they will typically refer to servers that are in "friendly hands".