Re: objections, again

[Chris Newman <[e-mail]>]

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