Viktor,
I believe we are in agreement with the same principles. But maybe not.
Not sure. I already implied local policy always prevails.
That said, I believe the IETF "operational decision" was incorrect and
inconsistent. To honor it, it may set a negative precedent for future
implementer trust and confidence in protocol design. Is it advocating
others to follow? After all, an SDO did it, so why not across all
systems?
We may have to explicitly embed this clause in the protocol:
A "MUST NOT" protocol element MAY be overridden with "550" Policies.
That is the implication we have here. Keeping in mind that these new
550 policies are generally based on some "Bad Guy" presumptions. It
did not explicitly exist before RFC5321. Previously, 550 was like a
"Catch all" reply code. Since 2003, with GreyListing, SPF, DKIM/SSP,
DKIM/ADSP, DKIM/DMARC, etc, the beauty of these new protocols to help
deal with "bad guys," they were ALL consistent with the written SMTP
specifications. They did not change the SMTP protocol except for one
thing. I was instrumental during RFC2821BIS in proposing and Klensin
adding section 7.9. "Scope of Operation of SMTP Servers." With the
advent of the new DNS TXT-based applications, we needed new SMTP
justifications for rejections. The bar was raised for SMTP compliancy
and correction.
7.9. Scope of Operation of SMTP Servers
It is a well-established principle that an SMTP server may refuse to
accept mail for any operational or technical reason that makes sense
to the site providing the server. However, cooperation among sites
and installations makes the Internet possible. If sites take
excessive advantage of the right to reject traffic, the ubiquity of
email availability (one of the strengths of the Internet) will be
threatened; considerable care should be taken and balance maintained
if a site decides to be selective about the traffic it will accept
and process.
In recent years, use of the relay function through arbitrary sites
has been used as part of hostile efforts to hide the actual origins
of mail. Some sites have decided to limit the use of the relay
function to known or identifiable sources, and implementations SHOULD
provide the capability to perform this type of filtering. When mail
is rejected for these or other policy reasons, a 550 code SHOULD be
used in response to EHLO (or HELO), MAIL, or RCPT as appropriate.
What it needs to update here is to include DATA because of ADSP and
DMARC.
Again, now of the new augmented protocols did not change SMTP.
For me, being consistent allows for raising the bar. In regards to
the new ietf mail policy, if it was consistent with this new 550
policy to reject legitimate ip literals for a yet to be explained
non-reason, it would be more consistent and acceptable, if it also
consistently enforced a correct FQDN using a new 550 policy
justification to reject IP::DOMAIN mismatches. After all a "real" MTA
is expected to use rDNS to obtain the correct FQDN for the sender
machine. No? That is not always optimal. Small lite weight SMTP
clients exist. PTR slows them down. What if there is no PTR record?
After all, again, more inconsistency, are we promoting PTR records
now? For a certain period there, we were discouraging them, in fact, I
think SPF tried to deprecate it. I am not going to bother to confirm
but I recall the debates.
Consistency with everyone "expected" to play by the same rules is
paramount for maximum interoperability and with minimum support. IMO,
this mail.ietf.org odd "operational decision" could drastically change
things because now others will follow.
I am still trying to understand why the legit IP-literal is being
rejected in the first place. I don't see any legit reason for it. Do
you?
Thanks
--
HLS
On 12/17/2019 2:24 PM, Viktor Dukhovni wrote:
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.
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp