[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [62.94.243.226]) (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 [172.25.197.111] (pcale.tana [172.25.197.111]) (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.
      https://tools.ietf.org/html/draft-vesely-vhlo-06#section-3.4.1


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.


Best
Ale
--