On Dec 17, 2019, at 2:02 PM, Hector Santos
<hsantos=40isdg(_dot_)net(_at_)dmarc(_dot_)ietf(_dot_)org> wrote:
But here is I see it:
1) Yes, everyone agree the response text needs to be fixed up, but
2) It is in fact a violation of RFC2821/5321 specification when a rejection
is applied by a server to a perfectly valid ip-literal per specification, and
It is not in fact. A receiving MTA can refuse your email for any reason.
As a matter of RFC-compliance it MUST recognize address literals as
valid syntax (which it did by returning a 550 rather than 500 or 501),
but is then free to reject them on policy grounds.
3) It lacks consistency in its operational decision on what Client Mail/Host
Names are rejected or accepted.
This is also not true. It consistently rejects address literals because
doing so carries little risk of false positives (as already explained on
the ietf-smtp list, where the more technical discussion belongs). "Real"
MTAs use domain names. It is as simple as that.
If a rejection is going to apply to ip-literals, hence enforcing a FQDN, then
at the very least, it should validate the FQDN.
No, because enough "Real" MTAs use HELO domain names that don't map to
their own IP address, or any address at all. So the risk of FPs is
too high.
There is no a priori discrimination here, it is all just based on what
one can get away with to reduce spam without blocking a non-trivial
volume of legitimate email.
The mail.ietg.org servers appears to accept any FQDN including a existing
FQDN which does not match the connecting IP address and a non-existing FQDNs:
As they must for operational reasons.
Yet, it does not validate the FQDN. Why?
Because, much as one might want to, too many "Real" MTAs (sending
legitimate traffic) have FQDNs that would fail verification.
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp