 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
Shawn Steele wrote:
Local names are not decoded until they arrive at the destination domain. At that point, if a mailbox exists for the local name, it is delivered. On EAI systems, if that mailbox does not exist, then the name is decoded and a second delivery is attempted to the UTF8 mailbox. If the checks outlined earlier are followed when creating new mailboxes, delivery will never go to different users for these two cases.My worry is about what happens if the recipient tries to decode the left-hand side as if it was a Punycoded name when it is not. Unless one can tell the difference between those domains that use Punycoded LHS and those that do not, a recipient will apply the Punycode decoding to left-hand sides indiscriminately. This can lead to similar effects as the "Bush hid the facts" bug (see http://en.wikipedia.org/wiki/Bush_hid_the_facts for details).Yup.
In fact, email administration on an ACE-based EAI should assign the punycode translation of local addresses as an alias for the UTF8 address. So delivery of either punycode or UTF8 goes to the same mailbox without the above two step delivery process.
We have to be careful about about making a statistical decision. If there is any chance that mail gets delivered to the wrong place, it is a serious breach of privacy. This takes precedence over other goals such as "works 99.999% of the time". This is a more serious failure than delivery failures in the triangle case, which is what we are basically trying to solve with an ACE-based downgrade.But I think it's worth the improvement for behavior in the 99.999% case. Maybe we could get statistics for how many account names actually look like this. Also we could pick something really wierd (like the q.-_.z or something).
-Ernie