Re: IETF Policy on dogfood consumption or avoidance - SMTP version

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/22/2019 1:45 AM, Valdis Klētnieks wrote:>
As it turns out, it wasn't rejecting on that basis, it was rejecting on a "not
having a FQDN is a very strong spam signal" policy basis and erroneously
issuing the wrong message.

If the SDO receiver did a PTR lookup for the existence of a FQDN, I can see the beginnings of a justification related to the SMTP spec and a MTA issuing an ip-literal when a FQDN exist.

But the reality is the SDO receiver does not do a PTR check to see if a FQDN even exist. I tested this case by using a machine without a PTR record. It is doing a flat out rejection of "EHLO [ip-literal]" usage.

Given that there were *two* rules involved, one of which *did* flag an actual
protocol violation, I'm willing to accept it's just a cut-n-paste error that
nobody actually noticed for a decade or so...

And what would be the message for the human?

550 Please use a FQDN since one exist.
550 IP literals are no longer acceptable at the site.

or since its not doing a PTR check:

500 Please use a non-ip-literal. Junk host names are valid. We won't check.

And maybe it's time to let that "address literal" sail into the sunset.

In my view, one server behavior, SDO or not, should not represent the entire world-wide community of valid mail bots that exist. We really don't have any clue or stats how big this problem really is because so far, its only one server, afaik.

Are you ready to blindly accepts SDO reasons, follow their lead and reject all EHLO [ip-literal] clients? Why not try it and give feedback?

The onus should be on SDO site to prove to the community why the protocol should be changed and why MTA code should be changed.

And if you're a full MTA on the public internet today, and *don't* have a FQDN,
you're going to have a really bad day in 2019, *totally notwithstanding what
the RFCs say about how it's totally legal*.

In the 16 yrs of using CBV, I haven't had seen a problem nor received a report from any customer except for two cases I found; this recent flat out rejection of ip-literals by the SDO site and another broken receiver who didn't like the HELO command and was enforcing EHLO. It had no problem with using IP Literals as long as it with the EHLO command.

What consenting MTA's do inside a walled garden is, of course, totally
up to the administrators involved.  They can use X.400 for all the rest
of the net cares. We passed the point of a significant divergence between
"what works in a walled garden" and "what works in the wild" at least
a decade ago. And at *some* point, that's a big pile of technical debt
that's going to need to be paid back. At this point, the least bad option
is probably producing an updated rfc5321/5322 that documents the
protocol, and a BCP/guidance document of "but here's what you need
to be doing to ensure you can survive in the wild".

I have a difference of a technical opinion for this particular item related to the adherence to a protocol feature of nearly 40 years. I don't see a justification for what is a uncommon behavior with standard SMTP servers.


If the SDO feels the SMTP community should eliminate it for the sake of the public SMTP service good, then propose it, show evidence, show legitimate justifications in the IETF-SMTP to convince implementators to change their code ($$$) and also update the SMTP specs. Again, its not even doing an PTR check to see if an FQDN exist to use this as a reason. So whatever proposal is offered has to make common IETF engineering sense. This one does not.

If you believe we should tighten SMTP, enforce no ip-literals, always a FQDN, then why just raise the bar and go for the maximum payoff possible - the big bang, and officially begin to validate FQDN for 100% correctness, no exception. After all, with the way it is is now done by the SDO, if others begin to follow their lead, disallowing ip-literal but allow invalid FQDNs, this would be encouraging more bad behavior and fact less spam detection.

--
HLS





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux