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

[Alissa Cooper <[e-mail]>]

Hi John, all,

The principles that the IESG has laid out for spam control on IETF lists are available here: <https://www.ietf.org/about/groups/iesg/statements/spam-control-2008-04-14/>. These principles continue to guide spam control as implemented by the AMS IT team. The IESG is not involved in day-to-day decisions about how the principles are operationalized and was not involved at all in the handling of the ticket you cite below.

With Glen’s help this week I’ve come to understand the history here, which was unknown to me before. It seems there was some sort of committee or group that existed a decade ago. Once when they met, one of their discussion topics was spam. Many measures including the one discussed in this thread were proposed, considered, and implemented. I don’t know much else about the group but it does not exist now.

As you’ve seen from Jay’s email, he has taken the lead on operationalizing a response. Based on discussions with him and Glen I think they both know they can reach out to the IESG at any time if they have questions in interpreting the IESG statement above or any other IESG statements.

Best,
Alissa on behalf of the IESG

> On Dec 15, 2019, at 4:15 PM, John C Klensin <[e-mail]> wrote:
> 
> Hi.
> 
> It has long been my personal belief that, in its operation of
> various of its own services on the Internet the IETF should
> adhere closely to its own standards.  If we do not do so, we
> lose all credibility in recommending to others that they follow
> our standards.  This practice has been referred to in many
> discussion threads over the years as "eating our own dog food".  
> 
> It has recently come to the attention of several of us, via an
> extended discussion on the SMTP list, that the IETF email
> servers are rejecting all SMTP connections whose EHLO commands
> contain IP address literals.   While the text describing the
> appropriateness of use of IP literal is RFC 5321 is more
> complicated than it probably ought to be, the discussion in
> Section 4.1.4 of that document seems quite clear that an SMTP
> server MUST NOT reject a message simply because an IP address
> literal (or a domain name that does not point to a host) is
> used. Those interested in the niceties of that issue should
> review the correspondence on the [e-mail] list and
> comment there if appropriate.
> 
> A ticket ( [www.ietf.org/rt #282782] ) was generated early in
> the month about the ietf.org mail servers apparently rejecting
> messages with IP address literals in the EHLO field.  The
> rejection is accompanied by a reply message that appears to be
> inappropriate in multiple ways; again, those interested should
> see the ietf-smtp list for an already-extensive discussion.  The
> Secretariat responded by indicating that all such addresses were
> being rejected and that the rejection was occurring under
> instructions from IETF leadership, instructions that were
> reaffirmed after the ticket was filed.  Whatever the problem is,
> and indeed, whether there is a problem, the Secretariat is
> therefore blameless.  I suggest that the IETF has a problem.
> 
> The purpose of this note is _not_ to evaluate the underlying
> technical issues, what should be done about them, or whether the
> text in RFC 5321 should be improved.  Those, it seems to me, are
> topics for the ietf-smtp list.   They have been discussed there
> at length and presumably will continue to be discussed there.
> It is whether there is consensus among IETF participants that
> "the leadership" (I presume whatever bodies, individuals, or
> their designees are relevant) should have the authority to
> instruct the Secretariat to violate an IETF standard without
> consultation of appropriate experts within the community
> (presumably on relevant mailing lists), evidence of IETF rough
> consensus, and/or Internet Drafts that specify alterations to
> the relevant standard(s).  I also don't want to cast blame about
> decisions of the past, only to understand what the process is
> for giving instructions to the Secretariat (or approving their
> suggestions) is now and whether IETF conformance to IETF
> standards is something we care about for the future.
> 
>  john
>