[UA-EAI] UASG014 - Quick Guide to EAI

[Mark Svancarek]

UPDATE FROM UASG HK / GZ MEETINGS

After many discussions about downgrading, we have decided that the official UASG stance must be to support only aliasing of one's own mailboxes (user can elect to provide an address for auto-alias; webmail providers can auto-alias their own mailboxes when SMTPUTF8 isn't advertised; etc.).

Any other mechanism is outside of UASG recommended practice, as well as IETF recommended practice.  If your SW or service uses any other mechanism or transformation, that is between you and your customers. It will never be endorsed by UASG, and quite likely will be disavowed.

As such, I prefer that we not continue to propose them or discuss such mechanisms on the discussion group.  In fact, I think we should update the code of conduct to reflect this approach, as we would for any other unproductive line of discussion.

I might just start shouting down these discussions whenever they pop up.  That would be terribly rude, I think.

Help me not to be terribly rude.  Please don't discuss downgrading* techniques on the mailing list!

/marksv

*Not everyone agrees that "auto-aliasing" is even a form of "downgrading".  But if you do, I request that you call it "auto-aliasing" or some other term just to help us keep the disctinction between what UASG supports (auto-aliasing) and what UASG doesn't support (everything else) distinct.

-----Original Message-----
From: UA-EAI [mailto:ua-eai-bounces at icann.org] On Behalf Of John R. Levine
Sent: Wednesday, January 17, 2018 10:41 AM
To: Don Hollander <don.hollander at icann.org>
Cc: ua-eai at icann.org
Subject: Re: [UA-EAI] UASG014 - Quick Guide to EAI

> Thanks for these comments.
>
> When a set of mail applications are bundled under a single umbrella, then the operator can do more - and the Transformation using an existing Alias is possible.
>
> But, if a mail user is using discrete components, then can you reasonably expect them to interact as we suggest transformation?
>
> Are we back to square 1' - having eliminated an algorithmic transformation of a non-ascii mailbox name?

FYI, the IETF's EAI group went through all of this stuff in excruciating detail.  The original experimental version had a bunch of downgrade features, nearly all of which went away in the later proposed standard because they just didn't work.

I think it's safe to say that the answer to any question of the form "how about if you downgrade using approach X" will be that "X turns out not to work, you'd better use the effort to make EAI work."

The only downgrade features left are ones to let old clients fetch EAI messages from POP and IMAP servers, and they don't try to make anything relplyable, just smash the headers so they're valid under RFC 5322.

Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjl.ly&data=02%7C01%7Cmarksv%40microsoft.com%7Cceb56687f8df4fe0a15f08d55dd9e33a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636518112758247250&sdata=cgrzChhVrJD4NqtdbKDEqfBMnTmH%2BLXP02wPSuA1xs0%3D&reserved=0
_______________________________________________
UA-EAI mailing list
UA-EAI at icann.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fua-eai&data=02%7C01%7Cmarksv%40microsoft.com%7Cceb56687f8df4fe0a15f08d55dd9e33a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636518112758247250&sdata=QWnMHjFP%2FC2w5rlU2NbjMu9dt3LwrKVsFc3SA0OPJBM%3D&reserved=0