[ietf-smtp] Variable HELO name, was DSNs

Alessandro Vesely <vesely@tana.it> Sun, 26 April 2020 10:04 UTC

Return-Path: <vesely@tana.it>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D00E43A0F30 for <ietf-smtp@ietfa.amsl.com>; Sun, 26 Apr 2020 03:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PQQYnaqQLRIS for <ietf-smtp@ietfa.amsl.com>; Sun, 26 Apr 2020 03:04:18 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it []) (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 D0A823A0F31 for <ietf-smtp@ietf.org>; Sun, 26 Apr 2020 03:04:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1587895453; bh=ugtasdHo0b3I8LvXoWLbRUBuN8uMu4DrSZwx1JCpJUg=; l=1251; h=To:References:From:Date:In-Reply-To; b=DPDQuFVZrM5FEvj2BxQ0G72SEGn4St4dyolUOsYmpSAFagNBqKSuAx8kVCK+gm6uq nIiJx77hLhYCo+NxXKnROOlJua2Zwa1gBKhsZGlQsDFU7WDUpL9AnstJdQw+npprdg I1HgEkzuSJeNQSN7RT4ZkksR+dl3fbCigBpE5DShblrC6NwodLhEXkcazDLYo
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC07E.000000005EA55C9D.000029F0; Sun, 26 Apr 2020 12:04:13 +0200
To: ietf-smtp@ietf.org
References: <20200409230011.F039B17637D0@ary.qy> <alpine.OSX.2.22.407.2004091945050.80689@ary.qy> <20200410090430.GA75736@kiel.esmtp.org> <29104A0F-B9ED-4CD7-99B3-5A042375C68B@dukhovni.org> <r7fq4k$1nm5$1@gal.iecc.com> <C1A5FAAA942E0F363CA177C0@PSB> <20200425013624.GV41308@straasha.imrryr.org> <01RK47G4QUK0000058@mauve.mrochek.com> <22e05a3b-bf47-9d83-a340-720ca9a373c4@dcrocker.net> <01RK4LP3NYJK000058@mauve.mrochek.com> <21987cb0-1cc2-e5ce-363f-5bb713333e8e@dcrocker.net> <CCD9771E28F1C5438052BB1A@PSB>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <129b193e-81ed-6f59-4f54-cc2d45b6dfb8@tana.it>
Date: Sun, 26 Apr 2020 12:04:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CCD9771E28F1C5438052BB1A@PSB>
Content-Type: text/plain; charset=us-ascii
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/krGK3UV3Lp3qx8_mApNlxC3EFww>
Subject: [ietf-smtp] Variable HELO name, was DSNs
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: Sun, 26 Apr 2020 10:04:20 -0000

On 26/04/2020 00:41, John C Klensin wrote:
> Suppose there were correspondents, or even domains, for which I have found
> read receipts useful and something I'm willing to let them use.  So, because
> of them, I advertise the availability of that feature in the EHLO response.
> When the MAIL command comes along and doesn't contain that domain or
> mailbox, I reject the request.  Now, which mailboxes or domains to accept is
> an operational decision, but the behavior, AFAICT, is fully conforming and
> it certainly don't mean that the features doesn't work, just that I have an
> operational policy prohibiting its use in most circumstances.

Wow, I never tried that at home!

A decade ago we fantasized about a Verified Hello, whereby:

   Non-empty arguments of the MAIL FROM commands are restricted to
   addresses whose domain part consists of the authenticated Domain.

Otherwise, the reply code is ambiguous.  For example:

  4xx HELO name/MAIL FROM inconsistency, try another session.

AFAIK, the HELO name is practically constant for most mailouts, so the above
reply will make the relevant message bounce for days, until timeout.