Re: [swinog] Mail to CNAME a thing?
Cheers Jeroen,
> If you are anti-spam, don't bother checking this (dom.com A); anybody
> who wants to receive mail will have an MX, if not, let them join the
> 2000s...
There are actually quite a few (definitely more than white noise) senders that
don't have MX, and only use A records.
Many of these are from what I call "isp-in-a-box" resellers, who a) don't know
how to properly setup their servers, and
b) since web-server-address and mail-server-address are the same, things "just
work" if they only point their domain
name to the IP address of their virtual server. While I don't think that's a
good setup, I'm not at the liberty of
denying our customers to receive mails from such senders :)
> Also, instead of bothering with the MX Lookup, verify and enforce SPF,
> DKIM and DMARC instead, they are meant for checking against the envelope
Oh, if a sender deliberately wants to break his mail delivery and defines such
records, you can be sure we'll test for
them, and classify the mail as SPAM if they fail. We don't encourage their use,
but you bet we'll enforce them if
they're set.
> From, MXs are not. Non-existence of a MX on a domain does not mean it
> does not get used for sending mail; thus you might have a small false
> positive rate there... (which you might chose to accept, you are the
> receiving end, hope you have an informative rejecting message ;) )
>
> Spammers will make sure that MX, SPF, DKIM and DMARC are all configured
> btw; they only really 'resolve' spoofing issues.
Yes, I consider SPF and friends evil, as I pointed out above, but will
definitely enforce them when provided. My stance
on the MAIL FROM address is: if we accept a mail for delivery/relay, we also
accept the responsibility to deliver back
DSN mails to the sender, if there is a problem with the finaly delivery of the
mail later on. For that, we need a
valid, usable sender address. If there isn't one, we won't accept the mail. It
is also a very effective tool to weed
out many spammers without resorting to content analysis (and is thus much more
efficient, as well). MX to localhost?
bye bye :)
> I assume you also allow '<>' for DSNs?
I do, but I severely restrict what we allow in these mails, their size, only a
single recipient, etc.
> If you do the above, you might want to check for "MX .", this indicates
> a domain that will never send mail as per RFC7505:
>
> https://tools.ietf.org/html/rfc7505
I don't have to check for this explicitly, because it will fail the A lookup
check, so it will be considered an invalid
domain for an email address. But thanks for the pointer, didn't know about this
rfc.
> But again: MX is for _receiving_, not _sending_ (From) thus checking it
> is a bit wrong, but at your prerogative.
I explained my reasoning above, why we do verify the sender like this.
> Last note: do _not_ use 'host' for debugging DNS related issues, always
> use the very useful 'dig' tool, or if you want use 'drill' instead.
> ('host' hides various error situations and does not properly show what
> you are actually querying...)
I actually do use dig normally, I used "host" here because the output is much
more terse and thus better suited to
explain a problem and keep the description smallish (my mail was too long
already for some people;-))
Ciao,
Markus
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Mail to CNAME a thing?
On 2018-02-19 12:57, Markus Wild wrote:
> 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 you are anti-spam, don't bother checking this (dom.com A); anybody
who wants to receive mail will have an MX, if not, let them join the
2000s...
Also, instead of bothering with the MX Lookup, verify and enforce SPF,
DKIM and DMARC instead, they are meant for checking against the envelope
From, MXs are not. Non-existence of a MX on a domain does not mean it
does not get used for sending mail; thus you might have a small false
positive rate there... (which you might chose to accept, you are the
receiving end, hope you have an informative rejecting message ;) )
Spammers will make sure that MX, SPF, DKIM and DMARC are all configured
btw; they only really 'resolve' spoofing issues.
[..]
> - if none of these are true, the address is considered to be invalid and mail
> is rejected
I assume you also allow '<>' for DSNs?
If you do the above, you might want to check for "MX .", this indicates
a domain that will never send mail as per RFC7505:
https://tools.ietf.org/html/rfc7505
I set that for every domain that I don't actually use for mail and quite
a few marketing hosters are pretty good at it too.
But again: MX is for _receiving_, not _sending_ (From) thus checking it
is a bit wrong, but at your prerogative.
Last note: do _not_ use 'host' for debugging DNS related issues, always
use the very useful 'dig' tool, or if you want use 'drill' instead.
('host' hides various error situations and does not properly show what
you are actually querying...)
Greets,
Jeroen
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Mail to CNAME a thing?
Short update on this problem, which should be fixed by now: - I was able to reach the responsible team, and they answered very quickly. I was positively surprised! - They confirmed there's a problem with the zone content on their Dyn nameservers - They then added additional NS records on level msa.msidentity.com to point only to Akamai servers (overriding the 50:50 split for msidentity.com) - The result now is that mail.msa.msidentity.com gets resolved only bei Akamai servers, and should thus resolve reliably. I don't know the reason why they couldn't just fix the zone copy that gets distributed to the Dyn servers, but the workaround fixed the problem at hand, so problem solved :) Congrats to the Microsoft AAD Network SRE team, I didn't hope to get any answer, but they took care of the problem right away! Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Mail to CNAME a thing?
there is actually one DNS service company providing Aname records .. basically a records with following an other A Record the getting notifyed when de A record changes and change the Aname record the very advantage is faster DNS resolve times and eliminating the need of Cname at all. and allows even using an Mailserver behind an Dynamic IP my small input ;) On 19/02/2018 08:46, Markus Wild wrote: Hello Ralph [TL;DR] ;-) sorry about that, but it's not about an MX to a CNAME, it's about the domain part being resolved directly via a CNAME (kind of like having a domain-level CNAME to another domain, except _THAT_ isn't allowed due to shadowing NS and SOA records). With something like "accountprotection.microsoft.com" they're probably not breaking that rule though. When you have time, I'd welcome an answer to my question ;) Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Mail to CNAME a thing?
Cheers Stephan, > 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. True, so guess I'll modify my validation rules according to this. Thanks! > However, the target domain in this case is not working correctly. I've found that inconsistency as well between their 2 main DNS providers. Akamai, using serials that seem to be unix timestamps, returns MX records. dynect.net using sequentially incrementing serials (much lower, Windows DNS? :)) doesn't return any MX. So, it's essentially pretty random whether the address resolves, or not... I've tried to communicate this to aadnet...@microsoft.com, as per: msidentity.com has SOA record ns1.p09.dynect.net. aadnetsre.microsoft.com. 23844 3600 600 604800 1800 but some part of me will be very surprised if I'll get any answer back from that address... Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Mail to CNAME a thing?
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
Re: [swinog] Mail to CNAME a thing?
Hi Markus, it looks like Microsoft has configured their DNS zones in a creative way and I would expect them to come up with an RFC that justifies their creative way to "rape" DNS at a later time. For now, the way they have set it up looks unsupported to me and I doubt that they get any mails beside from servers using their own s*it that might be compatible to that approach. To get this solved, I would recommend to open a ticket with Microsoft and file a bug. Sorry, I've given up on debugging the outcome of DNS rapists ;-) cheers Ralph - Am 19. Feb 2018 um 13:46 schrieb Markus Wild swinog-l...@dudes.ch: > Hello Ralph > >> [TL;DR] ;-) > > sorry about that, but it's not about an MX to a CNAME, it's about the domain > part being resolved > directly via a CNAME (kind of like having a domain-level CNAME to another > domain, except _THAT_ isn't allowed > due to shadowing NS and SOA records). With something like > "accountprotection.microsoft.com" they're probably > not breaking that rule though. > > When you have time, I'd welcome an answer to my question ;) > > Cheers, > Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Mail to CNAME a thing?
Hello Ralph > [TL;DR] ;-) sorry about that, but it's not about an MX to a CNAME, it's about the domain part being resolved directly via a CNAME (kind of like having a domain-level CNAME to another domain, except _THAT_ isn't allowed due to shadowing NS and SOA records). With something like "accountprotection.microsoft.com" they're probably not breaking that rule though. When you have time, I'd welcome an answer to my question ;) Cheers, Markus ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Mail to CNAME a thing?
Am 19.02.2018 um 13:12 schrieb Ralph Krämer: > I am sure this is mentioned somewhere in one of the RFCs - but I currently > have no time to look this up. rfc1912 references in "CNAME records" section > Don't use CNAMEs in combination with RRs which point to other names > like MX, CNAME, PTR and NS. (PTR is an exception if you want to > implement classless in-addr delegation.) to rfc974, which sez in "Minor Special Issues" section > Note that the algorithm to delete irrelevant RRs breaks if LOCAL has > a alias and the alias is listed in the MX records for REMOTE. (E.g. > REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This > can be avoided if aliases are never used in the data section of MX RRs I know of several big esp that reject if rcpt mx is resolved by a cname-rr Cheers tobi ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Mail to CNAME a thing?
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 swinog-l...@dudes.ch: > 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 > account-security-nore...@accountprotection.microsoft.com 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 > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] Mail to CNAME a thing?
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 account-security-nore...@accountprotection.microsoft.com 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 swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
