--On Sunday, December 15, 2019 18:32 -0500 John R Levine <johnl@xxxxxxxxx> wrote: >> RCPT TO:<ietf-bounces@xxxxxxxx> >> 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 ietf-smtp@xxxxxxxx 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
