[Top] [All Lists]

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

2019-12-14 15:49:17

From my point of view, there are only two flaws in your
reasoning, one minor and one major:

Minor: No matter what is going on, where, and why, I can see
little or no reason for blaming this on RFC 2821. 5321 was
published in October 2008, over eleven years ago and 2821 only
seven years before that.  If someone claimed that this was due
to the much-older RFC 821, I'd believe them, but then they would
presumably be treating EHLO as a syntax error and not returning
the type of response specified in 2821 (or 1869 and its

Major: There is a good deal of language in 5321 (most of it
carried forward exactly from 2821) that says, in essence, that
if following particular provisions of the standard causes Bad
Things to happen operationally, then it it ok to deviate from
those provisions for self-protection. The standard deliberately
does not say so, but the WG very much had attacks by spammers in
mind when those exceptions were specified.  However, there is no
such exception for address literals: 5321 says they MUST NOT be
rejected, at least as syntax errors.  I think I can read 5321 as
allowing rejection because Bad Things have come from particular
IP addresses, or even some closely-related family of them, just
as it is reasonable to reject and EHLO or MAIL command
containing and argument of, e.g., malware-are-us.example.  But,
"if it is an address literal, reject it" is clearly prohibited.
Now, since you mentioned dogs in your explanation, there is a
longstanding principle that, if the IETF wants its standards to
be taken seriously, we are obligated to eat our own dog food.  I
think that dog food consumption principle, viewed very
pragmatically and in terms of the IETF's desire to have its work
taken seriously, suggests that, even if every other mail server
on the Internet is rejecting address literals, we must not do
so.  For us, the proper remedy if a provision of a standard has
become unworkable is an I-D that changes that provision and gets
IETF consensus for doing so.  I haven't seen an I-D containing
that proposal yet whether from you, from the members of the IETF
leadership who decided that address literals be rejected, or
from anyone else.


--On Saturday, December 14, 2019 15:45 -0500 Viktor Dukhovni
<ietf-dane(_at_)dukhovni(_dot_)org> wrote:

On Dec 1, 2019, at 6:34 PM, Valdis Klētnieks
<valdis(_dot_)kletnieks(_at_)vt(_dot_)edu> wrote:

550 5.7.1 <[A.B.C.D]>: Helo command rejected: RFC2821

What's been lost in this discussion, is that plainly the MTA
is NOT reporting a syntax error.  Yes the MTA is Postfix, and
no Postfix does not reject address literals as a built-in
feature, that sort of access policy is something the
administrator would have to craft for himself.  The apparent
syntax error is just an illusion suffered by speakers of
English.  A dog[1] would arrive at a more correct

  550 5.7.1 <[A.B.C.D]> blah blah Hello command rejected blah


Syntax errors in SMTP are reported with 50x basic error codes,
not 55x error codes.  And defines 5.7.1

      X.7.1   Delivery not authorized, message refused

         The sender is not authorized to send to the
destination.  This          can be the result of per-host or
per-recipient filtering.  This          memo does not discuss
the merits of any such filtering, but          provides a
mechanism to report such.  This is useful only as a
permanent error.

The fact that a system administrator happened to decorate the
policy rule with misleading English text, does not
fundamentally alter the nature of the response.

Sadly, on the Internet, if botnets are found to use HELO
address literals with non-trivial frequency, but "legitimate"
MTAs almost never do, and are often held to "a higher
standard" (e.g. Google placing stringent requirement on
relaying via IPv6), then sysops are unsurprisingly
implementing various stop-gap measures to reduce the quantity
of junk accepted by their systems.

The text messages that follow the numeric codes are sometimes
even deliberately non-specific.  That's life.  This particular
case was actually pretty usable, clearly the receiving MTA
does not accept address literals in the HELO, whether or not
that's required by some RFC the administrator may have been
too busy to read.

And that's fine, provided on balance rejecting address literals
sufficiently reduces junk in IETF lists, with little collateral

ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>