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

[John C Klensin <[e-mail]>]

--On Sunday, December 15, 2019 18:32 -0500 John R Levine
<[e-mail]> wrote:

>> RCPT TO:<[e-mail]>
>> 550 5.7.1 <[A.B.C.D]>: Helo command rejected: RFC2821
>> violation
>> 
>> Personally,  my opinion is that if there's indication that a
>> lot of spam or other malicious mail is arriving from "address
>> literal EHLO" sources, it's appropriate to respond with a
>> "550 5.7.1 Rejected due to policy reasons",
> 
> I agree we should fix the message.  It has been a very long
> time since I saw any legit mail from a host that identified
> itself with an IP other than someone trying to make a point
> that I don't understand.

John, Valdis, Subramanian, and maybe a few others,

First of all, I read John's message too quickly and had
forgotten that the rejection message attributing the problem to
EHLO does not appear until after a RCPT command is sent.  So
SM's test is the important one; John's just didn't go far
enough.  There are also a number of issues raised by the error
message.  The problem condition should not be attributed to RFC
2821; it probably shouldn't refer to the "Helo command" when
EHLO was used; it is, as suggested above, a policy matter and
not a requirement of any IETF protocol specification; and, while
the specification arguably permits it, accepting the EHLO and
then rejecting the mail transaction only after processing the
MAIL and at least one RCPT command is probably at least in bad
taste.  Some of those issues suggest changes or clarification
that should be applied when and if RFC 5321 is updated and
replaced.  Most of them have been discussed, at length, on the
ietf-smtp list; I assume the others soon will be.

Interpretation is up to the SAA team but, given that the
[e-mail] list exists and a productive discussion of
the technical parts of this topic has already occurred there, I
hope we can avoid either repeating that discussion on this list
or forking it and expecting people to follow and integrate both.

None of the above has much of anything to do with the key issue
that I thought 
was worth raising on this list.  According to the response to
the trouble ticket, the Secretariat was told to block mail
transactions that used IP address literals in the EHLO command.
No matter how pragmatically desirable that may be (see the
ietf-smtp list for a discussion on that topic too), at least as
I read it (and wrote it) RFC 5321 prohibits that rejection,
making the IETF mail servers non-conforming to the standard.
So, again, the first question for this list is whether we are
comfortable with servers run in the IETF's name being
non-conforming to IETF standards.  I see objections to that on
ethical and credibility ground, but others may disagree.  If we
do believe that our not -conforming to our standards may be
appropriate in some circumstances, should there be a mechanism
for at least informing, and possibly consulting, the community
before that is done or are we comfortable not knowing about it
until someone stumbles over the problem.

I'm not going silent on the second topic because I want to see
what others have to say.  And, because I believe the technical
issues and tradeoffs belong on the ietf-smtp list, I'm not going
to comment further on them here until the SAA team or some AD
requests that I do otherwise.

best,
  john