Re: A couple of comments on the open issues...

Martin Duerst <[email protected]> wrote:

> Is subadressing just something that is done by a few email systems
> locally, or is it something specified in some of the email standards?

As far as I know, there are no standards for any structured local parts.
It's all unofficial conventions.

> to what extent do we really have to consider it here?

I'd say we're under no obligation to play nicely with these unofficial
practices, but our goal is to create utility, not frustration, so we
shouldn't immediately dismiss the concern.

> Also, using subaddressing seems to be quite popular for high-end
> users.  But is it actually very much used by the bulk of users (the
> proverbial hotmail/yahoo/... crowd)?

Currently, no.  As spam becomes ever more of a problem, more users might
start using subaddressing as a means of combating it (like I do).

> It's also easy to imagine that users have a single internationalized
> address (for personal mail) and a bunch of structured addresses (for
> list subscriptions,...).

That's a good point.

But then there are freaks like me who use subaddressing for all mail,
personal or not, as a means of eliminating spam.  Every address is
expendable and can be disabled the first time it receives spam; there is
no single stable mail address for me (but there is a stable template,
and a stable URL).

> A third thing I have just thought about is that the design of punycode
> actually has some very nice properties that allow separation of the
> subnet address in most cases even if the whole LHS is encoded in one
> go.

That's kind of cool, but as Roy says, it still doesn't let people use
IMAs containing delimiters in the local part.  If the mail server for
the domain is configured to support user+tag syntax, but the ACE form
of USER+tag looks like xn--+tag-blahblah, then it won't work at all,
because the mail server will try to deliver to xn--.

So users would not get the full IMAA functionality until the
infrastructure (the MTA) has been upgraded, which is an undesirable
dependence (one that IDNA does not suffer).  The counter-argument is
that most users won't care about the missing functionality.

AMC