Subject: rfc 2119 violation
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Date: 10 Aug 1997 06:09:48 -0000

I asked Scott Bradner, the author of RFC 2119, about Newman's ``MUST be
delivered to that primary address by default'' requirement. Scott wrote
back after reviewing Newman's spec.

``In looking at the text I think you are correct in detail---i.e. this
is not a case of ensuring interoperability between systems so it does
violate the caution in rfc 2119,'' he says. ``It seems like the author
is trying to ensure consistent user-level behavior, a reasonable goal,
but the use of MUST seems out of place.''

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

From: Masataka Ohta <[email-masked]>
Subject: please don't feed the Keith
To: [email-masked] (Keith Moore)
Date: Sat, 9 Aug 97 11:45:10 JST
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Keith;

> As usual, Dan Bernstein has managed to take a civil, technical discussion and 
> turn
> it into a sewer -- with insults, inappropriate accusations, and 
> misattributions.

Keith, it's your usual behaviour.

							Masataka Ohta

Date: Fri, 08 Aug 1997 17:08:30 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: please don't feed the Dan
To: Joe Kelsey <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Fri, 8 Aug 1997, Joe Kelsey wrote:
> In this case he has correctly analyzed the broken proposal of Newman as
> being an attempt to make the CMU/Innosoft subaddress scheme a global
> requirement simply for the perceived benefit of one administrator who
> doesn't want to support what user's really want to do.

Guessing other people's motives is always a dubious venture, and both Dan
and you have guessed incorrectly.  My motives are as follows:

(1) I like subaddressing and think others would like it as well.

(2) Quality MUA interfaces for subaddressing can't be built without a 
standard since it requires cooperation between MUA and the final delivery
agent (which usually are on different hosts).

(3) Certain spam-limitation efforts on MLMs make the use of subaddresses
for subscriptions a real pain.

(4) I like to write standards for the benefit of the community.  I also
noted that this would benefit my employeer, but that has more impact on
my personal vs. work time allocation then anything else.  This is a
personal proposal -- not an Innosoft or CMU proposal.

So I wrote a _first rough draft_ of a standard based on personal
experience with the intent to address (1)-(3).  I brought the rough draft
forward for public comment so it can be refined to a level suitable for
standardization, if possible.

The result is that I've learned a lot more about how people use
subaddresses and will make substantial revisions in the next draft.  Now
can we please end the confrontational garbage and stick with technical
issues?

		- Chris

Date: Fri, 8 Aug 1997 16:07:00 -0500 ()
From: Allen Gwinn <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked]
Subject: Re: please don't feed the Dan
Sender: [email-masked]

Well, I haven't posted in a long time, so, here goes!

First off, I disagree with you, Keith.  Dan usually has a very good
technical sense about him.  The only thing, perhaps, that I could side
with you on is the alt.flamisms.  Although I don't post alot, I feel that
his rationale and arguments wrt subaddressing and this whole line has been
well thought out.  Perhaps if everybody stuck to the issues and spent a
little less time flaming -- but on the other hand addressing the concerns
of the other parties (rather than toting their own party line) we'd
actually do things that benefitted the 'Net, eh?

Cheers!

Allen

On Fri, 8 Aug 1997, Keith Moore wrote:

> As usual, Dan Bernstein has managed to take a civil, technical discussion and 
> turn
> it into a sewer -- with insults, inappropriate accusations, and 
> misattributions.
> 
> Dan is right some of the time, and occasionally he even manages to produce a
> cogent and convincing argument.  So it's sometimes worthwhile to read his 
> opinion
> on a subject.
> 
> But I've never seen an occasion where responding to a message from Dan yielded
> anything useful.  Either you agree with him, in which case he'll use it against
> you later, or you disagree with him, in which case he'll respond with insults.
> 
> The result of replying to Dan is nearly always to polarize the discussion --
> to change it from a discussion aimed at honing technical details or fine tuning
> language, to a discussion about whether Dan is right or wrong.  
> 
> While such a discussion might be entertaining to those involved, it's certainly
> not going to produce anything useful. 
> 
> So please - don't feed the Dan.  
> 
> Read his messages if you want to, but resist the temptation to respond.  If 
> you
> do respond, consider responding directly to the list, rather than replying to 
> Dan
> with a cc to the list.  Address the topic of discussion in your own language, 
> with a new Subject header, rather than responding to his diatribes on a 
> point-by-point basis.    
> 
> This will make it possible for the other list members to see the variation in
> opinion, rather than how strongly people agree or disagree with Dan.
> 
> Keith
> 
> 
> 

Date: Fri, 8 Aug 1997 11:59:13 -0700 (PDT)
From: Joe Kelsey <[email-masked]>
To: [email-masked]
Subject: please don't feed the Dan
Sender: [email-masked]

I have to say that I completely disagree with Keith on this issue.

Dan has the most cogent, well-thought out sense of a problem of anyone I
have ever encountered on the net.  He has the ability to see through all
of the vagueness and unclear thinking that most users use when posting
messages and boil things down the the basics very quickly.

In this case he has correctly analyzed the broken proposal of Newman as
being an attempt to make the CMU/Innosoft subaddress scheme a global
requirement simply for the perceived benefit of one administrator who
doesn't want to support what user's really want to do.

I have never seen an issue where I disagreed with Dan.  He does tend to
assume that everyone can use the same completely logical thought
processes to arrive at his conclusions, so sometimes it takes people a
little longer to understand his positions.  Or, sometimes people refuse
to take the time to think an issue through and so they never understand
his conclusions, in which case a flame war erupts.  However, the
original source of the flames is always someone who through prejudice or
inability to use logic cannot understand his original position.

/Joe

Date: 8 Aug 1997 18:34:08 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: watch Moore squirm
Sender: [email-masked]

It's always rather amusing to watch Keith Moore trying to defend the
standardization of inferior technology.

> with insults, inappropriate accusations, and misattributions.

Hmmm. Are you saying that you prefer ``Newman's inferior technology'' to
``Innosoft's inferior technology''?

> to change it from a discussion aimed at honing technical details

Unlike some people here, I never use general complaints as an excuse to
ignore specific engineering issues.

> Address the topic of discussion in your own language, 
> with a new Subject header, rather than responding to his diatribes on a 
> point-by-point basis.    

Translation: ``Please don't discuss the specific costs and benefits of
Newman's proposal. The IESG knows what is Right For The Internet, damn
it, and if we decide that we have to standardize an inferior proposal,
we don't want people to talk about how incompetent we were.''

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

To: [email-masked]
Subject: please don't feed the Dan
cc: [email-masked]
From: Keith Moore <[email-masked]>
Date: Fri, 08 Aug 1997 12:40:59 -0400
Sender: [email-masked]

As usual, Dan Bernstein has managed to take a civil, technical discussion and 
turn
it into a sewer -- with insults, inappropriate accusations, and 
misattributions.

Dan is right some of the time, and occasionally he even manages to produce a
cogent and convincing argument.  So it's sometimes worthwhile to read his 
opinion
on a subject.

But I've never seen an occasion where responding to a message from Dan yielded
anything useful.  Either you agree with him, in which case he'll use it against
you later, or you disagree with him, in which case he'll respond with insults.

The result of replying to Dan is nearly always to polarize the discussion --
to change it from a discussion aimed at honing technical details or fine tuning
language, to a discussion about whether Dan is right or wrong.  

While such a discussion might be entertaining to those involved, it's certainly
not going to produce anything useful. 

So please - don't feed the Dan.  

Read his messages if you want to, but resist the temptation to respond.  If 
you
do respond, consider responding directly to the list, rather than replying to 
Dan
with a cc to the list.  Address the topic of discussion in your own language, 
with a new Subject header, rather than responding to his diatribes on a 
point-by-point basis.    

This will make it possible for the other list members to see the variation in
opinion, rather than how strongly people agree or disagree with Dan.

Keith

Date: 7 Aug 1997 23:55:58 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: failure to address objections
Sender: [email-masked]

  [ existing addresses, not subaddresses, containing "+" ]
> For the MLM rules this is a non-issue.

False.

Your MLM rules impose a global syntax and global semantics. Whenever one
of your ``subaddress aware'' MLMs accepts [email-masked],
it is also required to accept bob+liz.

This global scheme is incompatible with existing addresses. Your MLM
requirement is a security violation.

> I have attempted to respond to every one of your technical objections.

Mm-hm. Where exactly is your response to the widget-request problem?

Just to refresh your memory: There's a group project account called
widget. ``widget'' is also the mailing list for that project, run by
some MLM.

Most separators are incompatible with the de facto ``-request''
standard. If "+" is the separator, for example, the widget people will
end up pestering the sysadmin for a special ``widget-request'' alias.

With "-" as the subaddress separator, the widget account automatically
controls ``widget-request'', as well as ``widget-owner'' and
``widget-subscribe'' and whatever other addresses the MLM might support.
This is clearly superior.

Getting you to admit that the right address is ``widget-request'' and
not ``widget+request'' was like pulling teeth; I had to ask three times.
Apparently you don't want to admit any benefits of "-". You've spent far
more time claiming, incorrectly, that "-" doesn't work.

> In fact one of the more popular email address
> conventions <first.last@domain> conflicts with your use of "-" due to
> dashed last names. 

False. Many qmail sysadmins use this convention. There is no conflict.

For example, if there are jean and jean-pierre.serre accounts, the
jean-pierre.serre account controls jean-pierre.serre-books-request.
(UNIX traditionally doesn't support such long account names, but qmail
supports a translation table: e.g., jps:jean-pierre.serre.)

Similarly, if + is the separator, and there are smith and smith+co
accounts, the address smith+co+help is controlled by smith+co.

Next strawman?

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: Thu, 07 Aug 1997 15:05:35 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: failure to address objections
To: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Thu, 7 Aug 1997, D. J. Bernstein wrote:
> For example, qmail automatically handles existing usernames containing
> the separator character. Newman's proposal doesn't.
> 
> This is not a minor issue. This is a fundamental flaw in Newman's
> proposal. His insistence on a global syntax means that he cannot handle
> existing usernames correctly.

For the MLM rules this is a non-issue.  It is an issue for the final
delivery agent if there are legacy usernames on the system.  The latter
case will be addressed.

> As another example, qmail's default separator, "-", automatically gives
> ``project'' control over MLM addresses such as ``project-request''.
> Newman's proposal doesn't.

The character "-" is used as a non-hiearachy separator much more commonly
than "+" is so used.  In fact one of the more popular email address
conventions <first.last@domain> conflicts with your use of "-" due to
dashed last names.  And just to make myself clear, I'd be willing to
agree to change to "=" as the default.  My objection is solely a technical
objection to "-".

> Newman hasn't shown any willingness to address these objections---
> because addressing them would mean throwing his proposal away. He just
> ignores them. That's dishonest.

This statement is false.  I have attempted to respond to every one of your
technical objections.  This is very difficult to do as it is hard to
separate the technical content of your messages from the self-promotion,
insults, attacks and empty rhetoric.

> Why are you recommending Innosoft's inferior technology? 

Your public attacks on my employeer are misleading, tiresome, pointless
and very obnoxious.  If you want me to listen to your technical comments,
stop attacking my employeer and myself publicly.  I will not respond to
this sort of blather again.

		- Chris Newman

Date: 7 Aug 1997 19:44:45 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: failure to address objections
Sender: [email-masked]

> "what you already know is better"

qmail _is_ better.

For example, qmail automatically handles existing usernames containing
the separator character. Newman's proposal doesn't.

This is not a minor issue. This is a fundamental flaw in Newman's
proposal. His insistence on a global syntax means that he cannot handle
existing usernames correctly.

As another example, qmail's default separator, "-", automatically gives
``project'' control over MLM addresses such as ``project-request''.
Newman's proposal doesn't.

Newman hasn't shown any willingness to address these objections---
because addressing them would mean throwing his proposal away. He just
ignores them. That's dishonest.

Similarly, you're pretending that qmail's superiority is merely a matter
of ``what you already know.'' But it's not. Users really do complain
when their mail doesn't get delivered.

> a guideline and recommendation,

Please try to act like an engineer who actually cares about engineering
failures. Why are you recommending Innosoft's inferior technology? 

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: 7 Aug 1997 18:26:20 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: MLM subaddress requirement
Sender: [email-masked]

> It's not reasonable to use *any* return-path or header that's visible,
> as a password to access sensitive information.  

People protect this mechanism with strong authentication---e.g., PGP.

> There's nothing wrong with refining that heuristic to allow posting
> from [email-masked] if the subscriber address is [email-masked].

It breaks existing PGP-protected mailing lists, turning good security
into nonexistent security.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: Thu, 07 Aug 1997 09:14:33 -0400 (EDT)
From: John C Klensin <[email-masked]>
Subject: Re: MLM subaddress requirement
To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Reply-to: John C Klensin <[email-masked]>
Sender: [email-masked]

On Wed, 06 Aug 1997 16:27:41 -0400 Keith Moore 
<[email-masked]> wrote:

>...
> But if the list is potentially available to anyone just for signing
> up, comparing the return-path isn't really an authentication mechanism
> -- it's just a crude heuristic to filter out bogons. 
> 
> There's nothing wrong with refining that heuristic to allow posting
> from [email-masked] if the subscriber address is [email-masked].

Keith,

This, with which I agree, brings us back to a note I sent Chris 
some weeks ago that suggested that some of the issue being 
addressed was "too little, too late".  While I found his 
response was reasonable, the "what is the list manager to do" 
question brings me full circle. If I can have

  subscribe foo-list [my-address]

(i.e., get a slightly funny address in there without messing 
with the From field) then the author of an automated list 
manager can presumably extend that to

   subscribe foo-list [outbound-address] [inbound-address]

or

   subscribe foo-list [outbound-address] 
                         [subaddress-indicator-and-delimiter]

The posting/acceptance engine has to understand either the rule 
or a pair of lists in any case, so getting this from the user, 
especially if we start automating the subscription process, is 
just not a big deal.  And this model would permit someone to use 
"-", someone else to use "+", a third party to use "=" and, 
modulo some understanding about what to do if more than one such 
symbol is encountered (an area where a recommendation would be 
very useful in avoiding user astonishment), and the rest of us 
to get on with our lives.

My local MUA and MTA would probably need to be told too, but 
that is presumably a local problem -- they probably know what 
they are willing to treat as a subaddress.

There are, of course, authentication problems in any of these 
cases.  But they aren't much different by case, and the cheap 
heuristics, as you point out, don't accomplish much or provide 
much protection against anything but a casual slip-up.

While I wish we could do something sensible about subaddresses, 
our experience has been that every attempt to relax the rule 
that nothing but the destination host is permitted to interpret 
or mess with the local-part leads to a "gotcha" somewhere.  I 
fear the discussion of the last week or so is evidence that we 
now have another example.

Recommendation: 
  (i) We progress a revised version of Chris's note as 
       a guideline and recommendation, not a standard.  You 
       and IESG figure out how to do that: vote-counting among 
       captive audiences is silly, since this is one of those
       "what you already know is better" situations.
  (ii) We try to get a strong "security considerations" statement
       into the revision that discusses the interplay between
       subaddressing mechanisms and various security UI models.
    (iii) We keep it from saying anything that will violate the
       "don't mess with the local-part" rule.
    (iv) We create a separate document, or a clearly-deliniated
       piece of Chris's document, addressed to authors of 
       automated intermediary systems (e.g., list exploders and
       semi-automatic list maintainer software).  It should start
       from the premiss that people _will_ use these things and
       thus give advice about the facilities such systems might
       sensibly use to minimize trouble and effort.

Does that make sense and, if so, do we have volunteers to do 
some calm writing (as distinct from more flaming, misquotation 
and misinterpretation, etc.)?  If we believe that this is 
important and useful enough to justify the recent traffic level, 
then Chris shouldn't have to do all of the writing (although it 
is fine with me if he wants to sign up).

   john

From: Keith Moore <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Ned Freed <[email-masked]>, "Kenzaburou Tamaru (Exchange)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: comment for draft-moore-mime-cdisp-00 
Date: Wed, 06 Aug 1997 16:59:02 -0400
Sender: [email-masked]

> I just read it.
>
> The problem is that it uses character sets other than ASCII and
> Unicode.  This is a serious burden, since it essentially requires
> that every application in the world maintain character set
> conversion tables.  

If this were a new application protocol, I'd agree with you.  But this
burden already exists for MIME mail readers, so by using existing MIME
charsets we're not imposing an additional implementation burden beyond
the need to parse the new parameter sytnax.

At some point we might get consensus to deprecate the use of
everything but Unicode in email.  But I suspect it will be a long time
before this happens.

In the meantime, we'd only be increasing implementation complexity to
have one standard for charsets in displayable text, and another
standard for charsets in parameters.  

Besides, we'd never get consensus to impose such a restriction.

> Actually, it's worse than that; it uses charsets
> which are even more disgusting than character sets.

The MIME notion of 'charset' was right (and is still right) for
text-based mail which is intended for display.  'charset' is probably
not right for the representation of filenames, but the differences are
so subtle that trying to explain them to most people only increases
the confusion.

Keith

From: Keith Moore <[email-masked]>
To: "Kenzaburou Tamaru (Exchange)" <[email-masked]>
cc: [email-masked], Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: comment for draft-moore-mime-cdisp-00 
Date: Wed, 06 Aug 1997 16:50:06 -0400
Sender: [email-masked]

> Regarding the Filename parameter, none of Asia language is taken into
> consideration. As result, it is sort of nightmare in specially Japan.
> Many copmanies use different encoding scheme. This is because none of
> RFC does allow to use Asia character for file name as of today, it
> allows only US-ASCII. 

I believe this is solved with draft-moore-mime-cdisp-01.txt, which
references draft-freed-pvcsc-03.txt.

In particular, a content-disposition header could look like

content-disposition: attachment; filename*=iso-2022-jp'xx'yyyyyyyy

where xx is the ISO 639 language code for Japanese (sorry, I don't
have a copy of ISO 639) and yyyyyyyy is Japenese text in iso-2022-jp
charset encoded using URL-style "%XX" encoding for each octet.

Unfortunately, the encoding is very inefficient.  Each Japanese
two-octet character will require six ASCII characters to encode (for
example, ABCD hex gets encoded as "%AB%CD") Text in the UTF-8 charset
would require even more encoding overhead using this method.

So while it is possible to encode text in any language using this
method, I could certainly understand if users of Asian languages would
prefer a more efficient encoding for those languages.

Keith

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: MLM subaddress requirement 
Date: Wed, 06 Aug 1997 16:27:41 -0400
Sender: [email-masked]

> Have I made this clear? YOU CANNOT REQUIRE OR EVEN SUGGEST THAT AN MLM
> DO ANYTHING WITH SUBADDRESSING UNLESS IT IS EITHER A 'MUST' STANDARD OR
> YOU HAVE A WAY OF TELLING ON THE FLY IF THE REMOTE SITE SUPPORTS IT.

I strongly disagree.

It's not reasonable to use *any* return-path or header that's visible,
as a password to access sensitive information.  

(One could even imagine that the security considerations section of an
RFC saying you MUST NOT use a Return-Path or From header as an
authentication mechanism.)

But if the list is potentially available to anyone just for signing
up, comparing the return-path isn't really an authentication mechanism
-- it's just a crude heuristic to filter out bogons. 

There's nothing wrong with refining that heuristic to allow posting
from [email-masked] if the subscriber address is [email-masked].

Keith

Date: Wed, 6 Aug 1997 10:14:47 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: comment for draft-moore-mime-cdisp-00
To: Ned Freed <[email-masked]>
cc: "Kenzaburou Tamaru (Exchange)" <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, 06 Aug 1997 08:30:05 -0700 (PDT), Ned Freed wrote:
> I-D draft-freed-pvcsc-03.txt, which was recently approved as a proposed
> standard.

I just read it.

The problem is that it uses character sets other than ASCII and Unicode.  This
is a serious burden, since it essentially requires that every application in
the world maintain character set conversion tables.  Actually, it's worse than
that; it uses charsets which are even more disgusting than character sets.

It is alright to encode 8 in 7.  I have no problem with that part of it.  The
problem is the idea of expanding the broken idea of charsets to yet another
place where it doesn't belong.

Language is also good.

The problem is only in the contination of charsets, which is against the
recommendation in the first paragraph of section 8.2 of RFC 2130.

To: Ned Freed <[email-masked]>
Cc: "Kenzaburou Tamaru (Exchange)" <[email-masked]>, [email-masked], Mark Crispin <[email-masked]>
Subject: Re: comment for draft-moore-mime-cdisp-00 
From: [email-masked]
Date: Wed, 06 Aug 1997 12:41:36 -0400
Sender: [email-masked]

--==_Exmh_1761536784P
Content-Type: text/plain; charset=us-ascii

On Wed, 06 Aug 1997 08:36:58 PDT, Ned Freed said:
> Because we could never reach agreement on how, given a filename from a local
> system, to accurately map it into and out of a legal filename parameter value.
> Think about message/external-body, an FTP server that does localization based
> on client origin, and the name= parameter in this case, and you'll see what I'm
> talking about.

Hmm.. I remember that flame-fest..I just couldn't remember it at 4AM.. ;)
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_1761536784P
Content-Type: application/pgp-signature

--==_Exmh_1761536784P--

Date: Wed, 06 Aug 1997 08:36:58 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: comment for draft-moore-mime-cdisp-00
To: [email-masked]
Cc: "Kenzaburou Tamaru (Exchange)" <[email-masked]>, [email-masked], Mark Crispin <[email-masked]>
Sender: [email-masked]

> The more correct answer here is to allow RFC2047 header-encoding to be used
> in the 'dstring' field.  This way, other encoding systems besides UTF8
> can be used if desired.

Close but not quite. The main problem with using pure RFC2047 parameter values
is that equals signs are involved, and the quoting that results gets really
messy.

Another problem is that we really don't want to allow more than one character
set in a single value.

So what we ended up with is a mechanism that reuses only parts of RFC2047.
This works, and in fact works well.

> Unfortunately, it's past 4AM local time and I can't remember why we didn't
> allow the 2047-style encoding in the first place.  Somebody else here
> remember why we did that?

Because we could never reach agreement on how, given a filename from a local
system, to accurately map it into and out of a legal filename parameter value.
Think about message/external-body, an FTP server that does localization based
on client origin, and the name= parameter in this case, and you'll see what I'm
talking about.

It was only by avoiding this issue entirely that we were able to come up
with an acceptable approach. Pity we didn't realize this five years ago,
but there you are...

				Ned

Date: Wed, 06 Aug 1997 08:30:05 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: comment for draft-moore-mime-cdisp-00
To: "Kenzaburou Tamaru (Exchange)" <[email-masked]>
Cc: [email-masked], Mark Crispin <[email-masked]>
Sender: [email-masked]

> Regarding the Filename parameter, none of Asia language is taken into
> consideration.

This is simply not true. This draft specifically references the
I-D draft-freed-pvcsc-03.txt, which was recently approved as a proposed
standard. This draft provides a means by which any MIME content-type
parameter or content-disposition parameter can be encoded, can have
a character label, and can have a language label. As such, not only is
it possible to have filenames containing Asian characters, the mechanism
for doing so is already standardized.

> As result, it is sort of nightmare in specially Japan.
> Many copmanies use different encoding scheme. This is because none of
> RFC does allow to use Asia character for file name as of today, it
> allows only US-ASCII.

The one thing the draft doesn't do is deal with the issue of what character
sets to use when. And make no mistake about it -- this _is_ a nightmare.
This is the reason we didn't define a mechanism when MIME was first developed.
What we've done now is simply avoid this issue because were we to try and
deal with it we'd never have reached any sort of consensus. 

> Since using double-byte character is very natual in Asia countries as
> file name. filename-paran := "filename" "=value" need to be more
> considered to be able to accomodate non-US-ASCII character for value
> field. MIME-2(Message Header Extensions for Non-ASCII) is defined as
> extension for header field., I don't think this can be applied to this
> "value".

This has already been. See the referenced draft.

> It is time to say like
> ---------------------------------------------
> disposition-param := filename-param
> 	/..............
> filename-param := "filename" "=" dstring
> dstring := 1*utf8
> utf8 := <any sequence of octets formed from the UTF-8 transformation of
> a character from ISO 10646>
> ---------------------------------------------

This is unacceptable, as it would lead to 8bit characters in message headers.
Message headers have to remain 7bit to be compatible with the installed base.
But this is not a problem if the mechanisms we've defined are used.

				Ned

From: Peter Sylvester <[email-masked]>
Date: Wed, 6 Aug 1997 13:15:14 +0200
To: [email-masked]
Subject: extensions to local parts of mail addresses
Sender: [email-masked]

I wonder why nobody is coming up with the idea of a
more generalized way of extending mail addresses:

- It seems that for some purposes it is useful (on
  a global base) to associate additional information
  to an e-mail address. The example given is to
  add 'a subaddress'. 

- One might think about a general mechanism like for
  example:

  <"localpart;key=value;key=value"@domain>

  in order to associate different things to an address. 

- Examples: 

  To: "someone;reply=desired;receipttype=yes/none/negative"e@foo

- Of course this causes interoperability problems at several
  levels. (details left out as an exercise.) These need
  to be addressed, yes, that's part of the work to be done.

Peter

To: "Kenzaburou Tamaru (Exchange)" <[email-masked]>
Cc: [email-masked], Mark Crispin <[email-masked]>
Subject: Re: comment for draft-moore-mime-cdisp-00 
From: [email-masked]
Date: Wed, 06 Aug 1997 04:24:02 -0400
Sender: [email-masked]

--==_Exmh_919545674P
Content-Type: text/plain; charset=us-ascii

On Tue, 05 Aug 1997 21:06:19 PDT, "Kenzaburou Tamaru (Exchange)" said:
> field. MIME-2(Message Header Extensions for Non-ASCII) is defined as
> extension for header field., I don't think this can be applied to this
> "value".
> It is time to say like
> ---------------------------------------------
> disposition-param := filename-param
> 	/..............
> filename-param := "filename" "=" dstring
> dstring := 1*utf8
> utf8 := <any sequence of octets formed from the UTF-8 transformation of
> a character from ISO 10646>
> ---------------------------------------------

No.

The more correct answer here is to allow RFC2047 header-encoding to be used
in the 'dstring' field.  This way, other encoding systems besides UTF8 
can be used if desired.

Unfortunately, it's past 4AM local time and I can't remember why we didn't
allow the 2047-style encoding in the first place.  Somebody else here
remember why we did that?

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_919545674P
Content-Type: application/pgp-signature

--==_Exmh_919545674P--

From: "Kenzaburou Tamaru (Exchange)" <[email-masked]>
To: [email-masked]
Cc: Mark Crispin <[email-masked]>
Subject: comment for draft-moore-mime-cdisp-00
Date: Tue, 5 Aug 1997 21:06:19 -0700
Sender: [email-masked]

Regarding the Filename parameter, none of Asia language is taken into
consideration. As result, it is sort of nightmare in specially Japan.
Many copmanies use different encoding scheme. This is because none of
RFC does allow to use Asia character for file name as of today, it
allows only US-ASCII. 
Since using double-byte character is very natual in Asia countries as
file name. filename-paran := "filename" "=value" need to be more
considered to be able to accomodate non-US-ASCII character for value
field. MIME-2(Message Header Extensions for Non-ASCII) is defined as
extension for header field., I don't think this can be applied to this
"value".
It is time to say like
---------------------------------------------
disposition-param := filename-param
	/..............
filename-param := "filename" "=" dstring
dstring := 1*utf8
utf8 := <any sequence of octets formed from the UTF-8 transformation of
a character from ISO 10646>
---------------------------------------------

Thank you,
Kenzaburo Tamaru
Exchange Program Manager.
[email-masked]

Date: Tue, 5 Aug 1997 17:57:35 -0400 (EDT)
From: "Donald E. Eastlake 3rd" <[email-masked]>
To: [email-masked]
Subject: Re: MLM subaddress requirement 
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--==_Exmh_739160646P
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-ID: <[email-masked]>

On Tue, 5 Aug 1997 [email-masked] wrote:

> Date: Tue, 05 Aug 1997 16:03:10 -0400
> From: [email-masked]
> 
> On Tue, 05 Aug 1997 10:20:58 PDT, Chris Newman said:
> > What is the purpose of restricting postings based on the envelope address?
> > It's obviously *not* a security issue as anyone can generate email from
> > any address trivially (own a copy of Netscape?).  I claim the primary
> > purpose is to reduce spam.  Permitting postings from user if user+foo is
> > subscribed has no impact on this primary purpose.
> 
> ARGH!!!
> 
> How many times do I have to say this?
> 
> *YOU* *DO* *NOT* *KNOW* if 'user' and 'user+foo' are in fact the same
> address or not.  You cannot tell if the remote system sending the mail is
> or is not using your extension.

When non-ASCII text was added to 822 headers, a syntactic convention was
found which appears to have had no collision with any actually used ASCII
text, even though in principle it could.  It does not seem to me to be beyond
human ken to come up with such a syntax in this case.  It probably won't by
"+" or "-"  :-)

Donald 
=====================================================================
Donald E. Eastlake 3rd     +1 508-287-4877(tel)     [email-masked]
   318 Acton Street        +1 508-371-7148(fax)     [email-masked]
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.eff.org/blueribbon.html

--==_Exmh_739160646P--

Date: Tue, 05 Aug 1997 14:36:24 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: return-path security
To: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Tue, 5 Aug 1997, D. J. Bernstein wrote:
> The mailing list hides the return path, so the cookie isn't broadcasted
> to the mailing list. Of course, it's available in mail logs, but logs
> aren't public on well-run hosts. It's available to sniffers, but in any
> case the number of possible attackers has been drastically reduced. This
> is one of the most effective low-cost security mechanisms.

If the cookie is constant, this provides a mechanism with slightly worse
security than plaintext password logins, which are discouraged by the
IESG/IAB currently.  If the cookie is something like an HMAC-SHA1 computed
over a timestamp in the message and a secret, this is pretty cool but
worthless without interoperability between the MUA and MLM (thus requiring
a standard). 

> The main problem in practice is that, for many people, putting extra
> information into the return path is not as trivial as you claim.

Most modern MUAs have a text box in a preferences dialog to enter the
return path/sender/default from.  This does make it trivial to generate a
single message with any given return path, but is too cumbersome to
routinely change the return path.

A subaddress standard would encourage MUA authors to allow subaddresses to
be specified on a per-message basis or, even better, get the subaddress
from the personal address book for list postings.  So I conclude that a
subaddress standard could make your technique more usable down the road. 

		- Chris

Date: 5 Aug 1997 21:33:42 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: 50 people vs. newman
Sender: [email-masked]

> Your blantant commercialism pushing your own product

qmail is free software. I have no financial interest in it.

You may have trouble with this concept, but some people do things for
the good of the community, with no prospect of remuneration.

> I request that you withdraw your remark and appologize. 

Are you denying that Newman's system is inferior? For example, do you
claim that it handles existing usernames containing "+"?

> In you I see little but intrasigence and name calling. 

Your entire contribution to this discussion has been a series of vague
attacks---a transparent attempt to distract attention from the specific
objections I have raised to Newman's proposal.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: 5 Aug 1997 20:28:14 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: return-path security
Sender: [email-masked]

Correcting an error; no discussion of subaddresses.

> What is the purpose of restricting postings based on the envelope address?
> It's obviously *not* a security issue as anyone can generate email from
> any address trivially (own a copy of Netscape?).

On the contrary.

1. The return path is a very convenient place to put cookies.

With qmail, for example, a user can invoke ``cookie-check "$SENDER"''
before calling his usual mailing list manager.

The mailing list hides the return path, so the cookie isn't broadcasted
to the mailing list. Of course, it's available in mail logs, but logs
aren't public on well-run hosts. It's available to sniffers, but in any
case the number of possible attackers has been drastically reduced. This
is one of the most effective low-cost security mechanisms.

The main problem in practice is that, for many people, putting extra
information into the return path is not as trivial as you claim.

2. Another research security application of return paths is aimed at the
following problem: how do you protect subscribers from being flooded
with mail when lists are cross-subscribed? Suppose every mailing list is
subscribed to every other mailing list. What can the MLM do?

One answer is to set up Auto-Submitted on every mailing list. But this
is naive; it doesn't let people use sublists.

What I've implemented in ezmlm is the following combination of
techniques. Every mailing list sets the return path. Each sublist checks
that the incoming return path matches its parent list. Primary mailing
lists and MLMs generate Mailing-List fields, and reject messages with
existing Mailing-List fields. Sublists demand Mailing-List fields.

The result is that cross-subscriptions between ezmlm mailing lists are
eliminated. A primary mailing list won't accept messages that have
passed through any ezmlm mailing list, since all ezmlm mailing lists
have Mailing-List on all outgoing messages. A sublist won't accept
messages from any ezmlm mailing list other than its parent, since all
ezmlm mailing lists set the return path.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: Tue, 5 Aug 1997 16:17:33 -0400 (EDT)
From: "Donald E. Eastlake 3rd" <[email-masked]>
To: [email-masked]
Subject: Re: 50 people vs. newman
Sender: [email-masked]

On 5 Aug 1997, D. J. Bernstein wrote:

> Date: 5 Aug 1997 19:32:40 -0000
> From: D. J. Bernstein <[email-masked]>
> To: [email-masked]
> 
> > I can't tell what you are complaining about.
> 
> Newman's attempt to ``standardize'' Innosoft's inferior system.

Your blantant commercialism pushing your own product and bashing other's is
inappropriate.  I request that you withdraw your remark and appologize. 

> > The objections seem to have been based on the idea that an Internet
> > standard is somehow *mandatory* for the *whole network*.
> 
> Eastlake admits that this is an attempt to put ``pressure on product
> vendors.''

I believe that virtually all standards are issued with the hope that products
and services will conform to them and that their popularity will exert
pressure on suppliers to incorporate them.  This idea for standardization is
no different in that regard than any other. 

> It's pressure to adopt inferior technology. There are no legitimate
> interoperability concerns; this is a blatant attempt by one vendor to
> protect its dwindling market share by deceiving purchasers.

It would hardly seem surprising that that the first draft of a standard would
be colored by the author's experience.  However, I detect a willingness to
learn and change the draft in the author.  In you I see little but
intrasigence and name calling. 

> ---Dan
> Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Donald
=====================================================================
Donald E. Eastlake 3rd     +1 508-287-4877(tel)     [email-masked]
   318 Acton Street        +1 508-371-7148(fax)     [email-masked]
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.eff.org/blueribbon.html

To: [email-masked]
Subject: Re: MLM subaddress requirement 
From: [email-masked]
Date: Tue, 05 Aug 1997 16:03:10 -0400
Sender: [email-masked]

--==_Exmh_739160646P
Content-Type: text/plain; charset=us-ascii

On Tue, 05 Aug 1997 10:20:58 PDT, Chris Newman said:
> What is the purpose of restricting postings based on the envelope address?
> It's obviously *not* a security issue as anyone can generate email from
> any address trivially (own a copy of Netscape?).  I claim the primary
> purpose is to reduce spam.  Permitting postings from user if user+foo is
> subscribed has no impact on this primary purpose.

ARGH!!!

How many times do I have to say this?

*YOU* *DO* *NOT* *KNOW* if 'user' and 'user+foo' are in fact the same
address or not.  You cannot tell if the remote system sending the mail is
or is not using your extension.

This applies to *ALL* interactions with an MLM, not just posting.  Subscribing,
unsubscribing, requesting archive - which may be private and/or sensitive.

I'll let *YOU* deal with the irate phone calls because one user got a
corporate-sensitive archive he should not have been able to, just because
his site did *NOT* use your subaddressing scheme and your MLM assumed it did.

Until you explain how a MLM can *tell* that a given address is or
is not using subadressing, you MAY NOT (rfc2119 sense) give a MLM any
right to guess/assume/pull-out-of-its-rectum any decision based on the
"fact" that an address that contains a '+' is in fact using subaddressing.

Have I made this clear? YOU CANNOT REQUIRE OR EVEN SUGGEST THAT AN MLM
DO ANYTHING WITH SUBADDRESSING UNLESS IT IS EITHER A 'MUST' STANDARD OR
YOU HAVE A WAY OF TELLING ON THE FLY IF THE REMOTE SITE SUPPORTS IT.
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_739160646P
Content-Type: application/pgp-signature

--==_Exmh_739160646P--

Date: 5 Aug 1997 19:32:40 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: 50 people vs. newman
Sender: [email-masked]

> I can't tell what you are complaining about.

Newman's attempt to ``standardize'' Innosoft's inferior system.

> The objections seem to have been based on the idea that an Internet
> standard is somehow *mandatory* for the *whole network*.

Eastlake admits that this is an attempt to put ``pressure on product
vendors.''

It's pressure to adopt inferior technology. There are no legitimate
interoperability concerns; this is a blatant attempt by one vendor to
protect its dwindling market share by deceiving purchasers.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: Tue, 05 Aug 1997 10:20:58 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: MLM subaddress requirement
To: [email-masked]
Cc: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Tue, 5 Aug 1997 [email-masked] wrote:
> > (3) Ignoring subaddresses for the purpose of permitting postings.
> 
> This doesn't work.  Remember - the MLM *CAN NOT TELL* whether a piece
> of mail from [email-masked]' is from a subaddress-aware site or if
> it's just from a site that has some OTHER meaning for '+'.  As such,
> if you "ignore", and the list is closed, you just allowed [email-masked]'
> to improperly post/subscribe/etc to the list.

What is the purpose of restricting postings based on the envelope address?
It's obviously *not* a security issue as anyone can generate email from
any address trivially (own a copy of Netscape?).  I claim the primary
purpose is to reduce spam.  Permitting postings from user if user+foo is
subscribed has no impact on this primary purpose.

In the case of a signature verifying list, there has to be some way to
register a PGP key to use with the list.  The way to meet the
interoperability requirement is simply to allow the address in the
registered PGP key (used for posting & control) to be different from the
subscription address.  This is not particularly cumbersome or painful
given the key has to be registered anyway.

> Yes.  If the remote system is unable to tell if an optional feature is in
> use, it *MUST* assume that the feature is *NOT* present.  Blindly saying
> "This is SO $%(*^$% neat that I'll assume the world does it TOO" is just
> a good way to screw the users to the wall.

What negative impact does the loosened form of the requirement have?

I've actually been thinking about a feature negotiation for email
mechanism (e.g. a simple way to say "don't send me s/mime gunk or 
text/html but I like UTF-8"), but such a mechanism needs to be used
sparingly and I just don't think subaddresses merit this level of
complexity.

The fact is, subaddresses _mostly_ work today.  I had to switch a compile
time option to allow editing of the from address in my MUA.  Every final
delivery agent I've used supports them.  And only one mailing list I'm on
currently (IETF-TLS) doesn't meet this revised MLM requirement from what I
can tell.

		- Chris

To: [email-masked]
Subject: Re: MLM subaddress requirement 
From: [email-masked]
Date: Tue, 05 Aug 1997 12:42:37 -0400
Sender: [email-masked]

--==_Exmh_1444093296P
Content-Type: text/plain; charset=us-ascii

On Tue, 05 Aug 1997 09:30:22 PDT, Chris Newman said:
> A subaddress aware MLM MUST provide a way for a user to use his
> primary address with a subaddress for subscription and use just his
> primary address for posting.  Some ways to meet this requirement include:
> 
> (1) Having no restrictions on who can post to the list.

Not Acceptable.

> (2) Permitting subscribers to register different posting and submission
> addresses.

Pain in the ass.

> (3) Ignoring subaddresses for the purpose of permitting postings.

This doesn't work.  Remember - the MLM *CAN NOT TELL* whether a piece
of mail from [email-masked]' is from a subaddress-aware site or if
it's just from a site that has some OTHER meaning for '+'.  As such,
if you "ignore", and the list is closed, you just allowed [email-masked]'
to improperly post/subscribe/etc to the list.

> This now directly dictates the interoperability issue rather than a
> particular solution to it (which is what I should have done in the first
> draft).  There are plenty of ways to address this requirement without any
> significant impact on MLM systems or security validation.

No there aren't.  See above.

> > Bottom line - I think this proposal is a non-starter unless it provides
> > a way for a *remote* system (such as a MLM or what-have-you) to
> > determine if the option is available or not.
> 
> Do you still feel this is necessary if I make the above change?

Yes.  If the remote system is unable to tell if an optional feature is in
use, it *MUST* assume that the feature is *NOT* present.  Blindly saying
"This is SO $%(*^$% neat that I'll assume the world does it TOO" is just
a good way to screw the users to the wall.

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_1444093296P
Content-Type: application/pgp-signature

--==_Exmh_1444093296P--

Date: Tue, 05 Aug 1997 09:30:22 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: MLM subaddress requirement
To: [email-masked]
Cc: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

---559023410-1804928587-870798622=:18309
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-ID: <[email-masked]>

On Tue, 5 Aug 1997 [email-masked] wrote:
> 'fred', 'fred+warbot', 'fred+ghost' etc to be the "same" or not.  As has
> been pointed out, this has a *large* impact on MLM systems, and on anything
> that wants to do cryptographic signatures.
>
> This message is PGP-signed.  Would I have to add a new userid to my public
> key and re-send it to the keyservers each time I started using a new '+whatever'
> address?  Remember - the answer to this is *NOT* PGP-specific... ;)

Suppose I re-word the MLM rule as follows:

---
A subaddress aware MLM MUST provide a way for a user to use his
primary address with a subaddress for subscription and use just his
primary address for posting.  Some ways to meet this requirement include:

(1) Having no restrictions on who can post to the list.

(2) Permitting subscribers to register different posting and submission
addresses.

(3) Ignoring subaddresses for the purpose of permitting postings.
---

This now directly dictates the interoperability issue rather than a
particular solution to it (which is what I should have done in the first
draft).  There are plenty of ways to address this requirement without any
significant impact on MLM systems or security validation.

> Bottom line - I think this proposal is a non-starter unless it provides
> a way for a *remote* system (such as a MLM or what-have-you) to
> determine if the option is available or not.

Do you still feel this is necessary if I make the above change?

		- Chris

---559023410-1804928587-870798622=:18309--

From: "Bart Schaefer" <[email-masked]>
Date: Tue, 5 Aug 1997 09:18:31 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "50 people vs. newman" (Aug  5,  7:48am)
To: [email-masked]
Subject: Re: 50 people vs. newman
Sender: [email-masked]

On Aug 5,  7:48am, D. J. Bernstein wrote:
} Subject: 50 people vs. newman
}
} Yesterday I described the main features of Newman's proposal on the
} qmail mailing list, along with a pointer to the text.

I've read your descriptions of other people's proposals before.  Care
to forward this instance to us?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

To: [email-masked]
Subject: Re: 50 people vs. newman 
From: [email-masked]
Date: Tue, 05 Aug 1997 10:40:39 -0400
Sender: [email-masked]

--==_Exmh_1092358604P
Content-Type: text/plain; charset=us-ascii

On Tue, 05 Aug 1997 15:19:36 +0200, [email-masked] said:
> The Newman proposal describes a *per site* mechanism, with no effect
> (that I can see) on systems apart from the ones that *choose* to
> adopt this mechanism.
> With some care, it can be used *per user*, with no effect on the
> other users of the same mailhost.

Alas Harald, it's not *quite* that simple.  Now, I could support this draft
as going out as an "Informational" describing "here's the way some sites
do it".  Unfortunately, as written, I think this would be a Bad Idea for
even "Elective" status, much less 'MUST" status.

 The problem is that everything is too damned intertwined.

For instance, let's say we have a mailing list A, and subscribers X, Y,
and Z at seperate sites.  Now, if the administrators at sites X and Y
upgrade to this new scheme, *it doesn't really do any good* if site A
is unaware.  Site A treats the 'local part' as an opaque cookie to be
dealt with by sites X and Y.  As such, it's *not* permitted to look "inside"
the opaque-cookie local-part and say "Oh, this is from zlortch@X, he's
allowed to modify zlortch+biglist@X entries".  Of course, being able to 
do this sort of parsing *was* the whole *point* of the proposal...

So site A upgrades.  And thus breaks size Z, which happens to use '+'
(or whatever meta-char we picked) as a seperator for something ELSE.
Remember, since it's elective, site Z can opt out.  However, site A now
has a dilemma - it has no way of knowing which sites are using the
subaddressing scheme and which aren't.

Anybody who says "Site A can just keep a list of which sites X Y Z are
using which style" can go back and read up on why the DNS was invented.
And don't propose an "Extended MX" - it's been proven that people can't
get *REGULAR* MX configured right (how long has "compuserve.com" been
pointing their MX at a CNAME? ;)

Bottom line - I think this proposal is a non-starter unless it provides
a way for a *remote* system (such as a MLM or what-have-you) to determine
if the option is available or not.  Yes, I know RFC1123 says 'you MUST
support postmaster'.  However, notice that the status of 1123 means that
a remote system is allowed to use simple lexical operations to determine
address validity for those reserved addresses.  If they accept a connection
on port 25, it has to be safe to mail to 'postmaster@'.  However, there is
no similar way for a remote host to verify whether it should consider
'fred', 'fred+warbot', 'fred+ghost' etc to be the "same" or not.  As has
been pointed out, this has a *large* impact on MLM systems, and on anything
that wants to do cryptographic signatures.

This message is PGP-signed.  Would I have to add a new userid to my public
key and re-send it to the keyservers each time I started using a new '+whatever'
address?  Remember - the answer to this is *NOT* PGP-specific... ;)
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_1092358604P
Content-Type: application/pgp-signature

--==_Exmh_1092358604P--

From: [email-masked]
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked]
Subject: Re: 50 people vs. newman
Date: Tue, 05 Aug 1997 15:19:36 +0200
Sender: [email-masked]

I can't tell what you are complaining about.

The Newman proposal describes a *per site* mechanism, with no effect
(that I can see) on systems apart from the ones that *choose* to
adopt this mechanism.
With some care, it can be used *per user*, with no effect on the
other users of the same mailhost.

The objections seem to have been based on the idea that an Internet
standard is somehow *mandatory* for the *whole network*.

The difference between a Standard and an Informational is whether it
is something we recommend when people do this kind of thing or whether
it's simply documenting an existing practice.
For Elective standards, there is *NO* requirement that people do it.
A MUST in a standard just says "if you claim to follow this standard,
you MUST do this".
Nothing else.

                               Harald Tveit Alvestrand

Date: 5 Aug 1997 07:48:32 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: 50 people vs. newman
Sender: [email-masked]

Yesterday I described the main features of Newman's proposal on the
qmail mailing list, along with a pointer to the text.

So far, 50 users and system administrators have sent me e-mail stating
``Newman's address system should not be standardized.''

Many of them added unsolicited comments on various details of Newman's
proposal, including

   * testimonials to the active use of account names containing "+",
     which would no longer receive mail if the MTA were ``upgraded'' to
     follow Newman's requirements;

   * testimonials to the active use of "-" (and "=") on their machines
     by tens of thousands of people and dozens of mailing lists, all of
     which would be stranded by an MTA following Newman's requirements;

   * testimonials to the active use of PGP with MLMs for security---
     security that would be destroyed if the MLMs were ``upgraded'' to
     follow Newman's requirements;

   * criticism of Newman's enable-subaddresses-by-default requirement
     as ignoring the desires of the average user;

   * criticism of Newman's ``security considerations'' as violations
     of local security policy; and

   * evaluations of the difficulty of switching existing subaddresses
     to "+" in software, existing mailing lists, and address books
     around the world.

Other evaluations of Newman's proposal included ``pointless,''
``silly,'' ``insane,'' ``unneeded,'' ``intrusive,'' ``terrible,''
``go away,'' ``fundamentally flawed,'' ``we don't want it,'' and
``lock MTAs into often undesirable and even foolish behaviors.''

My impression is that many people, like me, would be interested in an
Informational RFC giving an honest description of the AMS subaddressing
system. A proposed ``standard,'' however, is completely unacceptable.

Here are the fifty people:

   Ira Abramov, Russ Allbery, Kimmo Arola, Jos Backus, Brian Behlendorf,
   Joe Block, David Bruce, Nathan Bryant, Len Budney, Evan Champion,
   Frank D. Cringle, Bernard Courtney, Dave Deakin, Gert Doering,
   Frank Ederveen, Janos Farkas, Felix Morley Finch, Bert Gijsbers,
   Paul Gregg, Andi Gutmans, Dirk Harms-Merbitz, Stephen Hawley,
   Douglas Henke, Marco d'Itri, Antti-Juhani Kaijanaho, Dax Kelson,
   Martijn Koster, Mark Lillywhite, Patrick J. LoPresti,
   Toshinori Maeno, Raul D. Miller, John D. Mitchell, Baldur Norddahl,
   John Palkovic, Andrea Paolini, Stephen Parker, Greg Patterson,
   William E. Powers, Chris Rovers, Aharon Schkolnik, Matthew Schnierle,
   Scott Schwartz, Dave Sill, Steve Simitzis, Rick Smith,
   Ethan Torretta, David Wuertele, Vince Vielhaber, Tommi Virtanen,
   Ximenes Zalteca.

I'm going to ask politely, for the last time, that Newman withdraw his
proposal.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: 4 Aug 1997 23:57:16 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Innosoft interoperability
Sender: [email-masked]

> This is entirely inappropriate for this group,

Then Bart shouldn't have brought it up.

He's the one pretending that your naive subaddressing ``standard'' will
settle the last internal interface design issue in Internet mailers and
usher in a new age of MUA-MSA-MTA-MDA interchangeability. (And, oh yes,
we'll all be using Windows 95.)

In the real world, Innosoft's version of pine doesn't even work with two
versions of Innosoft's MTA, because---by Ned Freed's own words---the
Innosoft people ``routinely change all sorts of interfaces and data
structures during the development of new releases of the product.''

> Dan has taken a quote out of context and posted misleading information.

What did I say that was misleading? I clearly identified my correct
presumption that the MUA was a modified version of pine: ``presumably
this is the famous Innosoft pine-with-subaddresses.'' (You subsequently
admitted that you were wrong about the ``subaddresses'' part.)

> Pine *is not* Innosoft's MUA.

Pay attention. All of us---the user, Ned Freed, me---are referring to
the ``pine'' program supplied and maintained by Innosoft.

The user asked whether Innosoft's latest pine program worked with
Innosoft's PMDF 5.0-6 program. The answer is no.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: Mon, 04 Aug 1997 15:37:45 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Innosoft interoperability
To: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

This is entirely inappropriate for this group, but I feel forced to
respond in defense.  Dan has taken a quote out of context and posted
misleading information.  I encourage readers to make their own evaluation
of Dan's motivations and veracity in this matter.

On Mon, 4 Aug 1997, D. J. Bernstein wrote:
> Speaking of Innosoft...
> 
> A user just asked whether the latest version of pine---presumably this
> is the famous Innosoft pine-with-subaddresses---works with PMDF 5.0-6.
> 
> Here's Ned Freed's answer: ``The answer is no, it won't work. There are
> countless version dependencies thoughout -- we routinely change all
> sorts of interfaces and data structures during the development of new
> releases of the product.''
> 
> So Innosoft's MUA doesn't even work with two versions of their own MTA.

Pine *is not* Innosoft's MUA.  Pine is a product of the University of
Washington.

When appropriate Internet standards are used, any version of Pine on a
client will interoperate with any version of PMDF on a separate server.

Innosoft maintains a VMS port of Pine for our customers.  This port uses
the same shared libraries that the MTA uses and thus the versions have to
be kept in sync when on the same host.  This is the context for Ned's
quote.

		- Chris

Date: 4 Aug 1997 20:52:27 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: objections, again
Sender: [email-masked]

Finally Chris admits some of his mistakes.

Chris, I invite you to write an INFORMATIONAL document explaining how
e-mail addresses are controlled in AMS.

> If they choose to use this variety of subaddressing, then they'd have to
> change those addresses or configure in a special MTA alias.

In contrast, qmail _automatically_ handles existing accounts that
contain the separator character.

Why are you trying to standardize an inferior mechanism?

> RFC 2142 clearly requires that it be "widget-request".

Correct. Now, with your ``+'' as a separator, the widget account doesn't
control this ``widget-request'' address, unless the sysadmin sets up one
of your ``special MTA aliases.''

In contrast, with ``-'' as a separator, the widget account automatically
controls ``widget-request'', so the user's favorite MLM can use
``widget-request'' without special sysadmin support.

Why are you trying to standardize an inferior mechanism?

> This is an interesting scenario.

Do you deny that an MLM ``upgraded'' to support your requirements will
cause this security mechanism to fail?

> The address encoding used in SMTP is "a,b+c"@d.e for that address.

What are you saying? All MUAs have to use SMTP? I'm talking about local
UNIX MUAs that pass addresses to the submission agent on the command
line---there are more than thirty programs in this category. If they
follow your interface requirements, they produce incorrect results with
MMDF and qmail for all quoted addresses.

> Linking the proposal to a single product when it is already in multiple
> products is deceptive.

Not at all. Obviously one vendor can imitate another vendor's features.

What's deceptive is your list of supporting products:

   * CMU (AMS, Cyrus) and Innosoft (PMDF) have paid you.

   * sendmail's support is pathetic---it doesn't allow user-controlled
     configuration by default.

   * Pine's support doesn't exist; it was your unverified speculation.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: Mon, 04 Aug 1997 10:46:38 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: objections, again
To: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Sun, 3 Aug 1997, D. J. Bernstein wrote:
> > it can still be configured to handle them.
> 
> Do these people have to change their e-mail addresses when they install
> your ``compliant'' software?

If they choose to use this variety of subaddressing, then they'd have to
change those addresses or configure in a special MTA alias.

> I'm still waiting for an answer to my question on this topic: Is it
> widget-request or widget+request?

If it is an administrative mailbox name for a mailing list "widget", then
then RFC 2142 clearly requires that it be "widget-request".

> How can ``MUST do X by default'' be required for interoperation? X isn't
> even required! It's indistinguishable from ``MUST NOT do X by default''
> from an interoperability perspective. Other software can't rely on X and
> can't rely on not-X.

You're correct that X isn't required.  But if X is part of service Y and
saying "MUST do X by default" makes service Y work consistantly between
implementations, then it is entirely reasonable.

> When your MUA replies to
> 
>    From: "a,b+c"@d.e
> 
> it will incorrectly pass "a,b+c"@d.e to the MTA.

There is nothing incorrect about that.  The address encoding used in SMTP
is "a,b+c"@d.e for that address.  Yes, the alternate encoding a\,[email-masked]
is also permitted but that's generally believed to be a mistake in the
formal grammar and probably won't be permitted on generation in 821bis.
The format a,[email-masked] is NOT legal in SMTP.

> The address is actually a,[email-masked]. It can be _encoded_ as "a,b+c"@d.e
> under RFC 821 and RFC 822, but the quotes are not part of the address.

Agreed.  So does all this have a point?

> It's much better in practice for the MUA to avoid address parsing. The
> MTA's submission agent can take care of it.

The vast majority of MUAs submit via SMTP.  Thus they have to parse
addresses and generate valid SMTP encodings of the address. 

> > >    * Chris's validation restriction is bizarre.
> > This is not a technical complaint and thus has no merit.
> 
> Amusing---your previous response to this criticism was ``good point.''

My previous response was to a statement to the effect that MUAs may wish
to validate certain subaddresses.  "bizarre" is not a technical point and
does not belong in a technical discussion.

> Let me rephrase. Your validation restriction has so many obviously wrong
> effects that it can't possibly be what you meant. It is, like your many
> unclear requirements, a result of bad writing; the fact that it's clear
> is merely an accident.

I asked to have the spec reviewed because I don't write perfect specs the
first try.

> I've seen a list that, before calling the MLM software, invokes PGP to
> verify that the message is PGP-signed by the sender. The MLM then checks
> the sender address against the subscription list. Subscribers have to be
> preapproved (though there are some open sublists for lurkers).
> 
> Your requirement destroys this security mechanism. An attacker takes an
> approved [email-masked]'' address and registers a [email-masked]''
> PGP key; PGP is satisfied; but an MLM following your rules has to ignore
> the +haha when it's checking the address.

This is an interesting scenario.  The obvious thing to do is allow
different posting/control and subscription addresses and associate the key
with the posting/control address.  The other option would be to disallow
registration of PGP keys with subaddresses at the MLM.

> Your denial of this security issue is despicable.

Why does this make me think of Daffy Duck?

> Inadequate. Your use of the term ``subaddressing'' is still deceptive.
> Choose a phrase that accurately identifies your subaddressing system,
> such as ``The AMS Subaddressing System.''

Linking the proposal to a single product when it is already in multiple
products is deceptive.

> > And I was surprised to find that Pine
> > supported the user-validation subaddressing feature.
> 
> Which version? Where is this documented? Are you sure you haven't been
> surprised by a local hack?

I double-checked and found I was incorrect on this point.  Pine in
IMAP/SMTP mode does no recipient address validation beyond address book
lookup.  It was simply relaying RCPT TO errors from the SMTP submit
server.

Pine has a compile-time option to allow the from address to be edited,
although I had to create a personal version to use subaddresses in MAIL
FROM.

		- Chris

Date: Mon, 04 Aug 1997 09:35:25 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: objections, again
To: Todd Vierling <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Mon, 4 Aug 1997, Todd Vierling wrote:
> I run a mail server that accepts mail for duh.org.  YOU HAVE NO AUTHORITY to
> control how mail is handled once it enters my system, or the validity or
> equality of addresses before the @.  THAT IS MY MTA'S CHOICE, not yours. B
> Not even a 'VRFY' or 'EXPN' SMTP command gives any kind of assurance on
> deliverability or identity of addressing.  Only an actual attempt at mail
> delivery does. 

You are right that I have no authority to control how mail is routed at
your site.  Nor does the IETF.  You can run any MTA you want which does
whatever you want.

The point of the spec I wrote is to standardize one subaddressing format
which had been implemented by multiple vendors.  If you want subaddressing
to interoperate between your final delivery agent and MUA, then you can
use this spec.  Otherwise you can ignore it -- the intention is certainly
not to require all Internet mail systems to do this.

> I don't use qmail.  I'm using your run-of-the-mill Sendmail 8.8.7.  I do use
> subaddressing on a minor basis.  My mail transfer agent has sole authority
> about addressing mail in the @duh.org domain.  I do interoperate quite well
> with every single SMTP compliant MTA out there, thankyouverymuch.  SMTP says
> nothing about subaddressing, and the interoperability requirement above is
> already satisfied. 

But with a POP/IMAP client and a remote final delivery agent, there is no
subaddressing interoperability.  That's the point of this spec -- if you
want subaddressing to interoperate between POP/IMAP and the final delivery
agent, use this spec.  Otherwise don't.

> You just don't have a ground to walk on by forcing us to standardize
> addresses before the @ sign.  As long as we don't use a well-known
> metacharacter defined by RFC, we can put just about anything before the @
> sign and expect it to remain untouched and unique.  Defining a new
> metacharacter is not only sloppy at this point, but it should also only
> affect routing of mail *outside* the destination host/domain (see the use of
> % and !).

I strongly disagree.  The left hand side is reserved only for routing
*inside* the local domain.

> In short, subaddresses DO NOT EXIST unless my MTA says they do (and only
> within the local delivery ability of my MTA).  Outside my domain, you have
> no authority to tell me how to deliver mail addressed to the @duh.org
> domain.  Anything to the contrary simply makes no sense.

Agreed.  Did someone mislead you into thinking I was doing otherwise?

> RFC 2015 provides real security via PGP et. al., sure.  So how does
> validation of a sender's identity, based on e-mail addressing, have any
> _usability_ whatsoever?  Therefore the _restriction_ of delivery/identity to
> a "primary user" has no merit. 

In practice it does reduce the amount of spam even if it provides no
security.  The requirement in the draft prevents this spam control measure 
from interfering with legitimate subaddress users.

> Oh, one off-hand note:  I cannot recall which, but there is a MTA out there
> that separates first and last names of a person with a +.  This package is
> not widely used, but it _is_ used by a couple Fortune 500s, and you'd
> probably infuriate many more unknowing users of that package and others by
> imposing some sort of authentication and identity mechanism on them that
> ruffles existing e-mail addresses.

Interesting case.  But I'm not imposing anything on them, nor could I if I
tried.

		- Chris

Date: 4 Aug 1997 11:11:48 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Innosoft interoperability
Sender: [email-masked]

> What if I want to write an agent that
> I can expect to interoperate with any of a large number of other MTAs and
> LDAs or submission agents?  Are you going to convince Netscape and MS and
> Software.com and Innosoft

Speaking of Innosoft...

A user just asked whether the latest version of pine---presumably this
is the famous Innosoft pine-with-subaddresses---works with PMDF 5.0-6.

Here's Ned Freed's answer: ``The answer is no, it won't work. There are
countless version dependencies thoughout -- we routinely change all
sorts of interfaces and data structures during the development of new
releases of the product.''

So Innosoft's MUA doesn't even work with two versions of their own MTA.

Now, Bart, what were you saying about interoperability?

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: Sun, 03 Aug 1997 21:36:08 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: objections, again
To: Todd Vierling <[email-masked]>
Cc: Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

> Under RFC 2119, section 6,

>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.

> I run a mail server that accepts mail for duh.org.  YOU HAVE NO AUTHORITY to
> control how mail is handled once it enters my system, or the validity or
> equality of addresses before the @.  THAT IS MY MTA'S CHOICE, not yours. B
> Not even a 'VRFY' or 'EXPN' SMTP command gives any kind of assurance on
> deliverability or identity of addressing.  Only an actual attempt at mail
> delivery does.

On the contrary, the IETF has had standards in place for a long time that
impose mandatory requirements on the namespace to the left of the @. In fact
not only is this done, one case where it is done is at full standard status.

I'm referring, of course, to the mandate in RFC1123 that any host that supports
a receiver-SMTP also support a mailbox called "postmaster". And there's also a
requirement that "postmaster" be supported in a case-insensitive fashion (a
pain to implement, BTW, and the source of at least one round of standards
incompliancy in sendmail).

And this isn't the only example of such a specification. There's also RFC2142,
now a proposed standard, which mandates a wide variety of mailbox names for
hosts offering various classes of service.

Now, you use the term "authority" above. And in this sense you're absolutely
right, the IETF doesn't have any authority to force you to comply with IETF
standards. You are completely free to comply with none, some, or all IETF
standards. You don't have to have a "postmaster" mailbox on your system (and in
fact an unfortunately large number of systems don't), in which case you aren't
in compliance with RFC1123. Or you can implement subaddressing in an entirely
different way than what a standards-track specifaction says, in which case you
woult not be in compliance with it.

But all this means is that you are not in compliance. Nobody is going to arrest
you for either action. You may get in trouble with someone somewhere because
they expected you to conform to some set of IETF standards but you did not, of
course. However, such contractural arrangements are outside the scope of the
IETF.

But this doesn't mean we cannot write standards that impose certain syntactic
and semantic requirements on what appears to the left of the @ in an email
address. We can. We have done so in the past and I'm sure we'll do so again in
the future.

In fact not only have we imposed such requirements in the past, we've done
something worse -- we have in fact let prose slip into standards-track
specifications that says certain mailbox name forms be interpreted in
particular ways even when they appear in conjunction with a domain that isn't
your own! This last is hard to believe I know, but you'll find that RFC1327 can
be read this way. Note that RFC1327 will soon be replaced with MIXER, where I
believe the problem to be corrected.)

Please note that I'm not commenting on the subaddress proposal either pro
or con. I'm only addressing the procedural issue of whether or not such
a proposal is in scope for the IETF to produce.

				Ned

Date: Mon, 4 Aug 1997 00:02:42 -0400 (EDT)
From: Todd Vierling <[email-masked]>
To: Chris Newman <[email-masked]>
cc: [email-masked]
Subject: Re: objections, again
Sender: [email-masked]

On Sun, 3 Aug 1997, Chris Newman wrote:

: >    * Chris's delivered-to-owner default violates RFC 2119, section 6.
: 
: The keywords are used to get interoperation between MUAs, final delivery
: agents and mailing list servers with respect to subaddresses as
: transmitted on the wire. Thus the proposal is entirely within IETF domain
: and your complaint has no merit.

Then let me clarify his point a little.

Under RFC 2119, section 6,

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

I run a mail server that accepts mail for duh.org.  YOU HAVE NO AUTHORITY to
control how mail is handled once it enters my system, or the validity or
equality of addresses before the @.  THAT IS MY MTA'S CHOICE, not yours. B
Not even a 'VRFY' or 'EXPN' SMTP command gives any kind of assurance on
deliverability or identity of addressing.  Only an actual attempt at mail
delivery does. 

I don't use qmail.  I'm using your run-of-the-mill Sendmail 8.8.7.  I do use
subaddressing on a minor basis.  My mail transfer agent has sole authority
about addressing mail in the @duh.org domain.  I do interoperate quite well
with every single SMTP compliant MTA out there, thankyouverymuch.  SMTP says
nothing about subaddressing, and the interoperability requirement above is
already satisfied. 

You just don't have a ground to walk on by forcing us to standardize
addresses before the @ sign.  As long as we don't use a well-known
metacharacter defined by RFC, we can put just about anything before the @
sign and expect it to remain untouched and unique.  Defining a new
metacharacter is not only sloppy at this point, but it should also only
affect routing of mail *outside* the destination host/domain (see the use of
% and !).

In short, subaddresses DO NOT EXIST unless my MTA says they do (and only
within the local delivery ability of my MTA).  Outside my domain, you have
no authority to tell me how to deliver mail addressed to the @duh.org
domain.  Anything to the contrary simply makes no sense.

: >    * Chris's MLM requirement creates a new security problem when a+b is
: >      subscribed to a mailing list and a+c is a different user.
: 
: No.  In that rare case, a subaddress-aware MLM would allow email with
: addresses from "a" to manage "a+b" and "a+c"'s subscription.  But this is
: not a real security issue as anyone can generate email from "a", "a+b" or 
: "a+c" regardless.  RFC 2015 provides real security.  Therefore this cliam
: has no merit. 

RFC 2015 provides real security via PGP et. al., sure.  So how does
validation of a sender's identity, based on e-mail addressing, have any
_usability_ whatsoever?  Therefore the _restriction_ of delivery/identity to
a "primary user" has no merit. 

: Perhaps if you forwarded a user's statement to that effect we'd be more
: inclined to listen and address the specifics of that complaint.

I'm not a casual user (I have contributed source code and patchwork to
several *BSD variants and Sendmail itself) but I don't write the core
"stuff"; I primarily just use it all.  So this was my statement.

Oh, one off-hand note:  I cannot recall which, but there is a MTA out there
that separates first and last names of a person with a +.  This package is
not widely used, but it _is_ used by a couple Fortune 500s, and you'd
probably infuriate many more unknowing users of that package and others by
imposing some sort of authentication and identity mechanism on them that
ruffles existing e-mail addresses.

=====
== Todd Vierling (Personal [email-masked]; Alternate [email-masked])
== I'm glad you like the Internet, Bobby.  Now go eat your Frosted Flakes.

Date: 3 Aug 1997 22:57:24 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: objections, again
Sender: [email-masked]

> it can still be configured to handle them.

How?

Consider, for example, the following two accounts (names changed to
protect the innocent):

   [email-masked]
   [email-masked]

These are project accounts for completely different groups.

According to your proposal, mail for widget+x MUST be delivered to
widget by default, except that widget MAY be allowed to reconfigure the
delivery.

Now you seem to be claiming that software can be configured to do

   widget+(x+*) -> (widget+x)+*

Is that capability required by your document? Yes, qmail could pull
this sort of trick even if it didn't do the right thing by default, but
what about other MTAs?

More importantly, your rules violate foo.com's security policy.

It is unacceptable for the widget people to receive the widget+x mail.

It is unacceptable for the widget people to control the widget+x mail.

Do these people have to change their e-mail addresses when they install
your ``compliant'' software?

  [ -request vs. the artificially inconsistent ``+'' separator ]
> However, it is naming hierarchy rather than subaddressing and it uses a
> different separator.

I'm still waiting for an answer to my question on this topic: Is it
widget-request or widget+request?

> Therefore there is no inconsistancy. 

Answer the question.

> The keywords are used to get interoperation between

How can ``MUST do X by default'' be required for interoperation? X isn't
even required! It's indistinguishable from ``MUST NOT do X by default''
from an interoperability perspective. Other software can't rely on X and
can't rely on not-X.

> >    * Chris's syntax requirements prohibit MUAs from sending mail to
> >      some valid addresses.
> Only when using subaddresses.

The point remains: Your rules prohibit MUAs from sending mail to some
valid addresses.

> >    * Chris's syntax requirements produce misdirected mail for _all_
> >      quoted addresses when the MTA handles quoting correctly (as, e.g.,
> >      MMDF does).
> I see no reason why.  Please explain.

When your MUA replies to

   From: "a,b+c"@d.e

it will incorrectly pass "a,b+c"@d.e to the MTA.

The address is actually a,[email-masked]. It can be _encoded_ as "a,b+c"@d.e
under RFC 821 and RFC 822, but the quotes are not part of the address.

The incorrect address will work with sendmail, but that doesn't make it
right. sendmail violates the quoting rules in RFC 821 and RFC 822.

It's much better in practice for the MUA to avoid address parsing. The
MTA's submission agent can take care of it.

> >    * Chris's validation restriction is bizarre.
> This is not a technical complaint and thus has no merit.

Amusing---your previous response to this criticism was ``good point.''

Let me rephrase. Your validation restriction has so many obviously wrong
effects that it can't possibly be what you meant. It is, like your many
unclear requirements, a result of bad writing; the fact that it's clear
is merely an accident.

> But this is
> not a real security issue as anyone can generate email from "a", "a+b" or 
> "a+c" regardless.

Wrong.

I've seen a list that, before calling the MLM software, invokes PGP to
verify that the message is PGP-signed by the sender. The MLM then checks
the sender address against the subscription list. Subscribers have to be
preapproved (though there are some open sublists for lurkers).

Your requirement destroys this security mechanism. An attacker takes an
approved [email-masked]'' address and registers a [email-masked]''
PGP key; PGP is satisfied; but an MLM following your rules has to ignore
the +haha when it's checking the address.

Your denial of this security issue is despicable.

> >    * Chris's MLM requirement prohibits cryptographic applications of
> >      subaddresses.
> How does the MLM requirement conflict with RFC 2015?

I said ``cryptographic applications of subaddresses,'' not ``RFC 2015.''
I already gave cookies as an example. It's a _different_ mechanism, see?

  [ proposal is not the de facto standard ]
> Thus I have previously agreed to alter the wording.

Inadequate. Your use of the term ``subaddressing'' is still deceptive.
Choose a phrase that accurately identifies your subaddressing system,
such as ``The AMS Subaddressing System.''

> Out of curiosity, which MTAs other than qmail support your flavor of
> subaddressing?

Do you mean using dash as a separator, or the more advanced features?

Reportedly both sendmail and exim can be configured to handle dash.

MMDF, the only popular MTA that has had this feature for a long time,
appears to break addresses at "=", "/", or "|"; not configurable.

On the MUA side, apparently mutt, elm, trn, slrn, nn, gnus, knews, and
mh allow the user to configure arbitrary From addresses. (Of course,
qmail can set the From even if the MUA doesn't.)

> And I was surprised to find that Pine
> supported the user-validation subaddressing feature.

Which version? Where is this documented? Are you sure you haven't been
surprised by a local hack?

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: 3 Aug 1997 22:15:14 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: finally, an example
Sender: [email-masked]

> If the intended destination for replies is the first ISP, I have to type
> "+party-4-july".  If the second, I have to type "-party_4_july" or some
> other permutation.

Oh, c'mon, surely you can imagine a better user interface than that.

You configure your three ISPs into the MUA, following ISP instructions:

   SMTP: 1.2.3.4
   user: schaefer
   separator: +
   domain: isp1.net

   SMTP: 5.6.7.8
   user: schaefer
   separator: -
   domain: isp2.net

   SMTP: 9.10.11.12
   user: bs
   domain: isp3.net

Now the MUA gives you a ``subaddress'' box with either ISP 1 or ISP 2.
You can type ``party-4-july'' either way.

With ISP 3, since you didn't configure a separator, the MUA tells you
that subaddressing isn't supported.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

From: "Bart Schaefer" <[email-masked]>
Date: Sun, 3 Aug 1997 14:20:21 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "finally, an example" (Aug  3,  8:20pm)
To: [email-masked]
Subject: Re: finally, an example
Sender: [email-masked]

On Aug 3,  8:20pm, D. J. Bernstein wrote:
} Subject: finally, an example
}
} > Suppose I
} > send a message with "schaefer+party-4-july" in the From field local-part.
} > Now I can filter the responses on "party-4-july".  But in order to do
} > that, I had to know that "+" is a separator and "-" is not.
} 
} Apparently the sysadmin has told you that you can receive e-mail at
} schaefer+*. So you type ``schaefer+party-4-july'' into your MUA.
} 
} If he says schaefer-*, you type ``schaefer-party-4-july'' instead.

It's not "schaefer+*" and "schaefer-*".  I told you the specifics are
not relevant.  If you really think its worthwile to pursue this, take
it as "schaefer+[^+]*" on one ISP, and "schaefer-[^-+]*" on another.

} Or, given appropriate MUA support, you type the ``schaefer+'' or
} ``schaefer-'' exactly once; then you type exactly the same
} ``party-4-july'' either way.

If the intended destination for replies is the first ISP, I have to type
"+party-4-july".  If the second, I have to type "-party_4_july" or some
other permutation.

The reason for wanting different reply destinations is irrelevant.

} I don't see the inconvenience here. This all looks very straightforward.
} How else would you expect this example to work?

It'd be much easier if both ISPs accepted one format or the other (I don't
care which) and if any more ISPs that I might encounter would also use the
same format.  Why is that so difficult to comprehend?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Date: 3 Aug 1997 20:20:12 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: finally, an example
Sender: [email-masked]

> Suppose I
> send a message with "schaefer+party-4-july" in the From field local-part.
> Now I can filter the responses on "party-4-july".  But in order to do
> that, I had to know that "+" is a separator and "-" is not.

Apparently the sysadmin has told you that you can receive e-mail at
schaefer+*. So you type ``schaefer+party-4-july'' into your MUA.

If he says schaefer-*, you type ``schaefer-party-4-july'' instead.

Or, given appropriate MUA support, you type the ``schaefer+'' or
``schaefer-'' exactly once; then you type exactly the same
``party-4-july'' either way.

I don't see the inconvenience here. This all looks very straightforward.
How else would you expect this example to work?

> A specific example is not relevant.

Specific examples are everything. Thank you for providing one.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: Sun, 03 Aug 1997 12:09:01 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: objections, again
To: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Sun, 3 Aug 1997, D. J. Bernstein wrote:
>    * Software following Chris's proposal can't handle mail for
>      existing names that contain plus signs. (In contrast, qmail
>      automatically handles usernames that contain the separator.)

There are few such names and it can still be configured to handle them.
Therefore this is a non-issue.

>    * Chris's delivered-to-owner default violates RFC 2119, section 6.

The keywords are used to get interoperation between MUAs, final delivery
agents and mailing list servers with respect to subaddresses as
transmitted on the wire. Thus the proposal is entirely within IETF domain
and your complaint has no merit.

>    * Chris's syntax requirements prohibit MUAs from sending mail to
>      some valid addresses.

Only when using subaddresses.  This is a minor point which I could be
convinced to change and has no bearing on the primary proposal. 

>    * Chris's syntax requirements produce misdirected mail for _all_
>      quoted addresses when the MTA handles quoting correctly (as, e.g.,
>      MMDF does).

I see no reason why.  Please explain.

>    * Chris's validation restriction is bizarre.

This is not a technical complaint and thus has no merit.

>    * Chris's MLM requirement creates a new security problem when a+b is
>      subscribed to a mailing list and a+c is a different user.

No.  In that rare case, a subaddress-aware MLM would allow email with
addresses from "a" to manage "a+b" and "a+c"'s subscription.  But this is
not a real security issue as anyone can generate email from "a", "a+b" or 
"a+c" regardless.  RFC 2015 provides real security.  Therefore this cliam
has no merit. 

>    * Chris's MLM requirement prohibits cryptographic applications of
>      subaddresses.

How does the MLM requirement conflict with RFC 2015?  Or is there another
standard you're using?  If you're just doing something by private
agreement you can use a separator other than "+".  Therefore this is a
non-issue.

>    * The point of Chris's proposal is to solve an MLM problem that is
>      already solved by a separation between posting addresses and
>      subscription addresses---a feature needed by many users anyway.

That is not the sole point of the proposal.  However, this claim has
merit otherwise.  Therefore I will include this as an alternate acceptable
solution in the next draft.

>    * Chris's other requirements are so unclear as to be useless.

This claim has merit.  I will work to clarify them.  It's quite common for
a first draft to have unclear sections.

>    * Chris's proposal is not the de facto standard for address
>      hierarchies.

This cliam has merit.  It may be implemented by more different vendors
than other formats, but that does not make it de facto.  Thus I have
previously agreed to alter the wording.  Please don't waste our time by
repeating an objection I have already agreed to address.

>    * Chris's proposal is inconsistent with the de facto ``-request''
>      standard when account names are used as mailing lists.

"-request" is a proposed IETF standard, not just a de facto standard. 
However, it is naming hierarchy rather than subaddressing and it uses a
different separator.  Therefore there is no inconsistancy. 

> Finally, and most importantly, MY USERS DO NOT WANT THESE RESTRICTIONS.
> Even the ones who prefer + as the usual separator sometimes want more
> flexibility than Chris's proposal allows.

Perhaps if you forwarded a user's statement to that effect we'd be more
inclined to listen and address the specifics of that complaint.

> In fact, users have recently pressured the authors of several other MTAs
> to imitate qmail's subaddressing. And, of course, some MTAs had the
> feature years before qmail, though most users were scared away by the
> poorly designed user interfaces.

Out of curiosity, which MTAs other than qmail support your flavor of
subaddressing?

Here's the deployed support for the "+" style which I'm simply
documenting:  Interestingly enough, PMDF had support for subaddresses
before I started working at Innosoft.  CMU's systems had support for
subaddresses before I got there.  And I was surprised to find that Pine
supported the user-validation subaddressing feature.  Sendmail supports it
(although that may be due to lobbying by CMU) as well. 

From: "Bart Schaefer" <[email-masked]>
Date: Sun, 3 Aug 1997 11:13:57 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "Re: Email Subaddressing" (Aug  3,  8:24am)
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

On Aug 3,  8:24am, D. J. Bernstein wrote:
} Subject: Re: Email Subaddressing
}
} This is getting tiresome. Do you know what ``specific example'' means?

A specific example is not relevant.  I'm not asking anyone to give me
"technical support" with my existing situation; I'd certainly not ask
that of someone with your attitude.

The question is not "what can I do with my current ISPs?"

The question is "how can I avoid having to do something different every
time I get a new ISP?" and secondarily "how could I write a program to
help other people do the same thing regardless of their ISP?"

} > So it can put the right ones in the Reply-To and/or From headers
} 
} Why do you want to do that?

Think of the subaddresses as sender-supplied keywords that respondents
automatically include in their replies.  When I send a message for reason
"X", I want the reply address to have a subaddress of "X".  Then I know
that when I get back a message with "X" in the address, the sender got
my address however indirectly from my original with "X" in it.

Ideally, I'd make up each new "X" on the fly, without having to tell the
LDA or MTA anything about it, yet the response would still end up in the
primary address mailbox.  I can do this with, for example, sendmail 8.x
with the procmail local delivery agent option included in the .cf.

Less ideal would be that I have to tell the LDA and/or MTA about "X", in
which case it would be nice if I could tell every LDA or MTA exactly the
same thing and have it understood in the same way.

Since I'd like to invent "X" on the fly, I'd like to limit the number of
variables imposed by the domain to the right of the "@".  A reasonable
limitation seems to me to be either "supports this and does so the same
way as every other domain that supports it" vs. "doesn't support it."

I can certainly treat all existing MTAs this way, by lumping everybody
who employs a different scheme into the "doesn't" camp, but I'd prefer
to increase the number of "supports it" domains.

If you really can't grasp that without a specific example:  Suppose I
send a message with "schaefer+party-4-july" in the From field local-part.
Now I can filter the responses on "party-4-july".  But in order to do
that, I had to know that "+" is a separator and "-" is not.

} > based on which ISP I'm sending through.
} 
} Why do you want to do that?

Actually, I don't want to do that, but I have no choice when the syntax
for using subaddresses differs from one ISP to the next.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Date: 3 Aug 1997 08:24:50 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

> Not using subaddressing to categorize my incoming mail.

What I'm asking is for you to explain the link between

   (1) address hierarchy variability, which you claim is inconvenient,
       and

   (2) your failure to use subaddresses, which surely is inconvenient.

You keep repeating the claim in #1, and the fact in #2. I don't see the
connection.

Many users who are faced with address hierarchy variability nevertheless
use subaddresses. What makes you different from them?

> So it can put the right ones in the Reply-To and/or From headers based
> on which ISP I'm sending through.

Why do you want to do that?

I know many multi-ISP users. They all stick to a single From address.
What makes you different?

And what does this have to do with subaddressing?

  [ MUA retrieving messages from several mailboxes by IMAP ]
> has to have the matching subaddresses to
> fill in submitted From and/or Reply-To in its own separate configuration.

Why?

This is getting tiresome. Do you know what ``specific example'' means?

> it's up to the POP client to
> spot the subaddress and categorize the messages after downloading them.

I've seen one (experimental) POP client that does this. It doesn't care
which addresses the user controls. It simply follows the patterns
configured by the user.

> In a better world, I'd have *one* subaddress configuration for both "A"
> and "B",

Details! Details! Details!

Show us which addresses A supports.

Show us which addresses B supports.

Show us which addresses you'd send where.

And explain why the variability between subaddress formats in A and B is
the crucial factor preventing you from setting this up.

> And my MUA's interface on
> configuring and selecting among subaddresses could be improved if there
> were only one format to support, as well.

Which MUA is that? Start giving names. Stop being the sort of useless
person that support technicians have nightmares about.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: 3 Aug 1997 07:44:50 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: objections, again
Sender: [email-masked]

> Are you putting up such exaggerated and overblown resistence to this idea 

Obviously it's time to refresh your memory:

   * Software following Chris's proposal can't handle mail for
     existing names that contain plus signs. (In contrast, qmail
     automatically handles usernames that contain the separator.)

   * Chris's delivered-to-owner default violates RFC 2119, section 6.

   * Chris's syntax requirements prohibit MUAs from sending mail to
     some valid addresses.

   * Chris's syntax requirements produce misdirected mail for _all_
     quoted addresses when the MTA handles quoting correctly (as, e.g.,
     MMDF does).

   * Chris's validation restriction is bizarre.

   * Chris's MLM requirement creates a new security problem when a+b is
     subscribed to a mailing list and a+c is a different user.

   * Chris's MLM requirement prohibits cryptographic applications of
     subaddresses.

   * The point of Chris's proposal is to solve an MLM problem that is
     already solved by a separation between posting addresses and
     subscription addresses---a feature needed by many users anyway.

   * Chris's other requirements are so unclear as to be useless. In
     several cases, I suspect the clear versions will be objectionable.

   * Chris's proposal is not the de facto standard for address
     hierarchies.

   * Chris's proposal is inconsistent with the de facto ``-request''
     standard when account names are used as mailing lists.

Finally, and most importantly, MY USERS DO NOT WANT THESE RESTRICTIONS.
Even the ones who prefer + as the usual separator sometimes want more
flexibility than Chris's proposal allows.

In short, Chris's proposal is a disaster.

Now, it's vaguely amusing to see you drawing stupid analogies, accusing
me of exaggeration, and blaming me for your failure to communicate; but
I'd prefer to see you discuss the specifics.

> because you want to minimize the probability of the inclusion of such a 
> feature in competing product?

In fact, users have recently pressured the authors of several other MTAs
to imitate qmail's subaddressing. And, of course, some MTAs had the
feature years before qmail, though most users were scared away by the
poorly designed user interfaces.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

From: "Bart Schaefer" <[email-masked]>
Date: Sat, 2 Aug 1997 23:13:50 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "Re: Email Subaddressing" (Aug  3, 12:56am)
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

On Aug 3, 12:56am, D. J. Bernstein wrote:
} Subject: Re: Email Subaddressing
}
} > As I said, it's inconvenience.
} 
} _What_ is inconvenient?

Not using subaddressing to categorize my incoming mail.

} > The interoperability problem is that the software on my Mac has to
} > support both schemes.
} 
} What for?

So it can put the right ones in the Reply-To and/or From headers based
on which ISP I'm sending through.

} I know people using subaddresses with a variety of MUAs. The MUAs all
} deal with incoming _mailboxes_, not incoming addresses. Why should an
} MUA care which addresses are owned by the user? 

To provide additional mail management features for the user.  It's not
necessary, but it's convenient.

} Yes or no: Are you having trouble sending messages?

No, but not really relevant.

} Yes or no: Are you having trouble receiving messages?

Also not relevant.  The question is not whether the message arrives, but
what happens to it after it does.

} Why should the MUA care about internal structure in the user's address?
} All it does is copy the address.

It is true that this is all that many MUAs do today.  That doesn't mean
it's the best behavior, especially for a user who has multiple addresses.

Example situations:

ISP "A" supports both subaddressing and IMAP.  I can FTP to the server
and set up a configuration file so that messages with different incoming
subaddresses end up in different mailboxes, which I can then access via
IMAP.  This is as close as things get to your model.  But my MUA can't
see the configuration file; it has to have the matching subaddresses to
fill in submitted From and/or Reply-To in its own separate configuration.

ISP "B" supports subaddressing but only POP.  All messages are delivered
to the POP mailbox of the primary address; it's up to the POP client to
spot the subaddress and categorize the messages after downloading them.
The ISP assigns only the primary address; the subaddresses are up to me
to make up.  They don't use the same format as ISP "A" subaddresses.
There's no LDA configuration file, because the subaddresses are ignored
for purposes of delivery; everything has to be configured at the MUA.
(An additional annoyance about "B" is that it doesn't give me a hook on
the envelope address, only what appears in the headers, but that doesn't
have anything to do with the address formats.)

ISP "C" supports only POP and not subaddressing, but it's where I have
my low-cost internet connection.

The goal I'm trying to attain is that messages that pass through all
three ISPs are categorized by incoming address into local mailboxes on
my home machine.  I can actually do this most easily with ISP "B"; one
remote mailbox is opened, and my MUA sorts out the messages as they are
downloaded.  (Unfortunately, it doesn't work as well as it could because
the envelope information is gone by that time.)  I can do it with ISP
"A" if I do more sophisticated remote access, opening one remote mailbox
for every corresponding local one.  I can't do it with ISP "C" at all.

In a better world, I'd have *one* subaddress configuration for both "A"
and "B", which is either part of my MUA or at least is tied to my home
machine.  I might choose to take advantage of the configuration on "A",
but I wouldn't have to.  I'd download and categorize mail from both "A"
and "B" exactly the same way, via my MUA.  And I'd contact "C" and ask
them to add support for this same common format.

As it is today, I don't make use of any of it, except for a couple of
cases on "A" that get used only when I want to send mail to my own home
address from my work.  I probably would use more if I had the envelope
address hooks on "B", because my MUA is configurable enough to support
both "A" and "B" formats; but it's still inconvenient to keep the two
configurations (MUA and "A") in sync, and that still doesn't give me
anything new in the way of leverage with "C".  And my MUA's interface on
configuring and selecting among subaddresses could be improved if there
were only one format to support, as well.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Date: Sun, 3 Aug 1997 00:32:12 -0400 (EDT)
From: "Donald E. Eastlake 3rd" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

On 2 Aug 1997, D. J. Bernstein wrote:

> Date: 2 Aug 1997 07:17:47 -0000
> From: D. J. Bernstein <[email-masked]>
> To: [email-masked]
> Subject: Re: Email Subaddressing
> 
> ...
> 
> I have neither the time nor the patience to explain operating system
> design, or my users' needs, to a parade of inexperienced IETF nitwits.

Well, you do seem to have plenty of time to post messages showing how
incapable you are of communicating with anyone having a different viewpoint. 

> The burden is on the aforementioned nitwits to read RFC 2119, section 6,
> and to butt out of areas where they don't belong.

Sorry, that section has almost nothing to do with it.  For example, people
can interoperate fine at the IP level with no domain name service.  And
someone who wanted to could keep jumping up and down and arguing primarily by
dogmantic assertion, as you do, that IP numbers are all you really need to
interoperate and that symbolic names are a purely private issue.  After all,
if people don't like a particular symbolic naming scheme, surely the product
will fail in the market place.  No need for standards here.  That's about
what you are saying about subaddressing. 

In fact, almost all IETF standards are of the form, if you want to do X, 
here is how you should do it.  The fact that not everyone wants to do X 
and can thus interoperate without any X, standard or not, is not very 
relevant.  And the fact that people can interoperate doing X by using 
various ad hoc non-standarized ways, while a factor of varying strength 
against standardization, is by no means a bar to it.

> ---Dan
> Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Like most of the nitwits out here, I would like to see some sort of rough 
consensus on a syntax for subaddress for quite a few reasons including 
some I have mentioned previously and as a way to bring a bit more 
pressure on product vendors to include such a feature.

Are you putting up such exaggerated and overblown resistence to this idea 
because you want to minimize the probability of the inclusion of such a 
feature in competing product?

Donald
=====================================================================
Donald E. Eastlake 3rd     +1 508-287-4877(tel)     [email-masked]
   318 Acton Street        +1 508-371-7148(fax)     [email-masked]
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.eff.org/blueribbon.html

Date: 3 Aug 1997 00:56:42 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

> As I said, it's inconvenience.

_What_ is inconvenient?

Chris's proposed mailing-list rule, though dangerously naive, at least
made it obvious what problem he was worried about. Your proposal is so
vague that I have no idea what it's supposed to accomplish.

> The interoperability problem is that the software on my Mac has to
> support both schemes.

What for?

I know people using subaddresses with a variety of MUAs. The MUAs all
deal with incoming _mailboxes_, not incoming addresses. Why should an
MUA care which addresses are owned by the user? 

Why don't you skip the vague generalities and give some specific
examples?

Yes or no: Are you having trouble sending messages? If yes, what is an
example of a message that you wanted to send? How did the system stop
you from sending that message?

Yes or no: Are you having trouble receiving messages? If yes, what is an
example of a message that you wanted to receive? How did the system stop
you from receiving that message?

> No, but if I'm going to put the right thing in my Reply-To or From header,
> I need to know what format the MTA and LDA are willing to accept when my
> recipients send mail back to me.

Huh?

The sysadmin gives the user an e-mail address. The user types it into
his MUA. Millions of users have successfully accomplished this feat.

Why should the MUA care about internal structure in the user's address?
All it does is copy the address.

> That's true, but the server (also incorrectly but by bilateral agreement)
> doesn't have a submission agent either.

False. The server (most commonly sendmail; sometimes qmail with
qmail-inject) includes a submission agent.

Have you already forgotten what ``submission agent'' means? I said two
days ago what submission agents do.

> I simply adopted your terminology
> because you refused to discuss the real-world situation of MUAs talking
> directly to MTAs.

False. The real-world situation is that MUAs talk to submission agents.

Many MTAs do not provide submission services by default. When MUAs talk
to those MTAs directly, malformed messages escape onto the Internet. In
some cases recipients can't respond since the From field is unqualified.
This problem is, as I said, solved by bilateral agreement: the MTA is
configured to provide submission services for certain IP addresses.

sendmail includes both a submission agent and an MTA, and currently
treats every message as a submission, but sendmail's author has been
adding options to change this.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

From: "Bart Schaefer" <[email-masked]>
Date: Sat, 2 Aug 1997 16:32:54 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "Re: Email Subaddressing" (Aug  2, 10:15pm)
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

On Aug 2, 10:15pm, D. J. Bernstein wrote:
} Subject: Re: Email Subaddressing
}
} > I just don't use subaddressing anywhere,
} 
} What exactly is the problem?

As I said, it's inconvenience.

} You've told us that one of your ISPs doesn't support subaddressing. Has
} it occurred to you that mail receipt isn't free?

That's irrelevant.  I'm not interested in forcing the ISP to support
subaddressing if it's too expensive for some strange reason.  I am
interested in encouraging MTA and LDA writers to include subaddressing
support so that ISPs could more easily find MTAs that support whatever
features led them to pick the one they have now, and subaddressing too.
But that's a reason for an informational document, not a standard.

} You've told us that your two other ISPs use different subaddressing
} systems. So what? Why should they match? Different domains have
} different address spaces. Where is the interoperability problem?

The interoperability problem is that the software on my Mac has to
support both schemes.  It's much easier to write software if there is
only one scheme to support.  So if there's a standard scheme, more MTA
software will support it and more MUA software will support it, and
it'll be easier for me to find software that works for multiple ISPs.

} > I am interested in how the submission agent that comes with my Mac MUA
} > interfaces with the MTA and LDA on the Win/NT host that's my ISP's IMAP
} > server.
} 
} What are you talking about? Submission agents don't talk to LDAs, or to
} IMAP servers.

No, but if I'm going to put the right thing in my Reply-To or From header,
I need to know what format the MTA and LDA are willing to accept when my
recipients send mail back to me.  And if the submission agent is in charge
of filling in those headers, as you suggested it should be, then it has to
interoperate with the LDA, albeit by a very circuitous route.

} Your MUA probably doesn't even include a submission agent;
} instead it uses SMTP (incorrectly, but by bilateral agreement) to relay
} what you typed to a submission agent on the server.

That's true, but the server (also incorrectly but by bilateral agreement)
doesn't have a submission agent either.  I simply adopted your terminology
because you refused to discuss the real-world situation of MUAs talking
directly to MTAs.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Date: 2 Aug 1997 22:15:11 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

> I just don't use subaddressing anywhere,

What exactly is the problem? Are you having trouble receiving messages?
Are you having trouble sending messages? Many other people use
subaddresses without trouble.

You've told us that one of your ISPs doesn't support subaddressing. Has
it occurred to you that mail receipt isn't free? Some ISPs charge for
subaddresses; some of them don't have appropriate software. Some ISPs
won't give you _any_ addresses. If you don't like that, use a different
ISP. Where is the interoperability problem?

You've told us that your two other ISPs use different subaddressing
systems. So what? Why should they match? Different domains have
different address spaces. Where is the interoperability problem?

> I am interested in how the submission agent that comes with my Mac MUA
> interfaces with the MTA and LDA on the Win/NT host that's my ISP's IMAP
> server.

What are you talking about? Submission agents don't talk to LDAs, or to
IMAP servers. Your MUA probably doesn't even include a submission agent;
instead it uses SMTP (incorrectly, but by bilateral agreement) to relay
what you typed to a submission agent on the server.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

From: "Bart Schaefer" <[email-masked]>
Date: Sat, 2 Aug 1997 12:58:39 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "Re: Email Subaddressing" (Aug  2,  7:17am)
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

On Aug 2,  7:17am, D. J. Bernstein wrote:
} Subject: Re: Email Subaddressing
}
} The IETF is the Internet Engineering Task Force, not the UNIX MTA-LDA
} Interface Engineering Task Force.

I don't give a damn how a Unix MTA and LDA interface to one another, and
certainly if that were all that's involved here there'd be no need for
a spec.

I am interested in how the submission agent that comes with my Mac MUA
interfaces with the MTA and LDA on the Win/NT host that's my ISP's IMAP
server.  Oh, and by the way, the ISP that's my IMAP server is not the
same one to which my Mac makes its PPP connection; in fact, there are
three different ISPs through which I send and recieve mail, but only
one submission agent on my Mac.  One ISP doesn't do subaddressing, and
the other two don't do it the same way.

As I said quite some while before, this is mainly an inconvenience; it
means I just don't use subaddressing anywhere, even though I'd like to.
Is it a bad enough inconvenience that a standard is needed to eliminate
it?  I'm not sure.  But I certainly haven't seen anything to convince
me that it'll go away by itself without one.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Date: 2 Aug 1997 07:17:47 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

The IETF is the Internet Engineering Task Force, not the UNIX MTA-LDA
Interface Engineering Task Force.

I have neither the time nor the patience to explain operating system
design, or my users' needs, to a parade of inexperienced IETF nitwits.

The burden is on the aforementioned nitwits to read RFC 2119, section 6,
and to butt out of areas where they don't belong.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

From: "Bart Schaefer" <[email-masked]>
Date: Fri, 1 Aug 1997 22:42:16 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "Re: Email Subaddressing" (Aug  1, 10:15pm)
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

On Aug 1, 10:15pm, D. J. Bernstein wrote:
} Subject: Re: Email Subaddressing
}
} > The one and only rule that
} > is necessary is that the primary address always identifies the same
} > entity regardless of what subaddress is attached.
} 
} What does this mean? What is an ``entity''?

It doesn't matter what an entity is.  An entity is whatever the local-part
would refer to if the subaddress were ignored.  Could be a user account,
could be an alias, could be anything.  Up to the interpreting domain.

} Why is this rule necessary?

So that new subaddresses can be created without having to create new
primary addresses.  Without that rule, all you have is flat aliasing.
It's certainly possible to implement equivalent behavior by using flat
aliasing, but then you need rules to prevent name collisions.

} More importantly, that rule is inconsistent with reality. There are
} a+b@host and a+c@host addresses that are _not_ the same entity.

Note that I avoided saying what the separator character is.  But it
really doesn't matter; if a domain that already has a+b and a+c local-
parts wants to begin using "+" as a subaddress separator, it can set up
a psuedo-user "a" whose only purpose is to redirect mail for the "a+b"
and "a+c" local-parts to the right real places.  Nobody outside that
domain should be counting on the final interpretation of "a+b" and "a+c".
The idea is that entities *inside* the domain can count on it, *if* the
domain claims to support subaddressing.

} > I've been asking for alternatives, but the only
} > suggestion so far is that we throw away combinations of agents that
} > don't already understand one another.  Not very helpful either to those
} > who'd like to change existing agents to be able to understand, nor to
} > those who want to write new agents.
} 
} On the contrary. Someone who wants to write (e.g.) a UNIX delivery agent
} that supports qmail's address hierarchy simply has to use the variables
} supplied by qmail-local: LOCAL, USER, EXT, EXT2, EXT3, etc.

That's wonderful if all I want to write is a new agent that interoperates
with qmail and other qmail agents.  What if I want to write an agent that
I can expect to interoperate with any of a large number of other MTAs and
LDAs or submission agents?  Are you going to convince Netscape and MS and
Software.com and Innosoft etc. all to adopt your scheme on all platforms
they support?

This discussion has now reached the point of arguing only for the sake of
arguing, so I'm bailing out until some other people have had a say.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Date: 2 Aug 1997 02:22:08 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

> > More importantly, that rule is inconsistent with reality. There are
> > a+b@host and a+c@host addresses that are _not_ the same entity.
> The important point here is that a@host controls where mail to a+b@host
> and a+c@host is routed.

I explicitly said that I'm talking about reality, not your proposal.

In the real world, what you're saying is simply not true. For example,
there's no ``info-g'' user controlling the info-g++ mailing list.

If you want to document what people do at CMU, fine. But please give it
an honest label that reflects your limited experience: e.g., ``The AFS
Mail Addressing System.'' Don't pretend that it's a de facto standard.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: Fri, 01 Aug 1997 18:31:54 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Email Subaddressing
To: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Fri, 1 Aug 1997, D. J. Bernstein wrote:
> What does this mean? What is an ``entity''? Why is this rule necessary?
> 
> More importantly, that rule is inconsistent with reality. There are
> a+b@host and a+c@host addresses that are _not_ the same entity.

The important point here is that a@host controls where mail to a+b@host
and a+c@host is routed.  That's what I mean by subaddress as distinct from
a simple naming hierarchy.

		- Chris

Date: 1 Aug 1997 22:15:13 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

> A syntax for subaddresses in local parts,

Sensible definitions such as

   The ``plus-terminated prefix'' of an address is everything up to and
   not including the first "+" character, or the entire address if it
   does not contain a "+" character.

or

   The ``dash-separated components'' of an address are its maximal
   substrings not containing "-" characters. For example, the
   dash-separated components of "jean-marc-sos-request" are the strings
   "jean", "marc", "sos", and "request".

are fine with me.

Such definitions might be useful in, e.g., an informational document
surveying common address formats and their uses.

> The one and only rule that
> is necessary is that the primary address always identifies the same
> entity regardless of what subaddress is attached.

What does this mean? What is an ``entity''? Why is this rule necessary?

More importantly, that rule is inconsistent with reality. There are
a+b@host and a+c@host addresses that are _not_ the same entity.

> I've been asking for alternatives, but the only
> suggestion so far is that we throw away combinations of agents that
> don't already understand one another.  Not very helpful either to those
> who'd like to change existing agents to be able to understand, nor to
> those who want to write new agents.

On the contrary. Someone who wants to write (e.g.) a UNIX delivery agent
that supports qmail's address hierarchy simply has to use the variables
supplied by qmail-local: LOCAL, USER, EXT, EXT2, EXT3, etc.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

From: "Bart Schaefer" <[email-masked]>
Date: Fri, 1 Aug 1997 13:06:20 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "Re: Email Subaddressing" (Aug  1,  6:55pm)
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

On Aug 1,  6:55pm, D. J. Bernstein wrote:
} Subject: Re: Email Subaddressing
}
} > So somebody who wants to create and market *only* an LDA or *only* a
} > submission agent should be shut out of the competitive process because
} > there's no way to interoperate?
} 
} I specifically pointed out that submission agents in qmail are
} interchangeable, and that delivery agents are interchangeable even
} across qmail and sendmail.

There must be some set of rules for how submission and delivery agents
have to behave in order to be interchanged.  Isn't what Chris suggests
(at the syntactic level) simply a standardization of one of those rules?

} > How can those remote users obtain the benefits of subaddressing?
} 
} They select software that can easily be configured to handle their local
} subaddresses.

Isn't one of the IETF's goals to help make a wider variety of such software
available?  Doesn't knowing what kinds of configuration are expected help
developers to write configurable software?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Date: 1 Aug 1997 19:50:17 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

> In fact, you were recently
> suggesting that a Wide-Reply-To header be standardized

Absolutely not.

I have suggested that the IETF _define_ useful ``reply'' concepts.

I have repeatedly emphasized that the relation between those ``reply''
concepts and the user interface is none of the IETF's business.

I have also pointed out several times that ``Wide-Reply-To'', being new
functionality, is not ready for standardization.

> almost every application protocol has a profound
> impact on the way a user interface works.

Most protocols have at most a superficial effect on user interfaces. The
occasional protocols designed for human use as well as computer use,
such as RFC 822, are interoperability disasters, certainly not something
to be imitated.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

From: "Bart Schaefer" <[email-masked]>
Date: Fri, 1 Aug 1997 12:46:16 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "Re: Email Subaddressing" (Aug  1,  6:33pm)
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

On Aug 1,  6:33pm, D. J. Bernstein wrote:
} Subject: Re: Email Subaddressing
}
} > Standarizing things has benefits and costs.
} 
} But standardizing user interfaces, no matter how beneficial, is none of
} the IETF's business.

I'm wondering if we have two separate points of dispute getting mixed into
the same argument.

The draft as Chris wrote it consists of two major parts:  A syntax for
subaddresses in local parts, and rules for how various agents should
treat local-parts that include subaddresses.

I agree that some of the rules for the semantics of subaddressing could
intrude on user interface and host policy.  The one and only rule that
is necessary is that the primary address always identifies the same
entity regardless of what subaddress is attached.  (If that primary
entity wants to dispatch certain subadresses to other entities, that's
entirely up to the primary entity or its representative.)

Further, the interpretation of local-parts as address plus subaddress
can be limited entirely to the host identified by the domain-part; it's
neither necessary to require nor necessary to prohibit interpretation by
intermediaries like mailing list managers.

The syntax, however, is entirely a data format, not a user interface.

I think Dan's remark above is directed at the semantics of local-parts;
but it's not clear whether the "benefits and costs" remark (sorry, don't
remember who wrote it) is referring to the entire draft or only to the
syntax dispute.

I want to stick to the syntax for now.

Even if that syntax is opaque to relays and other intermediaries, it
is necessary for it to be transparent to LDAs and submission agents
within the interpreting domain.  One way to make the syntax transparent
is to standardize it; I've been asking for alternatives, but the only
suggestion so far is that we throw away combinations of agents that
don't already understand one another.  Not very helpful either to those
who'd like to change existing agents to be able to understand, nor to
those who want to write new agents.

One alternative that I've thought of is to make it possible to discover
the syntax.  This is effectively what Dan's ``addalias'' program does
by sharing its configuration file.  It would certainly be possible to
create a simple protocol, possibly as part of the ietf-submit work
already in progress, for remote clients to learn the local-part syntax
of their server host.

However, we've already seen how well such a discovery mechanism works
with hierarchy separators in the IMAP4 protocol:  To wit, badly, if at
all.  Nearly everyone agrees that it would have been preferable to pick
a hierarchy separator and standardize it, even if that means restricting
the mailbox names that the server can present.

The situation here is no different; standardizing a character to separate
primary address from subaddress is far more workable than standardizing
a discovery mechanism, even if it means restricting the primary addresses
that a server can support.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Date: Fri, 1 Aug 1997 15:27:21 -0400 (EDT)
From: "Donald E. Eastlake 3rd" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

On 1 Aug 1997, D. J. Bernstein wrote:

> Date: 1 Aug 1997 18:33:04 -0000
> From: D. J. Bernstein <[email-masked]>
> 
> > If agents wish to constrain from addresses to fight spoofing or whatever but
> > allow subaddress editing, they can't do it because there is no uniformity of
> > subadressing.
> 
> Sorry, but you're wrong. The agent can rely on local configuration to
> decide which addresses are permitted for each user.

"can" does not mean it is the best way.

>...
> > Standarizing things has benefits and costs.
> 
> But standardizing user interfaces, no matter how beneficial, is none of
> the IETF's business.

Nonsense.  The IETF has zillions of standards that effect user interface. 
How 822 heaers and domain names and IP addresses are formed and parsed for
example.  Although, from another point of view, these are actually standards
for the wire format.  Just as a "+" separator for subaddressing would, in
principle, only effect the wire format.  A UI could have separate text boxes
for the pieces of the local part, for example. 

> > I don't know where you get this idea that IETF standards are requirements.
> 
> What are you talking about? I said ``document... requiring that all MTAs
> and LDAs work the same way.''

We'rem talking about an effort to create a standard for email subaddressing. 

> ---Dan

Donald
=====================================================================
Donald E. Eastlake 3rd     +1 508-287-4877(tel)     [email-masked]
   318 Acton Street        +1 508-371-7148(fax)     [email-masked]
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.eff.org/blueribbon.html

Date: Fri, 01 Aug 1997 12:11:24 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Email Subaddressing
To: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Fri, 1 Aug 1997, D. J. Bernstein wrote:
> But standardizing user interfaces, no matter how beneficial, is none of
> the IETF's business.

Most of RFC 822 impacts the user interface.  In fact, you were recently
suggesting that a Wide-Reply-To header be standardized -- thereby
mandating a user interface to that header.

The IETF's job is to promote multi-vendor interoperability by defining
standardized protocols.  While it's good to avoid unnecessary constraints
on the user interface, almost every application protocol has a profound
impact on the way a user interface works.

Standardizing one subaddress format means that any product which chooses
to use the standard subaddress format (and this choice is by no means
mandatory) will interoperate with subaddress support in other products
implementing the standard.

		- Chris

Date: 1 Aug 1997 18:55:34 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

> So somebody who wants to create and market *only* an LDA or *only* a
> submission agent should be shut out of the competitive process because
> there's no way to interoperate?

I specifically pointed out that submission agents in qmail are
interchangeable, and that delivery agents are interchangeable even
across qmail and sendmail.

> How can those remote users obtain the benefits of subaddressing?

They select software that can easily be configured to handle their local
subaddresses.

> (BTW, I tried to follow http://pobox.com/~djb/ezmlm.html and got
> "http://pobox.com/nobodyezmlm.html - 404 file not found".)

Thanks. Looks like pobox screwed up their forwarding for FTP URLs. You
can use ftp://koobera.math.uic.edu/www/ezmlm.html for now.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Date: 1 Aug 1997 18:33:04 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

> If agents wish to constrain from addresses to fight spoofing or whatever but
> allow subaddress editing, they can't do it because there is no uniformity of
> subadressing.

Sorry, but you're wrong. The agent can rely on local configuration to
decide which addresses are permitted for each user.

My ``addalias'' program, published in 1993, does exactly this. An MUA
that reads the addalias configuration file for From control will follow
the same rules.

> I'm not sure if the benefits warrant standardization but I don't accept
> your arguments by dogmatic assertion:

And I don't accept yours. The difference is that my arguments are
supported by facts.

> Standarizing things has benefits and costs.

But standardizing user interfaces, no matter how beneficial, is none of
the IETF's business.

> I don't know where you get this idea that IETF standards are requirements.

What are you talking about? I said ``document... requiring that all MTAs
and LDAs work the same way.''

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

From: "Bart Schaefer" <[email-masked]>
Date: Fri, 1 Aug 1997 10:42:54 -0700
Comments: In reply to "D. J. Bernstein" <[email-masked]> "Re: Email Subaddressing" (Aug  1, 12:29am)
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

On Aug 1, 12:29am, D. J. Bernstein wrote:
} Subject: Re: Email Subaddressing
}
} > Is there any way to make the answer be "yes"
} 
} MTAs and LDAs that don't support what the users want are thrown away.

That's very nice in theory, but in the "real world" the MTAs and LDAs
are more often chosen on the basis of what the MTA administrator wants.

} This is called competition. It's how the real world makes progress.

So somebody who wants to create and market *only* an LDA or *only* a
submission agent should be shut out of the competitive process because
there's no way to interoperate?

I'd rather see competition on quality and versatility than on proprietary
data formats.

} > other than standardizing the format subaddresses?
} 
} It's none of your business how a host interprets its local addresses.

It's certainly the business of the users of that host.  In the "real
world" an awful lot of those users are sitting on the far side of POP
or IMAP and SMTP connections, with control over how their personal MUA
is configured but absolutely no control over the host that interprets
their local addresses.

How can those remote users obtain the benefits of subaddressing?

(BTW, I tried to follow http://pobox.com/~djb/ezmlm.html and got
"http://pobox.com/nobodyezmlm.html - 404 file not found".)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Date: Fri, 1 Aug 1997 10:46:28 -0400 (EDT)
From: "Donald E. Eastlake 3rd" <[email-masked]>
To: [email-masked]
Subject: Re: Email Subaddressing
Sender: [email-masked]

Dan,

I'm not sure if the benefits warrant standardization but I don't accept
your arguments by dogmatic assertion:

On 31 Jul 1997, D. J. Bernstein wrote:

> Date: 31 Jul 1997 08:30:54 -0000
> From: D. J. Bernstein <[email-masked]>
> 
> > There are two cases where MUAs need to cooperate with subaddresses:
> > 1) MUAs which don't allow from to be edited otherwise.
> 
> This is a purely local configuration problem.

If agents wish to constrain from addresses to fight spoofing or whatever but
allow subaddress editing, they can't do it because there is no uniformity of
subadressing.  If there were a standard, they could.  I believe this would be
a benefit. 

Standarizing things has benefits and costs.  The benefits are not eliminated
by you enormous distaste for the particular standarization or your 
failure to acknowledge the benefits.

> > 2) MUAs which validate local addresses against a white pages or authdb
> > service.
> 
> A service that claims to check mail addresses obviously has to
> understand subaddresses. This is a purely local configuration problem.
> 
> > 1) List server restricts posting to subscribers.
> 
> You have no right to demand that list owners accept your mail.

The closest thing I've seen to a demand is your demand that this not be
standardized.  Most list owners want to accept mail and if subaddressing were
standardized, I believe many list servers would adapt to the standard.  If it
is not standardized, some sort of informal consensus might develop but it
would be much slower. 

> > There are several cases where a final delivery agent needs to cooperate
> > with subaddresses:
> 
> All of those cases are purely local configuration problems.
> 
> I suppose next we're going to see a document explaining how sendmail
> interacts with procmail, and requiring that all MTAs and LDAs work the
> same way.

I don't know where you get this idea that IETF standards are requirements.  I
supose you could say that of the tiny handful that are classified as
"mandatory", but that certainly doens't include *any* of the email standards
most of which are in the "recommended" or "elective" categories of IETF
standards.  See RFC 2200.

> ---Dan
> Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html

Donald
=====================================================================
Donald E. Eastlake 3rd     +1 508-287-4877(tel)     [email-masked]
   318 Acton Street        +1 508-371-7148(fax)     [email-masked]
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.eff.org/blueribbon.html