On Dec 14, 2019, at 4:48 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com>
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
Well, my point (perhaps not sufficiently clear) was that the
allusion to RFC2821 was the "blah blah" part of the response
and should not carry any weight. The error is "550 5.7.1"
indicating a policy that rejects EHLO address literals. The
RFC allusion is a distraction.
That leaves two questions. The first is:
* Does the community wish to hold the MTAs hosting IETF lists
to higher standards of accuracy in the free-form text portion
of policy-based failure responses.
If so, someone could ask the AMSL team to update the message text.
I'm not too hung up on the message text, but in this case the
misleading text is unlikely to keep the bad guys from guessing
what they need to do to get around the filter. So in this case
there's little reason to give a more accurate text message.
Major: [...] 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.
Well again, my point was that they are not being rejected as
syntax errors. They are rejected as a matter of access policy.
But, "if it is an address literal, reject it" is clearly prohibited.
That battle is lost, address literals, usually accepted from
authenticated submission users or from clients on local networks
are widely rejected from strangers by inbound MTAs. If the
collateral damage is sufficiently low, and enough junk is stopped,
the tactic will get (and is being) used.
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.
Which brings us to the second, and more important question:
* To what extent is the community willing to stand fast in
the defense of principled interoperability requirements,
even when essentially the only parties benefiting from
this are abusing access?
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
I sympathise with this point of view, but also keep in mind
that there is no RFC police, and RFCs specify what must do
in order to interoperate, but ultimately do not coerce
In practice some aspects of some RFCs have proved unworkable,
or the situation on the ground has changed over time, and
actual systems deviate from the RFCs to achieve the interoperability
they need "in practice".
I don't believe that deviating in some small details from
an 11-year old document (that on the whole has aged quite
well), which in turn is a conservative revision of an
18-year old document, ... amounts to disrespect of the
document as a whole. Things change...
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'm sure you know that doing that often requires a great deal
of effort that may not be commensurate with the reward.
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.
Well, you're working on 5321bis, would you be willing to add
text that states that use of address literals by relays is
now strongly discouraged, because they are not infrequently
rejected by the receiving SMTP server?
I would support such text, it represents operational reality.
It could go in "operational considerations".
ietf-smtp mailing list