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

Dave Cridland <dave@cridland.net> Wed, 05 December 2007 18:16 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 1IzynD-0002Lp-Nz; Wed, 05 Dec 2007 13:16:19 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzynC-0002Lb-Bh for discuss-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 13:16:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzynC-0002Ke-1A for discuss@apps.ietf.org; Wed, 05 Dec 2007 13:16:18 -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 1IzynA-0003rq-P3 for discuss@apps.ietf.org; Wed, 05 Dec 2007 13:16:18 -0500
Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <R1bq5gATbaQi@turner.dave.cridland.net>; Wed, 5 Dec 2007 18:16:06 +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> <2639.1196812257.522519@peirce.dave.cridland.net> <4755EF6C.8060703@cs.utk.edu> <2639.1196849327.522853@peirce.dave.cridland.net> <4756C14D.5080407@cs.utk.edu>
In-Reply-To: <4756C14D.5080407@cs.utk.edu>
MIME-Version: 1.0
Message-Id: <7282.1196878561.595377@peirce.dave.cridland.net>
Date: Wed, 05 Dec 2007 18:16:01 +0000
From: Dave Cridland <dave@cridland.net>
To: Keith Moore <moore@cs.utk.edu>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
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 Wed Dec  5 15:18:37 2007, Keith Moore wrote:
> 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.
> 
> 
Right - hence why I downgraded -00's suggestion to automagically  
recognise subaddresses to -01's requirement that this be explicitly  
configurable.


> > 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".
> 
> 
Yes, but short of the world's first RFC with a click-through, I can't  
see a way of avoiding this. I think ultimately, we have to trust the  
reader to read the entire document, and ensure that the document  
makes this very clear.

> 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.

Well, it's not a change, per-se, it's an addition. But in as much as  
the MUA is co-operating with a remote store, as is typically the  
case, it has to expose features of that store, and its interactions  
with that store are to be considered as being within the scope of the  
ADMD.

I'll cheerfully agree that this is probably a matter of hair  
splitting.

> 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.
> 
> 
I think the document has the beginnings of this.


> >> > 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.

Well, ManageSIEVE is such a protocol.

>   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.
> 
> 
Yes, that kind of thing is a mere specialization of the UI. Cleaner,  
certainly, but not a dramatic improvement. Similarly, many MUAs know  
about multiple addresses, and a reply to a message will default the  
from address to whichever address the message was addressed to -  
enhancing this to subaddresses is both obvious and trivial.

I was thinking that an MUA might, when a mailing list is being  
subscribed to, automatically generate a suggested subaddress, and  
have simple drop-downs for subaddresses, rather than the user having  
to edit the From address each time. That's something that's much  
harder to deal with without subaddressing being known to the MUA.


> 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.
> 
> 
Agreed on all counts. Expressly in the document is that by default,  
there is no such relationship.

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