Re: objections, again

Chris Newman <Chris.Newman@innosoft.com> Sun, 03 August 1997 19:24 UTC

Received: from cnri by ietf.org id aa10945; 3 Aug 97 15:24 EDT
Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA07433; Sun, 3 Aug 1997 15:22:39 -0400 (EDT)
Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA13615 for ietf-822-bks; Sun, 3 Aug 1997 12:04:06 -0700 (PDT)
Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA13611 for <ietf-822@imc.org>; Sun, 3 Aug 1997 12:04:02 -0700 (PDT)
Received: from eleanor.innosoft.com ("port 53482"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IM03JD27GK8WXZEU@INNOSOFT.COM> for ietf-822@imc.org; Sun, 3 Aug 1997 12:07:11 PDT
Date: Sun, 03 Aug 1997 12:09:01 -0700
From: Chris Newman <Chris.Newman@innosoft.com>
Subject: Re: objections, again
In-reply-to: <19970803074450.2023.qmail@koobera.math.uic.edu>
To: ietf-822@imc.org
Message-id: <Pine.SOL.3.95.970803113840.12748B-100000@eleanor.innosoft.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset="US-ASCII"
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: owner-ietf-822@imc.org
Precedence: bulk

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.