Re: [ietf-smtp] DSNs

Ned Freed <ned.freed@mrochek.com> Tue, 28 April 2020 23:47 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 3F0F73A0AB5 for <ietf-smtp@ietfa.amsl.com>; Tue, 28 Apr 2020 16:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 i0bnalLQc-ic for <ietf-smtp@ietfa.amsl.com>; Tue, 28 Apr 2020 16:47:53 -0700 (PDT)
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 732883A0AB6 for <ietf-smtp@ietf.org>; Tue, 28 Apr 2020 16:47:53 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RK8X42TG1S006GX1@mauve.mrochek.com> for ietf-smtp@ietf.org; Tue, 28 Apr 2020 16:42:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1588117368; bh=RbNuXgk4PO9lRw1BtfpCkUt/Nc9ojwQ9xjjpVCPgy+M=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Mo9M6+X0O5yMBQHo/BpSDmd6uAbcYxGEvIi//69z+p1z0i37W7ymwMTTVxxbDyBsG 2Y46XQxf2ffToEKA381emOZwA8cccYnHusO9M8AqFVUpp/lLRDKdg8Acu5Eq9t20n6 Lh8ENJICCTIOYvXTl3Zuhin1cl7Fl0iJK9Q091UU=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed; delsp=yes
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RJM3XSTRLC000058@mauve.mrochek.com>; Tue, 28 Apr 2020 16:42:46 -0700 (PDT)
Cc: ietf-smtp@ietf.org
Message-id: <01RK8X40XUC6000058@mauve.mrochek.com>
Date: Tue, 28 Apr 2020 16:36:25 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 28 Apr 2020 18:50:45 -0400" <cone.1588114245.584354.86006.1004@monster.email-scan.com>
References: <20200428221357.D6FAB188397F@ary.qy> <cone.1588114245.584354.86006.1004@monster.email-scan.com>
To: Sam Varshavchik <mrsam@courier-mta.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/iipmqUxwW715y5IC2OPZRsL8bgE>
Subject: Re: [ietf-smtp] 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: Tue, 28 Apr 2020 23:47:56 -0000

> John Levine writes:

> > In article <cone.1588076349.709902.75652.1004@monster.email-scan.com> you
> > write:
> > >> In general I agree but there are still situations where an MTA (mine
> > >> for example) accepts a message intending to forward it somewhere else
> > >> and then the forward fails.  Either send a DSN or drop it on the floor
> > >> at that point.
> > >
> > >Well, yes. You take ownership of that message by the act of forwarding, you
> > >now own it, from the point of forwarding. If you don't want to disclose the
> > >forwarded-to address, that's your responsibility, so either set the sender's
> > >address to <>, or to some other address where you want the bounces to go.
> >
> > Huh?  If I send a DSN it includes the original delivery address but it
> > doesn't have to include the forwarded-to address.

That depends on the type of forwwarding. Forwarding that doesn't change
envelope return address is reflected in the change of the final recipient
address only; the DSN request semantics generally do not change.

> I'm talking about the forwarding system. Whatever's forwarding the message,
> it can easily reset the return address to <>, or to some bit bucket.

Yes, and if this happens as far as the DSN status of the message is 
concerned you have essentially delivered one message and things are
now proceeding with a new one.

All of this is covered in detail in RFC 3461 section 5.2.7. The terminology
may be a bit archaic but the required semantics are pretty clear.

				Ned