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

Glen <glen@amsl.com> Mon, 16 December 2019 16:11 UTC

Return-Path: <glen@amsl.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FED1200BA; Mon, 16 Dec 2019 08:11:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.2
X-Spam-Level:
X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MaVxhIqo9UE; Mon, 16 Dec 2019 08:11:23 -0800 (PST)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4101200B1; Mon, 16 Dec 2019 08:11:23 -0800 (PST)
Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 84F02203AB7; Mon, 16 Dec 2019 08:09:13 -0800 (PST)
Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) by c8a.amsl.com (Postfix) with ESMTPSA id 682F2203ABA; Mon, 16 Dec 2019 08:09:13 -0800 (PST)
Received: by mail-ot1-f51.google.com with SMTP id a15so9829586otf.1; Mon, 16 Dec 2019 08:11:23 -0800 (PST)
X-Gm-Message-State: APjAAAWAEwr9asog+ROMn+vxqOIdCGJf603qkrmeKX9yH2xg6Z7bcGpH ZyckdLVVsuRR0gm0PRb6HtWV4J5mbclZnsmqrBY=
X-Google-Smtp-Source: APXvYqxUrCnrgH0N1FI/JCq0jVRFX721C7EjTRooXJOsQizl2RmQ/pkjqVYM+fUxctv1n5CD9+NHut9RaRq6hrHtGAc=
X-Received: by 2002:a9d:7447:: with SMTP id p7mr30931898otk.189.1576512682955; Mon, 16 Dec 2019 08:11:22 -0800 (PST)
MIME-Version: 1.0
References: <8EE11B75E1F8A7E7105A1573@PSB> <m2a77ttff6.wl-randy@psg.com>
In-Reply-To: <m2a77ttff6.wl-randy@psg.com>
From: Glen <glen@amsl.com>
Date: Mon, 16 Dec 2019 08:11:11 -0800
X-Gmail-Original-Message-ID: <CABL0ig4Wz-0dk7bsRpaN6pni2rHEc-jPnygwed_Hygy+CiehQA@mail.gmail.com>
Message-ID: <CABL0ig4Wz-0dk7bsRpaN6pni2rHEc-jPnygwed_Hygy+CiehQA@mail.gmail.com>
Subject: Re: IETF Policy on dogfood consumption or avoidance - SMTP version
To: ietf@ietf.org
Cc: iesg@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/EK0N8JKT7fcFN9sbenxNHahP8Ws>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Dec 2019 16:11:25 -0000

All -

While I am not normally on the IETF list, I was summoned by my *very*
esteemed friend Randy :-) and I will answer his questions below.  I
have read some of the other messages, and know that this has been
partially addressed already, but as the IT director of the vendor
providing IT operations services to the IETF, and the person who is
most hands-on with this, I felt that I should personally answer the
technical questions he posed.

As Randy wisely implies, the politics of this are beyond me, so please
do not consider my silence elsewhere - anywhere - as apathy; rather,
prudence.  I am always happy to answer questions about our operations.
I cannot ever speak to anything else beyond that.

On Mon, Dec 16, 2019 at 7:43 AM Randy Bush <randy@psg.com> wrote:
>   o would it be technically easy for the smtp servers to accept ip
>     literals in a conforming manner?  yes, this is a question for my
>     esteemed friend glen

Extremely easy.  The statements already made about Postfix are
correct.  There is a configuration file, with two lines in it:

/^[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.

>   o what would the technical and/or security exposure or other
>     downside(s) be of doing so?

These rules have been in place for roughly 10-ish years, as has
already been explained by John.  They are in essence gateway checks,
which occur before other measures like Postconfirm or Spamassassin see
the messages.  On a given day, there are between 700 and 1000 incoming
messages rejected by this rule.

Changing the messages would have no technical exposure or downsides
that I can see.  Changing the messages may have a positive or negative
security exposure in that it might either (a) send the message that we
(the IETF) are watching and know what we're doing and scare attackers
off, or (b) might cause attackers to abandon this channel (which at
the moment could be a honeypot-esque bit bucket) and focus on other
methods of attack.  But I think both of those things are extremely
small side-effects.

Removing the rules would increase the load on Spamassassin and - for
that subset of those 1000 messages per day that pass through
Spamassassin's upper threshhold - cause us to send out challenge
emails to the (potentially forged) senders of all of those emails.
This could possibly cause increases in greylisting threshholds or
other automated checks used by others to evaluate email - and in
potential delays in IETF email delivery.  It could make us become (or
be perceived as) a spam source, or (incorrectly, but, it's all about
perception) an open relay.  It could also potentially cause some hosts
or ISPs to block or blacklist us, requiring the users of those hosts
to either appeal to their ISPs, or change ISPs, to continue
participating with us.  There may be other downsides I am not aware
of.

I trust the answers are helpful.  If there are other technical
questions to which answers are desired, please copy me directly, as I
do not normally subscribe to the IETF list.

Thank you!
Glen
--
Glen Barney
IT Director
AMS (IETF Secretariat)