Re: Mail to CNAME a thing?
Gasoo <[email protected]> Mon, 19 Feb 2018 16:44:40 +0100
| Newsgroups | gmane.org.operators.swinog |
|---|---|
| Message-ID | <[email protected]> |
Hi
I might be wrong but according to RFC 2821 it is ok to use a CNAME if
the target is resolvable to A or MX.
3.6 Domains
Only resolvable, fully-qualified, domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or A RRs (as discussed in section 5) are
permitted, as are CNAME RRs whose targets can be resolved, in turn,
to MX or A RRs. Local nicknames or unqualified names MUST NOT be
used.
However, the target domain in this case is not working correctly.
Short:
The nameserver konfiguration at the .com level is wrong.
OR
The configuration of the nameservers at the domain level is wrong
See https://zonemaster.net/test/60c7bac42eb6e304
Long:
The Domain resolves to a CNAME:
;; QUESTION SECTION:
;accountprotection.microsoft.com. IN A
;; ANSWER SECTION:
accountprotection.microsoft.com. 2877 IN CNAME mail.msa.msidentity.com.
;; AUTHORITY SECTION:
msa.msidentity.com. 7200 IN SOA usw1.akam.net.
hostmaster.akamai.com. 1518736843 43200 7200 604800 7200
The domain msa.msidentity.com has the follwoing NS records at the TLD
servers:
;; QUESTION SECTION:
;msa.msidentity.com. IN NS
;; AUTHORITY SECTION:
msidentity.com. 172800 IN NS usw1.akam.net.
msidentity.com. 172800 IN NS eur2.akam.net.
msidentity.com. 172800 IN NS use2.akam.net.
msidentity.com. 172800 IN NS ns1-169.akam.net.
msidentity.com. 172800 IN NS ns1.p09.dynect.net.
msidentity.com. 172800 IN NS ns3.p09.dynect.net.
msidentity.com. 172800 IN NS ns2.p09.dynect.net.
msidentity.com. 172800 IN NS ns4.p09.dynect.net.
On the *.akam.net servers it has only the *.akam.net servers as NS:
; <<>> DiG 9.11.2 <<>> @usw1.akam.net. msa.msidentity.com. ns +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44395
;; flags: qr aa; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 12
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;msa.msidentity.com. IN NS
;; ANSWER SECTION:
msa.msidentity.com. 172800 IN NS use2.akam.net.
msa.msidentity.com. 172800 IN NS eur2.akam.net.
msa.msidentity.com. 172800 IN NS usc3.akam.net.
msa.msidentity.com. 172800 IN NS ns1-169.akam.net.
msa.msidentity.com. 172800 IN NS use5.akam.net.
msa.msidentity.com. 172800 IN NS usw1.akam.net.
msa.msidentity.com. 172800 IN NS ns1-68.akam.net.
msa.msidentity.com. 172800 IN NS eur4.akam.net.
On the *.dynect.net servers the zone is different:
; <<>> DiG 9.11.2 <<>> @ns1.p09.dynect.net. msa.msidentity.com. ns +norec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44314
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;msa.msidentity.com. IN NS
;; AUTHORITY SECTION:
msidentity.com. 1800 IN SOA ns1.p09.dynect.net.
aadnetsre.microsoft.com. 23844 3600 600 604800 1800
It seems that not all of those NS have the same zone data.
The *.akam.net servers answer to MX queries:
; <<>> DiG 9.11.2 <<>> @usw1.akam.net. mail.msa.msidentity.com. MX +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4484
;; flags: qr aa; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mail.msa.msidentity.com. IN MX
;; ANSWER SECTION:
mail.msa.msidentity.com. 7200 IN MX 5 mx1.hotmail.com.
mail.msa.msidentity.com. 7200 IN MX 10
accountprotection-microsoft-com.mail.protection.outlook.com.
mail.msa.msidentity.com. 7200 IN MX 5 mx3.hotmail.com.
mail.msa.msidentity.com. 7200 IN MX 5 mx4.hotmail.com.
mail.msa.msidentity.com. 7200 IN MX 5 mx2.hotmail.com.
;; Query time: 9 msec
;; SERVER: 23.61.199.66#53(23.61.199.66)
;; WHEN: Mon Feb 19 15:46:49 CET 2018
;; MSG SIZE rcvd: 212
But the *.dynect.net. servers dont:
; <<>> DiG 9.11.2 <<>> @ns2.p09.dynect.net. mail.msa.msidentity.com. MX
+norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45448
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mail.msa.msidentity.com. IN MX
;; AUTHORITY SECTION:
msidentity.com. 1800 IN SOA ns1.p09.dynect.net.
aadnetsre.microsoft.com. 23844 3600 600 604800 1800
;; Query time: 17 msec
;; SERVER: 204.13.250.9#53(204.13.250.9)
;; WHEN: Mon Feb 19 15:48:00 CET 2018
;; MSG SIZE rcvd: 126
So depending on which server the query goes to, it responds with an MX
record or not.
Regards
Stephan
On 02/19/2018 01:12 PM, Ralph Krämer wrote:
> Hi Markus,
>
> [TL;DR] ;-)
>
> a MX record pointing to a CNAME is generally not supported and a bad idea.
> I am sure this is mentioned somewhere in one of the RFCs - but I currently have no time to look this up.
>
> A MX should always point to a A record.
>
> kind regards
>
> Ralph
>
> ----- Am 19. Feb 2018 um 8:57 schrieb Markus Wild [email protected]:
>
>> Hi there,
>>
>> I've just come across a weird mail reception problem of some mails from
>> Microsoft. Our servers insist that
>> a specified MAIL FROM address can be resolved correctly, and this usually boils
>> down to the following checks
>> on the domain-part of the email-address specified:
>> - is there an MX? Does the target resolve using an A record (not a CNAME), and
>> does it resolve to a publically
>> reachable address (not RFC1918 or localhost etc)
>> - if there is no MX, is there an A record that fulfils the same criteria as the
>> MX target above?
>> - if none of these are true, the address is considered to be invalid and mail is
>> rejected
>>
>> Since about Feb 15, I've now come across mails from
>> [email protected] that
>> get rejected. When I manually perform the above steps, I can see why, and I also
>> see a first: the domain part is
>> actually a CNAME, something I've not encountered mentioned in standards as being
>> a legal way to perform address
>> resolution when delivering email. But, I also don't recall reading about rules
>> that explicitly deny this, contrary
>> to the very explicit rules that for example deny having MX point to CNAME. The
>> domain setup here is borked in multiple
>> ways however:
>>
>> $ host -t mx accountprotection.microsoft.com
>> Host accountprotection.microsoft.com not found: 3(NXDOMAIN)
>>
>> $ host -t a accountprotection.microsoft.com
>> Host accountprotection.microsoft.com not found: 3(NXDOMAIN)
>>
>> BUT:
>>
>> $ host -t cname accountprotection.microsoft.com
>> accountprotection.microsoft.com is an alias for mail.msa.msidentity.com.
>>
>> and even if we should allow use of a CNAME here, we'd have to apply the same
>> rules as stated initially on the
>> CNAME target, and these fail as well:
>>
>> $ host -t mx mail.msa.msidentity.com.
>> Host mail.msa.msidentity.com not found: 3(NXDOMAIN)
>>
>> $ host -t a mail.msa.msidentity.com.
>> Host mail.msa.msidentity.com not found: 3(NXDOMAIN)
>>
>> So, what's your take on this? Does someone see a legal way to resolv this
>> sender, that I've missed? Am I right in
>> considering these addresses to be unresolvable and thus reject these mails? Who
>> would I have to report this to at
>> Microsoft to have any chance of a human person looking at the issue?
>>
>> Cheers,
>> Markus
>>
>>
>> _______________________________________________
>> swinog mailing list
>> [email protected]
>> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
>
> _______________________________________________
> swinog mailing list
> [email protected]
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
_______________________________________________
swinog mailing list
[email protected]
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog