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 violation
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 interpretation:
550 5.7.1 <[A.B.C.D]> blah blah Hello command rejected blah blah...
[1] https://www.flickr.com/photos/sluggerotoole/153603564/
Syntax errors in SMTP are reported with 50x basic error codes, not 55x
error codes. And https://tools.ietf.org/html/rfc3463#section-3.8
defines 5.7.1 as:
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
damage.
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp