Re: I-D Action:draft-newman-email-subaddr-01.txt
Keith Moore <moore@cs.utk.edu> Wed, 05 December 2007 15:19 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 1Izw1h-0008Kb-UU; Wed, 05 Dec 2007 10:19:05 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Izw1g-0008KK-ET for discuss-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 10:19:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izw1g-0008Ju-43 for discuss@apps.ietf.org; Wed, 05 Dec 2007 10:19:04 -0500
Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izw1f-0002PO-DC for discuss@apps.ietf.org; Wed, 05 Dec 2007 10:19:04 -0500
Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id C153A1EE2CC; Wed, 5 Dec 2007 10:18:57 -0500 (EST)
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu
Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6d8NXROcpOB; Wed, 5 Dec 2007 10:18:55 -0500 (EST)
Received: from lust.indecency.org (dhcp-415b.ietf70.org [130.129.65.91]) by shu.cs.utk.edu (Postfix) with ESMTP id B2C9F1EE2C1; Wed, 5 Dec 2007 10:18:53 -0500 (EST)
Message-ID: <4756C14D.5080407@cs.utk.edu>
Date: Wed, 05 Dec 2007 07:18:37 -0800
From: Keith Moore <moore@cs.utk.edu>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: Dave Cridland <dave@cridland.net>
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> <2639.1196812257.522519@peirce.dave.cridland.net> <4755EF6C.8060703@cs.utk.edu> <2639.1196849327.522853@peirce.dave.cridland.net>
In-Reply-To: <2639.1196849327.522853@peirce.dave.cridland.net>
X-Enigmail-Version: 0.95.5
OpenPGP: id=E1473978
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
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
>> > 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. >> fwiw, bulk_mailer recognizes - = / . # % + because at the time I wrote >> the code, I found cases where all of these had been used to delimit >> subaddresses. compared with just - and +, this adds 6 whole bytes of >> code and a few dozen cpu cycles per comparison. I really don't think >> that having one or two widely advertised conventions for subaddress >> delmiting is a good idea, precisely because I don't want to encourage >> MSAs and MTAs and MUAs to be too smart about addresses. > > Whereas it's okay for bulk_mailer to be smart about them? Given that the only thing bulk_mailer uses them for is to decide whether an address happens to be "close enough" to a subscriber's address, it seems pretty harmless. But I agree it's tricky to explain why this is harmless while maintaining that other intermediaries that peek at the local-part can do harm. I think people on this list probably understand the difference, but getting the audience of an RFC to understand the difference is difficult. > Seriously, this sounds like you're arguing that we should describe it > as loosely as possible in order to mitigate the damage by people who > don't read the specification, or who selectively ignore portions of it. I'm certainly worried about the potential for damage done by people who read enough of the specification to know what subaddresses look like, and ignore the portion of the specification that says "if you're not the MSA for the sender's domain, nor an authoritative MTA for the recipient's domain, you MUST treat the local-part as opaque". > Where there is a convention that local-parts may adhere to, then it > makes sense for this to be as usefully defined as possible, such that > all components of the MHS - from MTA to MUA and back to MSA - all have > the same notion. This is purely a convention of no relevance outside > the ADMD. I have yet to be convinced that this is at all in scope for _any_ MUA, except in the very broad sense that MUAs should allow users to type in _any_ valid address as a sender or recipient address. I really don't buy the model that an MUA lives within a particular mail domain, perhaps because my MUA is configured to deal with mailboxes in multiple mail domains that are maintained by multiple parties - and this seems increasingly common. I don't really want to see MUAs changing their user interfaces on a per-domain basis. > >> what I really >> want to encourage is mostly these two things: >> >> 1. giving users an extensible space for their email messages is really >> useful > > Yup. > > >> 2. yes, it's legitimate for these printable characters to appear in the >> local-part of an email address > > Right. (FWIW, I think I'll add a paragraph or two explaining that "+" > is a character that does appear in local-parts that demonstrably do > not have subaddressing). > > But I think for usability, having a known convention is useful. It > allows "checkbox configuration" of all components within the ADMD, as > well as certain components outside of it (such as MLMs, which can be > told that the local-part convention for the domain is this one). Along those lines it might be useful to make a list of things that are necessary for each component in a mail system to be compatible with subaddresses. e.g. MSAs must do these things to be subaddress-compatible, MTAs must do these things, MUAs must do these things, MLMs must do these things, mail domains must make sure that all of their MSAs and MTAs are compatible, and that any MLMs that they expect their subscribers to use are compatible, and if they impose particular MUAs on their users or encourage their users to use particular MUAs then they need to make sure that their MUAs are compatible. >> > An MUA wishing to provide a user-friendly UI to subaddressing also >> > needs to know the convention, > > >> so far, I'm unconvinced of this . > > As an MUA developer of sorts (I don't get paid for it anymore, and > it's a mere hobby), I'm very much convinced by it. Sure, it's not > essential - but it makes it possible to build a clean UI and several > rather neat tricks. can you give an example? I can imagine having a clean UI to create new subaddresses, to delete them, to specify what happens to mail sent to a particular subaddress. But absent some sort of standard protocol to communicate this to the delivery agent, I'm not sure that this is a MUA function. I can also imagine an MUA having the ability to use a subaddress as a default From address when reply to mail from a particular folder that is associated with a subaddress. But I don't know why having a per-folder default From address is specific to subaddresses. It seems like a generalization of per-mailbox default >From addresses that many MUAs already support. which reminds me - I am dubious that MUAs or users should assume that there's a relationship between the subaddress and the name of the folder where that mail ends up. at least I've found good reasons for them not to be the same. though admittedly that makes for a more complex user interface. Keith
- Re: I-D Action:draft-newman-email-subaddr-01.txt Stephane Bortzmeyer
- Re: I-D Action:draft-newman-email-subaddr-01.txt Randall Gellens
- Re: I-D Action:draft-newman-email-subaddr-01.txt Stephane Bortzmeyer
- Re: I-D Action:draft-newman-email-subaddr-01.txt Stephane Bortzmeyer
- Re: I-D Action:draft-newman-email-subaddr-01.txt Bill McQuillan
- Re: I-D Action:draft-newman-email-subaddr-01.txt Keith Moore
- Re: I-D Action:draft-newman-email-subaddr-01.txt der Mouse
- Re: I-D Action:draft-newman-email-subaddr-01.txt Keith Moore
- Re: I-D Action:draft-newman-email-subaddr-01.txt Dave Cridland
- Re: I-D Action:draft-newman-email-subaddr-01.txt Keith Moore
- Re: I-D Action:draft-newman-email-subaddr-01.txt der Mouse
- Re: I-D Action:draft-newman-email-subaddr-01.txt Dave Cridland
- Re: I-D Action:draft-newman-email-subaddr-01.txt Tony Finch
- Re: I-D Action:draft-newman-email-subaddr-01.txt Keith Moore
- Re: I-D Action:draft-newman-email-subaddr-01.txt Dave Cridland
- Re: I-D Action:draft-newman-email-subaddr-01.txt Randall Gellens
- Re: I-D Action:draft-newman-email-subaddr-01.txt Randall Gellens
- Re: I-D Action:draft-newman-email-subaddr-01.txt Randall Gellens
- Re: I-D Action:draft-newman-email-subaddr-01.txt der Mouse
- Re: I-D Action:draft-newman-email-subaddr-01.txt Dave Cridland