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

[Hector Santos <[e-mail]>]

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