Re: The dogfood discussion (was: Re: IETF Policy on dogfood consumption or avoidance - SMTP version)

[Viktor Dukhovni <[e-mail]>]

> On Dec 22, 2019, at 5:30 PM, John C Klensin <[e-mail]> wrote:
> 
> But we don't know... and, if
> Hector had not been a very long-term participant who knew which
> list to ask on and had alternate posting mechanisms readily
> available, it is reasonable to assume we would not have heard
> about his case either.

One relevant point here is perhaps that (based on my understanding
of Hector's posts) even his MTA did not actually use address literals
when posting messages *to* IETF lists, and his messages to IETF lists
were getting through just fine.

The problem was that his callback verification system (variously called
CBV, sender address verifcation, ...) used address literals, and so
messages coming *from* IETF lists to him were rejected by his server
when callback probes were rejected by mail.ietf.org.

In my view, this makes the problem report more marginal.

I also posit that the IETF mail servers are not running some bespoke
version of SMTP that is inconsistent with IETF standards.  The
"550 5.7.1" reject is a clear policy reject, and the MTA adds further
context that makes it clear that the policy rejects the EHLO command
on the basis of the EHLO name.

The poorly chosen additional text added by the administrator has
since been amended, and the rejects now take the form:

  550 5.7.1 <[192.0.2.1]>: Helo command rejected: Policy violation

The policy in question is presumably effective, and can make it
possible to avoid more fragile and less transparent content-based
policies downstream.

Address literals remain a valid part of the SMTP protocol, useful
between minimal SMTP clients (special-purpose appliances of various
sorts, and some MUAs) and their configured SMTP relays (smarthosts).

They are much less useful between the SMTP relays and SMTP servers
operated by others on the public Internet.  The same applies to
sending from machines with no PTR records, from sender addresses in
non-existent domains, or non-FQDN HELO names that are not address
literals...

While Hector feels passionately[1] that he should not have to change
the CBV code he's been using for over a decade, others may well view
that code as a potential abuse vector in its own right, that masks
the origin of directory harvesting attacks.

I, for one, do not share his passion for keeping address literals
a viable HELO name form for MTA-to-MTA traffic across the public
Internet, nor do I feel that a policy that rejects these, even at
mail.ietf.org is a failure of the IETF to adhere to its own
standards.

On the contrary, I prefer filters that use static criteria over
fragile content filters, unavoidably error-prone (but sadly needed
RBLs), etc.  If the HELO filters work well enough (block
non-negligible quantities of junk, don't block non-negligible
quantities of legitimate email, allow the sending system to
generate a local bounce back to the message sender) they are
precisely the sort of filters that should be used when available,
and while still effective.

-- 
	Viktor.

[1] Along with a passion about the purported "inconsistency" of
    blocking IP literals, while allowing unvalidated FQDNs.  This
    would be a valid critique if the aim were to police protocol
    correctness, but since the aim is merely to cheaply block
    traffic from clients effectively don't resemble an MTA, there
    is no inconsistency, policing FQDN "validity" is not effective.

    Of course MTAs should have valid HELO FQDNs, these could even be
    useful some day in support of client-side DANE TLSA records,
    hardening the message relay path with hop-by-hop client
    authentication, when possible, but that's falls squarely outside
    the issue at hand.