ietf-smtp
[Top] [All Lists]

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

2019-12-01 13:57:25
Hector,

AFAICT, unless what you have written as "[A.B.C.D]" is not
actually a valid domain literal, it is broken and in more than
one way.  Section 2.3.5 of RFC 5321 seems quite specific that an
address literal in that syntax is allowed.  It says:

        o The domain name given in the EHLO command MUST be either
                a primary host name (a domain name that resolves to an
                address RR) or, if the host has no name, an address
                literal, as described in Section 4.1.3 and discussed
                further in the EHLO discussion of Section 4.1.4.

Similar text appears in RFC 2821, but there is no excuse for a
modern SMTP server to be reporting or rejecting (correctly or
not) on the basis of what 2821 says (or is imagined to say).  It
is disturbing that anything the IETF is running is referring to
2821 and not only because it may reinforce my impression,
mentioned in a different thread, that it is unlikely that anyone
will pay any more attention to a revision of 5321 than they did
to 5321 itself.

Two things are not clear from that text: (i) while the language
describing a domain name requires that the domain be resolvable
with the target RRSet containing an address RR, there does not
seem to be a requirement that whatever is at those address(es)
support an SMTP client or server.  (ii) Similarly, there does
not appear to be a requirement that, if an address literal is
used, that it refer to a system that can be accessed from the
public Internet or that an SMTP client and/or server be
supported there.   Given that EHLO and its arguments are sent
from an SMTP client, I don't see those additional potential
tests (much less clarification(s) that would require them) as
important or even helpful but, if anyone disagrees and we move
forward with 5321bis, please raise the issue then (while noting
that any stronger requirement than a SHOULD would impose a
restriction that was not there before).

If you have seen this as a problem in the wild, please write to
ietf-action(_at_)ietf(_dot_)org, supply documentation the form of logs that
show the actual transaction, and ask that it be fixed.

best,
   john


--On Sunday, December 1, 2019 14:12 -0500 Hector Santos
<hsantos=40isdg(_dot_)net(_at_)dmarc(_dot_)ietf(_dot_)org> wrote:

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??


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