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

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 3 Dec 2007 10:43:51 +0100

[No discussion list indicated in the draft, trying the Application
Area general list.]

On Fri, Nov 16, 2007 at 12:50:01PM -0500,
 [email-masked] <[email-masked]> wrote 
 a message of 97 lines which said:

> 	Title           : Internet Email Subaddressing
> 	Author(s)       : D. Cridland
> 	Filename        : draft-newman-email-subaddr-01.txt

I'm quite puzzled by this draft and I do not really understand what it
normalizes or what its purpose is.

The entire idea of subaddressing is to be a local decision, only the
final MTA and/or its MDA will have to know it. Besides stuff like RFC
3598, there is little room for IETF work. 

Some sentences in the draft are strange, in that respect. For
instance, section 4.2 says "A subaddress-aware gateway or firewall
SHOULD preserve the detail part when rewriting an address." while I
thought that the SMTP rule was much stronger: "DO NOT MESS with
addresses", and that is a general rule, it is not only for
subaddressing.

Apart from that, the draft puts too much emphasis on the most common
"+" (with a MTA like Postfix, it is trivial to change it - the
recipient_delimiter option, and many people do so to avoid the problem
of broken software mentioned later). Again, the IETF should not
mention this separator, since it is a local decision.

Strangely enough, the draft does not talk about *the* big problem with
subaddressing: the fact that many stupid and broken Web forms and/or
mail software do not accept them or do not handle them
properly. Certainly, an informational RFC asking to accept valid email
addresses would be an useful document. See a good start in
http://www.linuxjournal.com/article/9585, specially the conclusion
("There is some danger that common usage and widespread sloppy coding
will establish a de facto standard for e-mail addresses that is more
restrictive than the recorded formal standard.") or in
http://worsethanfailure.com/Articles/Validating_Email_Addresses.aspx
(the comments are interesting, too).

---

From: Randall Gellens <[email-masked]>
Date: Mon, 3 Dec 2007 19:45:47 -0800

>  3598, there is little room for IETF work.

Currently, subaddressing is mostly part of the mostly undocumented 
email lore that some implementers are aware of while others are not. 
Formalizing the concept is a good thing.  It would still be a purely 
local decision to use it or not, and indeed to define what it means. 
But having a common basis for information seems helpful to me.

Also, the advice for mailing lists to ignore the detail, and the 
Security Considerations text on command-line handling, seem useful. 
The mailing list issue argues for a standardized character, but the 
prevalence of broken web forms argues against it.

>  addresses", and that is a general rule, it is not only for

I think a gateway or firewall that rewrites addresses (or in any way 
alters the mail) is, by definition, within the local delivery domain, 
and hence the 2821 rule doesn't apply.  It is permitted to do as it 
pleases.  Given the widespread ignorance of user-detail addresses, it 
seems helpful to have something to point to that tells these boxes to 
preserve this.

>  mention this separator, since it is a local decision.

Mentioning it, with examples, is probably a good thing, since it can 
help gain understanding.  The text shouldn't dictate the specific 
character, though.  Perhaps the text in Section 1, for example, that 
currently says

    In general, deployed forms of subaddressing divide the local-part of
    an email address into two strings, seperated by a delimiter
    character.  This is most commonly a plus sign, "+".

    This document does not document all forms of subaddressing, merely
    the most common form, also known as "plus-addressing".  Other forms
    are also deployed, sometimes using a minus sign, and in some rare
    cases using encoding rules rather than simple catenation.

Could be changed to

    In general, deployed forms of subaddressing divide the local-part of
    an email address into two strings, seperated by a delimiter
    character.  This is most commonly a plus sign, "+".

    For clarity, the examples in this document all use the "+" (which is also
    known as "plus-addressing".  Other forms
    are also deployed, sometimes using a minus sign, and in some rare
    cases using encoding rules rather than simple catenation.

And then change non-example uses of "+" to "the delimiter".  Also add 
"the delimiter" to the Definitions, and fix the ABNF to allow other 
safe characters that aren't "%" as the delimiter.

Maybe it should also suggest NOT using "%", since many systems treat 
the presence of this character in the local-part as an attempt to 
relay and hence an attack.

>  properly.

Yes, this is a major problem.

>   Certainly, an informational RFC asking to accept valid email

This is useful, but separate.  (Also, wasn't this done a few years ago?)
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
If A = B and B = C, then A = C, except where void or prohibited by law.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 4 Dec 2007 17:16:59 +0100

On Mon, Dec 03, 2007 at 10:24:03PM +0000,
 Dave Cridland <[email-masked]> wrote 
 a message of 89 lines which said:

> As good as any.

May be [email-masked] would have been a better place?

> Subaddressing isn't described anywhere, 

That's the whole point, I believe. Subaddressing has always been a
matter of local conventions (like the [email-masked]
convention in many environments), not needing to be "described".

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.

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 4 Dec 2007 17:20:40 +0100

On Mon, Dec 03, 2007 at 07:45:47PM -0800,
 Randall Gellens <[email-masked]> wrote 

> email lore that some implementers are aware of while others are not.

And that's the right way: subaddressing does not have to be
documented, it is a local convention. (How can you tell if
[email-masked] is not an address with subaddressing and "m" as the
delimiter?)

> Formalizing the concept is a good thing. 

I'm not convinced.

> This is useful, but separate.  (Also, wasn't this done a few years ago?)

I do not think so, alas. I'm engaged in a personal crusade against
such Web forms and the 1 or 2 % of the webmasters who do reply to my
complaints always said that [email-masked] is not a legal
email address... Pointing them to RFC 2822 does not help, the grammar
is too... funny.

---

From: Bill McQuillan <[email-masked]>
Date: Tue, 4 Dec 2007 09:35:00 -0800

> That's may be a good idea but it is something new, not a description

Well, it seems to be "partial" current practice. My public email address
goes to a forwarder (pobox.com) that, being fairly knowledgable in the
email area, will rewrite my address while preserving the detail portion
when forwarding it to my actual ISP. I know they understand the "+"
delimiter, but I haven't tested other delimiters.

Unfortunately, my current ISP rejects such addresses as Recipient Unknown!
This means that MY "local convention" is thwarted by my ISPs "border
servers".

I would love to point the ISP to an RFC that shows them what ought to be
allowed.

-- 
Bill McQuillan <[email-masked]>

---

From: Keith Moore <[email-masked]>
Date: Tue, 04 Dec 2007 10:05:26 -0800

> That's may be a good idea but it is something new, not a description
I don't know how widespread the practice is, but my "bulk_mailer"
software (which used to get a lot of use, anyway) has supported this
kind of fuzzy matching since 2002.  (it also does fuzzy matching on the
domain part, so that a.example.com is treated as equivalent to
b.example.com and example.com)

---

From: der Mouse <[email-masked]>
Date: Tue, 4 Dec 2007 13:54:39 -0500 (EST)

>> [..."global subaddressing"...]
> Well, it seems to be "partial" current practice.  My public email
> address goes to a forwarder (pobox.com) that, being fairly
> knowledgable in the email area, will rewrite my address while
> preserving the detail portion when forwarding it to my actual ISP.

Sure, but this is by private agreement among pobox.com, you, and your
actual provider; it is hardly "global", and, as with almost everything
else involving local-parts, is the business of nobody but those three
parties.

> Unfortunately, my current ISP rejects such addresses as Recipient
> Unknown!  This means that MY "local convention" is thwarted by my
> ISPs "border servers".

Yes, anyone who rejects plussed addresses because they think the plus
sign renders the address invalid is broken.

> I would love to point the ISP to an RFC that shows them what ought to
> be allowed.

2822 (and 2821, which refers to 2822 for many things, including this).

Given their present position, they probably aren't going to want to
even read it, much less implement it.  To me this means you need to
stop getting mail through them, switching instead to someone who
actually understands email.  Fortunately, there are many places that
will cheerfully host email for you, for comparatively little money -
you might even be able to find one willing to comp your account.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Keith Moore <[email-masked]>
Date: Tue, 04 Dec 2007 13:50:34 -0800

> I would love to point the ISP to an RFC that shows them what ought to be
is this a case of your ISP not supporting subaddressing on its mail
servers, or a case of your ISP imposing an interception proxy that
interferes with traffic to your own mail servers?

---

From: Dave Cridland <[email-masked]>
Date: Tue, 04 Dec 2007 23:50:57 +0000

On Tue Dec  4 16:16:59 2007, Stephane Bortzmeyer wrote:
>  Dave Cridland <[email-masked]> wrote  a message of 89 lines  
> which said:
> 
> > As good as any.
> 
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).

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

> That's may be a good idea but it is something new, not a description
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.

> 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  
<[email-masked]>, and not <[email-masked]>. Such MSAs need to  
be aware that <[email-masked]> 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:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Keith Moore <[email-masked]>
Date: Tue, 04 Dec 2007 16:23:08 -0800

Dave Cridland wrote:
>
>> > Subaddressing isn't described anywhere,That's the whole point, I
>> believe. Subaddressing has always been a
> Yes, it's a convention local to a specific ADMD.
I don't know what an ADMD is in the context of Internet email.  AFAIK
it's never been clearly defined in this context and I think it's
probably misleading to use the term.

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

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

(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)
> 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.  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
> be aware that <[email-masked]> is also valid for me, because it
> is the same "primary address", even if they've never seen it before.
yes, MSAs that verify the return address need to be aware of which
return addresses are (a) valid and (b) usable by the authenticated
submitter.
> then it needs to know for this, too.
so far, I'm unconvinced of this .

Keith

---

From: der Mouse <[email-masked]>
Date: Wed, 5 Dec 2007 01:27:53 -0500 (EST)

> [...subaddressing...plussed addresses...]

The biggest worry I have is that this will lead to people who currently
design busted webforms who reject plussed addresses will start
accepting + but none of the other variants, under the impression
they're fixing something, and, worse, that they will then point to this
as some kind of weird justification for their brokenness.

Of course, people with the proverbially-dangerous "little learning"
have never been stopped by lack of justificatory documents....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Dave Cridland <[email-masked]>
Date: Wed, 05 Dec 2007 10:08:47 +0000

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

> part of a return address.
That text is better, yes. I'll use something very similar.

> work better, the list might provide better service to its  

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

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

> my normal address and have the list subscription go to the  

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  
<[email-masked]> copied to a mailing list which has a  
(Subaddress-enabled) subscriber of <[email-masked]> would  
cause the MLM to go as far as rewriting headers to the subscribed  
address.

> 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

Yup.

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

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

---

From: Tony Finch <[email-masked]>
Date: Wed, 5 Dec 2007 10:54:23 +0000

On Tue, 4 Dec 2007, Dave Cridland wrote:
>
> 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.

A particular example would be an in-MUA Sieve implementation.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOLE LUNDY FASTNET IRISH SEA SHANNON: WEST OR SOUTHWEST 6 TO GALE 8,
OCCASIONALLY SEVERE GALE 9. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH. RAIN OR
SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

---

From: Keith Moore <[email-masked]>
Date: Wed, 05 Dec 2007 07:18:37 -0800

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

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

> essential - but it makes it possible to build a clean UI and several
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

---

From: Dave Cridland <[email-masked]>
Date: Wed, 05 Dec 2007 18:16:01 +0000

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

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

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

> particular MUAs then they need to make sure that their MUAs are  
I think the document has the beginnings of this.

> function.

Well, ManageSIEVE is such a protocol.

>   I can also imagine an MUA having the ability to use a
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.

> to be the same.  though admittedly that makes for a more complex  
Agreed on all counts. Expressly in the document is that by default,  
there is no such relationship.

Dave.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 5 Dec 2007 14:36:00 -0800

At 5:20 PM +0100 12/4/07, Stephane Bortzmeyer wrote:

>  documented, it is a local convention.

Even as a local convention, it is helpful to have a document that describes it.

>   (How can you tell if

Only the recipient's environment needs to know.  I certainly don't 
need to know if I'm sending you email if the particular address I 
have for you is subaddressed.

At present, the document does contain text about list servers 
recognizing subaddressing.  This is the one area where I'm not 
convinced.  I can see the benefit, but I think that once we allow for 
anything that isn't after final delivery knowing about subaddressing, 
at that point we have changed it from a purely local convention to 
one that does indeed have meaning elsewhere, and we pretty much are 
then forced to choose a single (or maybe two) character for the 
delimiter.  Because of this, I am wavering as to if we should mention 
list servers or not.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The nice thing about standards is that there are so many of
them to choose from.                  --Andrew S. Tanenbaum

---

From: Randall Gellens <[email-masked]>
Date: Wed, 5 Dec 2007 14:45:46 -0800

At 10:08 AM +0000 12/5/07, Dave Cridland wrote:

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

There isn't any way to tell the MLM, though, aside from some 
administrative interface that is beyond the reach of most users of 
most MLMs.  That's why I'm not convinced that the list server text is 
worth keeping.

> can't really find much documentation. (List-* header fields not 

There's also a document a while back on using standard addresses, 
such as the -request address, and standard commands, IIRC.  But a BCP 
on MLMs would be a good thing.

> cause the MLM to go as far as rewriting headers to the subscribed 

This makes me nervous.  There may be some reason why a particular 
subaddress was used for a message.  I don't think the MLM is in any 
position to know what is the right thing to do here.  I'd be 
delighted if my MUA would let me assign a default From address (or 
"personality" or "account") to use when I send a message to a 
particular recipient.  The MUA is in the best position to do this, 
and there is still the opportunity for the user to correct it.  There 
is no chance for this at the MLM.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
We adore chaos because we love to produce order.
                                  --M. C. Escher

---

From: Randall Gellens <[email-masked]>
Date: Wed, 5 Dec 2007 14:51:01 -0800

At 7:18 AM -0800 12/5/07, Keith Moore wrote:

>  I am dubious that MUAs or users should assume that

Yes -- it is better to think of them as a general ability to tag 
inbound mail for some sort of special processing.  The fact that some 
delivery agents have a default rule of delivering into a mailbox 
whose name exactly matches the detail part is merely an optimization.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
A bird in the hand is safer than one overhead.

---

From: der Mouse <[email-masked]>
Date: Wed, 5 Dec 2007 18:58:55 -0500 (EST)

>> within the ADMD (at least for this subscriber),

This raises another hazard of a convention like this: it can lead to
things like MLMs assuming that anything with a + (or whatever
deliminiter is chosen) is an instance of this convention, leading to
severe brokenness when faced with addresses at a site that doesn't work
that way.

FWIMBW, I'd prefer to see emphasis on the "nobody but the receiver and
those with out-of-band knowledge of the receiver have any business
assuming anything about local-parts" aspect.  If my system happens to
have an address with local-part *^%+_!^! (or, more plausibly, one+two)
nobody without special knowledge of my system has any business
inferring any structure from that; in particular, inferring that
local-parts *^% (or one, respectively) even exist, much less bear any
relationship to the full form, is broken - absent, of course, specific
out-of-band reason to think the relevant mailer uses plussed addresses.

> This makes me nervous.

Me too.  Your reason strikes me as valid, but I'm actually more worried
that implementors will lose that "(subaddress-enabled)" part and simply
assume subaddresses - after all, it's Standard, right? - and end up
sending mail to the wrong places.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Dave Cridland <[email-masked]>
Date: Mon, 03 Dec 2007 22:24:03 +0000

As good as any.

> normalizes or what its purpose is.
Subaddressing isn't described anywhere, much - the closest we come is  
in the SIEVE subaddress extension. This is fine - as you say, it's a  
purely local thing - except that multiple components are involved.  
 From an inter-domain perspective, there is nothing to do - unless  
you consider mailing list managers - but for the communications  
between the components of an MHS, there are several areas which would  
benefit from a consistent handling of subaddressing.

1) The final MTA.
2) The MDA.
3) The MUA.

The behaviour of all of these, and in particular how they interact,  
most certainly is within the scope of the IETF.

> addresses", and that is a general rule, it is not only for
Oh, indeed, there's lots of sentences which were much more useful a  
decade ago, and these days are surplus to requirements.

> mention this separator, since it is a local decision.
Now here I disagree - a common syntax for subaddressing isn't  
absolutely required from a technical perspective, but it makes  
considerable sense for subaddress-aware entities to have the same  
general notion of what syntax to use, to reduce configuration  
requirements, both for sysadmins and users alike.

> (the comments are interesting, too).

You're not the first to raise this, but I'm not convinced that this  
draft is the right place to give such advice. It would, however, be a  
useful place for such a draft to point to by way of example.

Dave.