--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
