SFP howto manuals and procedure to old?

[ikkeben]

Read here why spf as directadmin does it now is maybe a to old way todo it?

While this document from August 30, 2017

https://www.m3aawg.org/sites/default/files/m3aawg_managing-spf_records-2017-08.pdf

For example:

Use of the “a” and “mx” directives§ The use of a and mx directives in SPF records is no longer recommended.

If the domain in question uses a third-party service to host mailboxes, then the service should provide an include directive for the SPF record. Similarly, most websites no longer send email directly from their web servers; they use an email service provider to deliver mail generated by web applications. Again, in this case the vendor should provide an include directive.

§Historically, many SPF generators created records that included a and mx directives by default. As above, these directives should be replaced by ip4/ip6 directives.

M3AAWG Best Practices for Managing SPF Records 6§a and mx directives count against the 10-DNS lookup limit, and can cause security holes when unintentional changes to DNS or compromise of servers lead to accidentally authorization of mail from unintended IPs.

In this howto and probably more.

https://help.directadmin.com/item.php?id=616

 

[factor]

Hey Ikkeben

The RFC is even older but it gives Guidance as well. Yes a and mx are considered wasteful use.

RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1

Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework...

tools.ietf.org

10.1.1

. DNS Resource Considerations

Minimizing the DNS resources needed for SPF lookups can be done by
choosing directives that require less DNS information and by placing
lower-cost mechanisms earlier in the SPF record.

Section 4.6.4 specifies the limits receivers have to use. It is
essential to publish records that do not exceed these requirements.
It is also required to carefully weigh the cost and the
maintainability of licit solutions.

For example, consider a domain set up as follows:

example.com. IN MX 10 mx.example.com.
IN MX 20 mx2.example.com.
mx.example.com. IN A 192.0.2.1
mx2.example.com. IN A 192.0.2.129

Assume the administrative point is to authorize (pass) mx and mx2
while failing every other host. Compare the following solutions:

Best record:
example.com. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.129 -all"

Good record:
$ORIGIN example.com.
@ IN TXT "v=spf1 a:authorized-spf.example.com -all"
authorized-spf IN A 192.0.2.1
IN A 192.0.2.129

Expensive record:
example.com. IN TXT "v=spf1 mx:example.com -all"

Wasteful, bad record:
example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 mx -all"

10.1.2. Administrator's Considerations

There might be administrative considerations: using "a" over "ip4" or
"ip6" allows hosts to be renumbered easily at the cost of a DNS query
per receiver. Using "mx" over "a" allows the set of mail hosts to be
changed easily. Unless such changes are common, it is better to use
the less resource-intensive mechanisms like "ip4" and "ip6" over "a"
or "a" over "mx".

In some specific cases, standard advice on record content is
appropriate. Publishing SPF records for domains that send no mail is
a well-established best practice. The record for a domain that sends
no mail is:

www.example.com. IN TXT "v=spf1 -all"

Publishing SPF records for individual hosts is also best practice.
The host name is generally the identity used in the 5321.HELO/.EHLO
command. In the case of messages with a null 5321.MailFrom, this is
used as the domain for 5321.MailFrom SPF checks, in addition to being
used in 5321.HELO/.EHLO-based SPF checks. The standard SPF record
for an individual host that is involved in mail processing is:

relay.example.com. IN TXT "v=spf1 a -all"

Validating correct deployment is difficult. [RFC6652] describes one
mechanism for soliciting feedback on SPF failures. Another
suggestion can be found in Appendix C.

Regardless of the method used, understanding the ADMD's outbound mail
architecture is essential to effective deployment.

the A and MX check boxes are here.

 

[Richard G]

Well, I read the article but I don't agree about the not recommended use of A or MX records. This is what it says just below the non-recommendation.

Similarly, most websites no longer send email directly
from their web servers; they use an email service provider to deliver mail generated by web
applications.

IMHO this means it really depends on the fact if you are indeed using an email service provider to deliver mail generated by web applicates. But there are still loads of forums and wordpress installations for example which still used the php mail. Or applications which do use an email service provider, but that is the one from their own domain so like smtp.customerdomain.com which is residing at the same server as the website/web-application is.

It has to do with the max 10 spf dns lookups, which can also be check by some sites if there are not too many lookups.
Next to that, I wonder if big providers like Microsoft's hotmail are following the more modern techniques too. In the past I only had the MX record and not the ipv4. The mx record only pointed to that one ipv4. However, it seems sometimes this gave trouble.
After some reading on Google I found that for sending to Microsoft accounts you could best still use MX and ipv4.

So I think for a lot of servers the default from DA is still good.
For a hobby domain I use this one:

v=spf1 a mx ip4:95.xxx.xxx.xxx -all

This does not even get near 5 DNS lookups. It's quite the DA default, except that I used the -all instead of the default ?all at the end.

So it's always good to check your SPF records, but also monitor them so you won't use by accident to little entry's instead of to many.

 

[ikkeben]

@Richard G

Why does for example Google gmail doesn't have "a" and "mx" records in SPF do you think?

This is for them:

v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all

Is only one/two extra lookups is not true while this is only for one mailserver and one mail trying to connect , so also all spammers and much more mails..... so server resources are "overused" where not needed i think.

And this is using Microsoft for spf-a.outlook.com

v=spf1 ip4:157.56.232.0/21 ip4:157.56.240.0/20 ip4:207.46.198.0/25 ip4:207.46.4.128/25 ip4:157.56.24.0/25 ip4:157.55.157.128/25 ip4:157.55.61.0/24 ip4:157.55.49.0/25 ip4:65.55.174.0/25 ip4:65.55.126.0/25 ip4:65.55.113.64/26 ip4:65.55.94.0/25 -all

 

[Richard G]

Why does for example Google gmail doesn't have "a" and "mx" records in SPF do you think?

Because they have a lot more mx records which would cause more then 10 lookups. If you take a look a level higher, at outlook.com where you should be looking, you can see that Microsoft is using includes. And includes -are- counting for the lookups.
So they split up everything in multiple records like a.outlook.com and b.outlook.com and several more, which are again setup with spf ipv4 which do not count against the lookups.
So they ave a good reason to work that way. Same for Google. I presume they already used this for a long time.
I'm interested on how this splitting is done by the way. Multiple TXT records I presume.

I still don't see the difference between mx and ipv4 if you use the website on the same server the mailserver is running on, we're talking about 1 or 2 lookups and I don't see what spammers would have to do with it. Mailserver is easy to find, no matter if you use 1 MX or 1 ipv4 in your spf.
Oke it's not really needed, correct.

Anyway, if the default DA would change from "a mx ipv4:" to only ipv4 and things keep working great (especially mail to Microsoft), I wouldn't mind that change.

 

[ditto]

[cut]Anyway, if the default DA would change from "a mx ipv4:" to only ipv4 and things keep working great (especially mail to Microsoft), I wouldn't mind that change.

On a sidenote and a little off-topic, this remind me of the trouble with Exim 4.93.x, wich was casing problem for anyone using v=spf a mx -all without any IP in the SPF: https://forum.directadmin.com/threads/exim-4-93-has-been-released.59733/post-306226 - so maybe the problem with Exim 4.93.x would be solved if DirectAdmin changed the default SPF to not use a mx in the SPF. However I think it might be best just to wait for Exim to fix the bug.

 

[ikkeben]

Every lookup costs extra.

If one can avoid then less recources are used. also form you server / network parts.

Also for the "climate change" if spoiling no needed counts, if you count al extra none needed lookups in the world together then it makes sense. ( ok it will not save the ...... but still )

Yes or nu BUG with some a mx related in EXIM 4.93.x , is also maybe indication that they don't test anymore ore enough with those parts, while use is no longer recomended for years now.?

 

[Richard G]

while use is no longer recomended for years now.?

It's only just a couple of years, and all SPF generators including the one from MXtoolbox still uses them.

But indeed, if it's not recommended and working the same, it can better be removed anyway.

 

[ikkeben]

It's only just a couple of years, and all SPF generators including the one from MXtoolbox still uses them.

But indeed, if it's not recommended and working the same, it can better be removed anyway.

Richard this is because lot of IT running behind as LIMBURG is with UNI Maastricht to.
they had for example on port 443 for their ns1 and ns2 a

The expiration date of this certificate is 2015-04-24

and lot of leak very old protocols on port 443 and 22

 

[Richard G]

There was a lot more not very good with the IT at the hacked Uni. See my pm.