Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3
2021-04-02 10:10:11
Affair? Nice!! <g>
As a SMTP developer, I have designed my DNS resolver to resolve CNAME
even if it came during a MX query simply because they do exist in the
wild and who I am to argue with a customer when it came to delivering
mail, "Oh I'm sorry but you can't sent mail because the destination
is not following the rules." CNAME is expanded as part of the IP
expansion process to get a sorted list and all that before a Round
Robin outbound session login begins. RFC2181 does suggest this can be
expensive and I will say, that is probably mostly true back in 1997
where even a PTR was expensive -- it is accepted today, if fact,
increasingly required by many mail host.
I don't follow RFC8461 so I have no generated no rules or a higher bar
for MX-TST technical protocol requirements. I don't know how it works
(didn't read it). But overall, administrators applying 8461 believing
using a CNAME for MX as is reason for rejecting a transaction is a
local policy concept. It can happen. Even the ietf.org, a SDO, has
applied SPAM associations with mail clients using legal EHLO
[ip-literal] SMTP usage. I am not going to change my SMTP compliance
because the ietf.org mail administrators has refused to follow the
RFC2821/5321 SMTP specs first and subjectively apply an general
ip-literal usage restriction. Its a local policy. In our SMTP
client, we send public DNS host name first, fallback to an ip-literal
and/or an local site override is used. Doing a CBV check, an
ip-literal is used to optimized CBV preparation. We white listed the
ietf.org site to stopped the CBV check on them.
Overall, Postel's law!!
"Be conservative in what you send, be liberal in what you accept"
If the receiver administrative policy is causing a pain and they don't
see that you may not be the only one with MX->CNAME records and they
do exist, they won't make an exception, then you're only left with one
thing - comply with the 2181 specification.
Good luck with your affair!! <g>
On 3/31/2021 5:44 PM, Kristijonas Lukas Bukauskas wrote:
Hello,
I'm having an affair with one of the vendors as a sending MTA,
honoring MTA-STS (RFC 8461). Their response:
1. Our TDS validation shows MX lookup for n0.lt returns
*n0.lt* instead of*mx.n0.lt*. It is consistent with what we
are seeing with production.
/remote server(451 4.4.8 MX hosts of 'n0.lt' failed MTA-STS
validation.)' 3/24/2021 3:36:19 PM - Server at n0.lt
(0.0.0.0) returned '450 4.4.317 Cannot connect to remote
server [Message=451 4.4.8 MX hosts of 'n0.lt' failed MTA-STS
validation.] [LastAttemptedServerName=*n0.lt]*/
2. We can confirm that customer is not RFC compliant with MX
pointing to a CNAME and we don't think it is worth to change
the logic to accommodate that.
3. Customer does have an easy fix on their side, just to modify
their STS Policy to include n0.lt as one of the supported MX
record.
My objections:
I'm familiar with a general prohibition, pursuant to RFC 2181 §
10.3 <https://tools.ietf.org/html/rfc2181#section-10.3>, for MX
records to point to CNAMEs. Despite that, I do not believe that it
should affect MX host validation in accordance with RFC 8
<https://tools.ietf.org/html/rfc8461#section-4.1>461§4.1
<https://tools.ietf.org/html/rfc8461#section-4.1>when selecting a
target MX host, for the reasons of:
1.
RFC 2181 is an RFC on Clarifications to the DNS Specification,
not SMTP.
2.
Selecting an MX target host is regulated in a different RFC,
namely and specifically in RFC 5321 §5.1
<https://tools.ietf.org/html/rfc5321#section-5.1>:
If MX records are present, but none of them are usable, this
situation MUST be reported as an error.<...> When a domain
name associated with an MX RR is looked up and the associated
data field obtained, the data field of that response *MUST
contain a domain name*. That domain name, when queried, MUST
return at least one address record (e.g., A or AAAA RR) that
gives the IP address of the SMTP server to which the message
should be directed. _*Any other response, specifically
including a value that will return a CNAME record when
queried, lies outside the scope of this Standard*_. The
prohibition on labels in the data that resolve to CNAMEs is
discussed in more detail in RFC 2181, Section 10.3 [38]
2.
Thus, the prohibition of CNAMEs is *NOT* an SMTP or MTA-STS
issue. As per the RFC 5321 §5.1, which is used to select an MX
target host, pursuant to RFC 8461 §4.1 (MX Host validation),
vendors are *NOT* allowed to choose a different host name (in
my scenario, n0.lt instead of mx.n0.lt which is found in MX
record). The situation MUST be reported as an error, if none of
the found records are usuable. That MUST happened even if the
target domain has not deployed MTA-STS. And this doesn’t seem
to be the case. When MTA-STS is not deployed, Microsoft, as a
sending MTA doesn’t return any errors.
3.
No major providers (including, but not limited to Gmail) nor
publicly available MTA-STS tests (including, but not limited to
My Email Communications Security Assessment (MECSA) by European
Commission’s Joint Research Center) doesn’t select n0.lt
instead of mx.n0.lt which is found in MX record nor does it
show any errors, suggesting my interpretation of different RFCs
is most likely correct.
As advised by one of the authors of RFC 8461, I'm reaching out to
the IETF SMTP list for your opinions, namely if MTA-STS, in theory,
should fail to validate if an MX points to a CNAME.
Any insights would be much appreciated and thanked in advance. :)
--
Regards,
Kristijonas
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3, (continued)
- Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3, John R Levine
- Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3, Arnt Gulbrandsen
- Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3, Mark Andrews
- Re: [ietf-smtp] on liberality, was MTS-STS_validation, John Levine
- Re: [ietf-smtp] on liberality, was MTS-STS_validation, Dave Crocker
- Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3, Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3, John C Klensin
- Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3, Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3, Sam Varshavchik
- Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3, Kristijonas Lukas Bukauskas
Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3,
Hector Santos <=
|
|
|