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

[Eliot Lear <lear@xxxxxxxxx>]

Hi John,

On the general issue, as the late Brian Kantor said, RFCs serve us best when they document existing practice.  This is entirely in accord with the “running code” part of our mantra: if network needs dictate that the RFC not be followed to the letter, then so be it.  I would actually like that we are demonstrating this point and reenforcing that our standards are voluntary, but for the fact that I don’t think the standard was substantially violated.  That’s my second point.

If one looks at RFC 5321, there are three reasons to think that really the standard does not prohibit the behavior being described.  First, the text in 4.1.4 doesn’t actually prohibit the rejecting literals.  Here is what is said:

   If the EHLO command is not acceptable to the SMTP server, 501, 500,

   502, or 550 failure replies MUST be returned as appropriate.

At this point in the transaction, it may not be readily apparent that the EHLO indeed is unacceptable.  That’s because the server may need to gather more information, such as the recipient, in order to check against SPF records or other inputs delivered later to make a decision.

   An SMTP server MAY verify that the domain name argument in the EHLO

   command actually corresponds to the IP address of the client.

   However, if the verification fails, the server MUST NOT refuse to

   accept a message on that basis.

That “MUST NOT” conflicts with the most important principle we have to go with in order to defend against spam and malware, as clearly stated in Section 7.9:

    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.

And so the server chose to reject a message.  I would add that an erratum should be filed to resolve this conflict.

Finally, we cannot CANNOT CANNOT micromanage secretariat and mailing list operations on the IETF list. This does NOT impact open participation, when anyone can get free email service on any number of platforms that work just fine with the IETF.  That this message didn’t meet the extremely low barrier of setting up a PTR record when > 99% of SMTP client connections are best classed as attacks.  That THAT isn’t recognized as THE problem the IETF should work on with regard to email is disturbing.

Eliot

On 16 Dec 2019, at 18:50, John C Klensin <john-ietf@xxxxxxx> wrote:

--On Monday, December 16, 2019 16:18 +0000 Nick Hilliard
<nick@xxxxxxxxxx> wrote:

Glen wrote on 16/12/2019 16:11:

/^[0-9.]+$/             550 RFC2821 violation
/^\[[0-9.]+\]$/         550 RFC2821 violation

In just seconds, I can easily change the messages, or remove
the rules, either with complete ease.

s/RFC2821 violation/policy violation/

+ let's move on.

Nick,

(1) Again, this is more of an issue for the ietf-smtp list than
this one, but, because RFC 5321 says, early in Section 4.1.4,
"If the EHLO command is not acceptable to the SMTP server, 501,
500, 502, or 550 failure replies MUST be returned as
appropriate" and not, e.g., "whenever the server gets around to
it" or "it is ok to wait until after the first RCPT command",
there is still probably a violation of the standard.  Since you
and others are encouraging just changing the error report and
moving on, there is also the mostly-technical question of
whether saying "policy violation" and leaving legitimate senders
to guess what undocumented rule they might have tripped over or
explaining that the problem is with the argument to EHLO (even
though it might encourage the bad guys (including spammers) to
get smarter) is better.

(2) One thing Glen did not mention is that, noting that it is
hard to imagine that fixing something that has been in place and
unchanged for a decade is a screaming emergency, I encouraged
him to not rush to make changes until some consensus emerged,
particularly on the ietf-smtp list, as to whether the right
solution was to tune the error message, to remove the check, or
do something else _and_ until whatever mechanism is used to tell
him, as a vendor, what "we" want him to do makes a decision and
revises the instructions (or not).

(3) Once again, it is the apparent violation of the standard by
an IETF server that caused me to raise the issue on this list.
If we don't care about non-conformance to our own specs, then,
although I'd be interested in knowing what percentage of the
total number of messages the IETF servers reject a day these IP
literals in EHLO represent, I'm likely persuaded from Glen's
figures that accepting them is not worth the added cycles.  If
we do care, then either we should be accepting the mail session
opening attempt and dealing with the problems later in the
process (and accepting the marginal overhead) or we should be
seeing a proposal to change  the standard.  And, again if we
care, we should be looking at, or encouraging someone to look
at, whether we should make some adjustments to lower the odds of
similar non-conformance with IETF standards occurring in the
future.

Finally, to summarize part of an off-list discussion that may be
relevant, I am not accusing anyone (especially not Glen) of
having done something wrong here.  I simply believe that the
question of whether we feel an obligation to conform to our own
standards is important.  If the answer is "yes", then some
adjustments are probably in order going forward, adjustments
that might include a little more transparency about how
instructions to Glen and his colleagues that might interact with
IETF standards are generated and by whom and/or a requirement
that a decision to deviate from relevant standards requires
either an I-D proposing a change to those standards or one
explaining why the deviation is appropriate.  And, for the
record, I have no reason to believe that those who generated the
instructions to Glen were aware that they were directing
non-conformance with the relevant standard.  I assume it just
slipped by (5321 is really hard to read on these issues) and
that the question is only what, if anything, we should do
differently in the future to lower the odds of a recurrence
(again, if we care).

best,
  john

Attachment: signature.asc
Description: Message signed with OpenPGP