ietf-smtp
[Top] [All Lists]

[ietf-smtp] ietf.org SMTP server "RFC2821 Violation" for EHLO ip-literal.

2019-12-01 13:13:15
Can anyone confirm why the following session would be an "RFC2821 Violation" as issued by the ietf.org SMTP server?

220 ietfa.amsl.com ESMTP
EHLO [A.B.C.D]
250-ietfa.amsl.com
250-PIPELINING
250-SIZE 67108864
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250 8BITMIME
MAIL FROM:<>
250 2.1.0 Ok
RCPT TO:<ietf-bounces(_at_)ietf(_dot_)org>
550 5.7.1 <[A.B.C.D]>: Helo command rejected: RFC2821 violation
QUIT
221 2.0.0 Bye

The client connection IP is A.B.C.D. It matches the EHLO [A.B.C.D] ip-literal input. PTR records exist for the IP A.B.C.D. In this mail app, using the IP literal is preferred.

So what RFC2821 violation could it be complaining about?

Both RFC 2821/5321 clearly indicate an verification fail MUST NOT be a reason for rejection. Yet as we know, the PTR requirement has been increasingly enforced at various sites.

Since the server used RFC2821 as a reference, I see these two paragraphs in conflict:

   RFC2821 Section 4.1.4 Order of Commands

   The SMTP client MUST, if possible, ensure that the domain parameter
   to the EHLO command is a valid principal host name (not a CNAME or MX
   name) for its host.  If this is not possible (e.g., when the client's
   address is dynamically assigned and the client does not have an
   obvious name), an address literal SHOULD be substituted for the
   domain name and supplemental information provided that will assist in
   identifying the client.

   An SMTP server MAY verify that the domain name parameter in the EHLO
   command actually corresponds to the IP address of the client.
   However, the server MUST NOT refuse to accept a message for this
   reason if the verification fails: the information about verification
   failure is for logging and tracing only.

While RFC 5321 has revised the two paragraphs, the protocol semantics, I believe, remain the same.

In the 1st paragraph, there is a MUST for using a host name, if possible. This means if one or more PTR records exist for the connecting IP, one of host records returned MUST be used for the EHLO command.

In the 2nd paragraph, there is a MUST NOT refuse for verification fails. This has been the standard expectation for SMTP servers for many years.

Obviously, this would be a candidate for a RFC5321bis revision where it would say "the server MAY refuse." But there are a number of mail app scenarios where the IP literal is legitimately preferred even when PTR record(s) exist.

Comment??


--
HLS


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp