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

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

Jay,

Three questions:

* Did you review and understand the extensive discussion that
has occurred on the [e-mail] since the beginning of
the month or just the (relatively few) comments on this IETF
list?

* Did you consider the issues associated with the possibility of
IETF servers being out of conformance, whether clearly or
marginally, with IETF standards and the implications if that
were the case?

* Is the answer to the question of where the Secretariat will
get guidance and instructions on technical issues going forward
that it will come from you and your assessments of  those issues
and community consensus about them?

thanks,
   john


--On Tuesday, December 17, 2019 10:46 +1300 Jay Daley
<[e-mail]> wrote:

> Hi
> 
> While there is not unanimous consensus, I think the mood is
> clearly to leave this as an operational decision.  In which
> case, taking into account the following recommendation ...
> 
>> On 17/12/2019, at 5:18 AM, Nick Hilliard <[e-mail]>
>> 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/
> 
> … and the following technical comment … 
> 
>> On 17/12/2019, at 6:04 AM, Viktor Dukhovni
>> <[e-mail]> wrote:
>> 
>> On Mon, Dec 16, 2019 at 08:11:11AM -0800, Glen wrote:
>> 
>>> There is a configuration file, with two lines in it:
>>> 
>>> /^[0-9.]+$/             550 RFC2821 violation
>>> /^\[[0-9.]+\]$/         550 RFC2821 violation
>> 
>> While the patterns look similar, the first one rejects
>> non-compliant "EHLO 192.0.2.1" and similar dotted quads (or
>> more generally some mixture of digits and dots), the second
>> rejects RFC-compliant address literals.  So at least the
>> second message should probably be different, if the rule is
>> retained.
> 
> 
> 
> … the following has now changed from
> 
> 	/^[0-9.]+$/             550 RFC2821 violation
> 	/^\[[0-9.]+\]$/         550 RFC2821 violation
> 
> to
> 
> 	/^[0-9.]+$/             550 RFC2821 violation
> 	/^\[[0-9.]+\]$/         550 Policy violation
> 
> 
> As to the question of data, we cannot say for certain that the
> rejected messages were all spam, but we have only received one
> complaint in 10 years and so we can reasonably assume this
> rule has not caused problems that need to be addressed.
> 
> Please let me know if you have any questions, comments or
> recommendations.
> 
> kind regards
> Jay