Re: [ietf-smtp] Endless debate on IP literals

Ned Freed <ned.freed@mrochek.com> Fri, 03 January 2020 03:34 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F2D12004E for <ietf-smtp@ietfa.amsl.com>; Thu, 2 Jan 2020 19:34:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
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 vZ898FqbeD-x for <ietf-smtp@ietfa.amsl.com>; Thu, 2 Jan 2020 19:34:57 -0800 (PST)
Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A9612004D for <ietf-smtp@ietf.org>; Thu, 2 Jan 2020 19:34:57 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RFPMUSZQIO000WV7@mauve.mrochek.com> for ietf-smtp@ietf.org; Thu, 2 Jan 2020 19:29:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1578022193; bh=7Har1zDiij0bk1bLw5EpgkTsg2kLJ8oSzP7mEEyN1Gw=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=niNmMI3vHGpLzzXRjNXAItjS60rqDKxl37Hw7/EQXcMp8KBj2OLWHweImiSXMEnrp xcYaESYYQc+wRnWsSUhGXhlO9od0qoQbpjCOil3ZPL0fnEV4bQhxbBchJDdI/4yR95 p2Y6Axd4IfT5f/hL76FNg3Kq1B+YC/ifBIsJs1Ao=
MIME-version: 1.0
Content-transfer-encoding: 8bit
Content-type: TEXT/PLAIN; charset="utf-8"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RFPBA16NAO000059@mauve.mrochek.com>; Thu, 2 Jan 2020 19:29:50 -0800 (PST)
Cc: ietf-smtp@ietf.org, moore@network-heretics.com
Message-id: <01RFPMURANBO000059@mauve.mrochek.com>
Date: Thu, 02 Jan 2020 19:27:49 -0800
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Wed, 01 Jan 2020 17:52:24 -0500" <20200101225225.1011D11E6345@ary.qy>
References: <b3f0f5d9-a433-b83a-b032-b726ddd8919a@network-heretics.com> <20200101225225.1011D11E6345@ary.qy>
To: John Levine <johnl@taugh.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/_dc7WFI2WBFiMdtcCec78AIKEbU>
Subject: Re: [ietf-smtp] Endless debate on IP literals
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jan 2020 03:34:58 -0000

> In article <b3f0f5d9-a433-b83a-b032-b726ddd8919a@network-heretics.com> you write:
> >p.s. I suspect ietf-smtp doesn't want to dig down into details of how
> >IoT devices should authenticate submissions - at least not just yet -
> >and such a topic might be better discussed in a working group that's
> >specifically tailored to that purpose.   For now I just want people to
> >realize that some long-held assumptions may not be universlaly valid.

> On the contrary, I'd like to understand what we can and can't expect
> them to do, and how they match up with the facilities we already have.

> For example, CRAM-MD5 challenge authentication is widely available
> give or take the issue that the server needs to store the password in
> the clear.  If that's good enough, that's one less thing we need to
> invent.

> Also, some of the stuff you find confusing could go into a BCP, e.g.,
> when to use port 25 vs port 587.  The main reason to do submission on
> port 465 or 587 rather than 25 is that a lot of networks firewall port
> 25 as an effective anti-spam measure.  If you can be sure that your
> network doesn't do that, at least for its internal traffic, port 25
> submission works fine.

And others have stringent security policies against mail being sent to any port
other than 25.

Getting hung up on which port does what isn't helpful. The goal should be
to figure out the actual characteristics of the services that are needed.

				Ned