Re: IETF Policy on dogfood consumption or avoidance - SMTP version

[Hector Santos <[e-mail]>]

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