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