Re: objections, again

[Todd Vierling <[e-mail]>]

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 [e-mail]; Alternate [e-mail])
== I'm glad you like the Internet, Bobby.  Now go eat your Frosted Flakes.