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

Dave Cridland <> Wed, 05 December 2007 10:09 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IzrBl-0000Mc-3s; Wed, 05 Dec 2007 05:09:09 -0500
Received: from discuss by with local (Exim 4.43) id 1IzrBk-0000ML-03 for; Wed, 05 Dec 2007 05:09:08 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IzrBj-0000Kt-Hl for; Wed, 05 Dec 2007 05:09:07 -0500
Received: from [2001:838:378:0:211:9ff:fe2c:e28e] ( by with esmtp (Exim 4.43) id 1IzrBg-0007Zf-FZ for; Wed, 05 Dec 2007 05:09:07 -0500
Received: from ([]) by (submission) via TCP with ESMTPA id <>; Wed, 5 Dec 2007 10:08:50 +0000
Subject: Re: I-D Action:draft-newman-email-subaddr-01.txt
References: <> <> <> <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Message-Id: <>
Date: Wed, 05 Dec 2007 10:08:47 +0000
From: Dave Cridland <>
To: Keith Moore <>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc
Cc: Apps Discuss <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On Wed Dec  5 00:23:08 2007, Keith Moore wrote:
> I don't know what an ADMD is in the context of Internet email.   
> it's never been clearly defined in this context and I think it's
> probably misleading to use the term.
I think Dave Crocker defines it in draft-crocker-email-arch section  
2.3 pretty well. Pick another term if you feel more comfortable, I'm  
not particular wed to most of the increasingly clunky language we use  
to describe actors and addresses within the global MHS, most  
especially the terms I've had to come up with for this document.  
("Detail"? Ugh.)

> > 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.
> the statement needs to be stronger than that.  for the most part,  
> nobody
> except the authoritative MTAs for the recipient's domain should be
> interpreting the local part of a recipient address.  similarly,  
> nobody
> except the MSAs for a sender's domain should be interpreting the  
> local
> part of a return address.
That text is better, yes. I'll use something very similar.

> having said that, if lists do fuzzy matching on addresses  
> (recognizing
> that in general there are often several equivalent ways of spelling  
> an
> email address) they're just using heuristics to decide what traffic  
> to
> forward to subscribers.   this is no different than any other
> content-based heuristics (e.g. spam or virus filters) that they  
> might
> employ to decide what traffic to forward to subscribers.  nothing
> (including this document) should require a list to accept mail from  
> an
> address that is similar to, but not quite the same as, a subscriber
> address.  it would be silly to say to a list "you can filter based  
> on
> message content but you can't filter based on the local-part of a  
> from
> or return address".  but if a list can tune its filtering  
> heuristics to
> work better, the list might provide better service to its  
> subscribers. 

Or it might screw things up irrevocably...

As common as this sort of thing is - and I'm pretty sure that  
local-parts are treated case-insensitively, for example - I don't  
want to even attempt to describe or suggest what might happen here.  
Trying to specify this sort of thing would be simpler by leaving a  
couple of blank pages and telling the implementor to write whatever  
they liked in.

Whereas, if the MLM is explicitly told that the convention is in use  
within the ADMD (at least for this subscriber), then it can perform  
that kind of action without the need for potentially dangerous  

> fwiw, I was about to write my own version of this document, and I  
> would
> certainly have mentioned the case of a mailing list doing fuzzy  
> matching
> on a sender address vs. its list of subscriber addresses.
FWIW, I think there's a BCP to be written on MLMs; the state of the  
art is getting quite refined, these days, and it's another area I  
can't really find much documentation. (List-* header fields not  

> (what I tend to do for most lists is to subscribe twice - once at my
> normal email address, and again at the subaddress.  then I set  
> "nomail"
> or the equivalent for the normal address.  that way I can send mail  
> from
> my normal address and have the list subscription go to the  
> subaddress)

Right, and this sort of thing is possible with most, or even all,  
MLMs. I'll make it clear that this is essentially a specific case of  
this functionality, and nothing particularly new.

That said, it has been suggested that MLMs might want to go a step  
further, and rewrite messages such that a message from  
<> copied to a mailing list which has a  
(Subaddress-enabled) subscriber of <> would  
cause the MLM to go as far as rewriting headers to the subscribed  

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

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.

>   what I really
> want to encourage is mostly these two things:
> 1. giving users an extensible space for their email messages is  
> really
> useful


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

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

It makes it possible to support it such that my mother could use it,  
rather than restricting it largely to IETF participants and other  
technically aware people.

Don't ask me how the MUA knows the convention is supported, though. I  
do have an answer, but I'll have to use the "A word", and people seem  
to get upset by it. :-)

Dave Cridland - -
  - acap://
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade