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