Re: I-D Action:draft-newman-email-subaddr-01.txt

Dave Cridland <dave@cridland.net> Tue, 04 December 2007 23:51 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzhXs-0007hi-SI; Tue, 04 Dec 2007 18:51:20 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzhXr-0007ha-Uw for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 18:51:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzhXr-0007hQ-Kv for discuss@apps.ietf.org; Tue, 04 Dec 2007 18:51:19 -0500
Received: from [2001:838:378:0:211:9ff:fe2c:e28e] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzhXq-0000Cv-Im for discuss@apps.ietf.org; Tue, 04 Dec 2007 18:51:19 -0500
Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <R1Xn5AATbZQg@turner.dave.cridland.net>; Tue, 4 Dec 2007 23:51:00 +0000
Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt
References: <E1It5KL-00032t-Up@stiedprstage1.ietf.org> <20071203094351.GA19449@nic.fr> <2639.1196720643.545129@peirce.dave.cridland.net> <20071204161659.GA19161@nic.fr>
In-Reply-To: <20071204161659.GA19161@nic.fr>
MIME-Version: 1.0
Message-Id: <2639.1196812257.522519@peirce.dave.cridland.net>
Date: Tue, 04 Dec 2007 23:50:57 +0000
From: Dave Cridland <dave@cridland.net>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
X-Spam-Score: -1.4 (-)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Cc: Apps Discuss <discuss@apps.ietf.org>
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

On Tue Dec  4 16:16:59 2007, Stephane Bortzmeyer wrote:
> On Mon, Dec 03, 2007 at 10:24:03PM +0000,
>  Dave Cridland <dave@cridland.net> wrote  a message of 89 lines  
> which said:
> 
> > As good as any.
> 
> May be ietf-smtp@imc.org would have been a better place?
> 
> 
Possibly. But this one's been picked, now, and subaddressing isn't  
specific to SMTP, so this one works for me just as well. (Even if I'd  
somehow become unsubscribed).


> > Subaddressing isn't described anywhere, 
> That's the whole point, I believe. Subaddressing has always been a
> matter of local conventions (like the Firstname.Name@example.org
> convention in many environments), not needing to be "described".
> 
> 
Yes, it's a convention local to a specific ADMD. This memo does  
indeed describe one very common, and useful, convention. John Klensin  
(and, I think, Keith Moore) both suggested that I add text to make it  
exceptionally clear that externally to the ADMD, there is no way to  
tell if a particular address is (in the phrasing of the SIEVE  
subaddressing extension) a detailed address or not - these are indeed  
perfectly legal addresses.


> If I understand you well, you suggest to create (not describe) a new
> concept, "global subaddressing", with a standard delimiter and
> subaddressing-aware software, allowing new tricks (like the MLM you
> mention, which accepts mail only from subscribers and who can
> recognize them even when they use subaddressing).
> 
> That's may be a good idea but it is something new, not a description
> of a current practice.
> 
> 
Well, somewhat to my surprise, Keith said this has been going on for  
some time, and John said it was not especially different to the use  
of "post only" addresses. Arguably, this *is* current practise,  
albeit not widespread, and is unblessed primarily due to the absence  
of this document. I freely admit that there's cases of interpreting  
subaddressing where I'm unsure that the actor is doing the Right  
Thing, and hence there's also some tightening up to do.

But, this is not a "global" thing, it's specific to an ADMD. The only  
case where I suggest (or rather, Chris Newman suggested and I watered  
down but essentially agree with) that actors external to the ADMD  
should consider the convention is MLMs, essentially because they're  
acting per-pro the user in a sense.

Using a standard -- or at least heavily promoted -- delimiter doesn't  
preclude people from choosing another (or another method entirely),  
but it does mean that when deploying an MTA and a Store, for example,  
if both claim to be "Subaddress-aware", according to RFC-9999, then  
they'll both work together nicely.

The purposeful use of the phrase "Subaddress-aware" is merely to  
provide a useful stamp with which to market your product - there's no  
more sinister intent than that.


> > No, every component needs to know about it.
> > > 1) The final MTA.
> > 2) The MDA.
> > 3) The MUA.
> > 4) The Submission server.
> 
> Can you explain why the MUA and the MSA need to know it?
>  
> 
Some MSAs restrict usage of a reverse-path to specific authenticated  
users, for example, I might only be allowed to use  
<dave@cridland.net>et>, and not <james@cridland.net>et>. Such MSAs need to  
be aware that <dave+foo@cridland.net> is also valid for me, because  
it is the same "primary address", even if they've never seen it  
before.

An MUA wishing to provide a user-friendly UI to subaddressing also  
needs to know the convention, in order to be capable of forming  
local-parts for use in both message header fields and envelope  
reverse-paths. If it's additionally performing some specific actions  
on message which are to be considered directly addressed to the user,  
then it needs to know for this, too.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade