On 12/16/2019 4:46 PM, Jay Daley wrote:
Hi
While there is not unanimous consensus, I think the mood is clearly to
leave this as an operational decision.
Hi,
The operation decision appears to be inconsistent in its erroneous and
RFC2821 violating application of an aggressive mail filter.
Let me state, that am implementer and commercial mail package,
operators always have the last say and I am always for local policy
considerations.
But here is I see it:
1) Yes, everyone agree the response text needs to be fixed up, but
2) It is in fact a violation of RFC2821/5321 specification when a
rejection is applied by a server to a perfectly valid ip-literal per
specification, and
3) It lacks consistency in its operational decision on what Client
Mail/Host Names are rejected or accepted.
If a rejection is going to apply to ip-literals, hence enforcing a
FQDN, then at the very least, it should validate the FQDN.
The mail.ietg.org servers appears to accept any FQDN including a
existing FQDN which does not match the connecting IP address and a
non-existing FQDNs:
The mail.ietf.org returns
EHLO [ip-literal] <- not acceptable
EHLO santronics.com <- acceptable, but non-matching IP::DOMAIN
EHLO foo.santronics.com <- acceptable, but not existing domain
Yet, it does not validate the FQDN. Why?
Because we have a history of this FQDN check to be unreliable, hence
why a MUST NOT reject on the basis of a HELO/EHLO check.
Finally, imeo, to prudent implementators who follow the IETF cogs to
engineer consistent and logical protocols, it is expected the IETF
mail servers themselves to also follow the same rules asked of them.
If the operational decision remain to reject ip-literals but accept
invalid FQDNs, then the specifications will need to change. If the
FQDN are now validity and rejection occurs for mismatches, then the
specification needs to change. So to me, its beyond being an
operational decision.
The next implementer will read what is written it says MUST NOT, not
SHOULD NOT, or MAY NOT. We pay close attention to the protocol design
elements. The IETF should also.
Thanks
--
HLS
