Re: [EAI] double angle brackets
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [EAI] double angle brackets



> To replace double angle brackets for the Sender, John Klensin proposed 
> using multiple From fields. SM amended this with Reply-To to specify the 
> preferred address, as in
>         From: EAI-addr, ASCII-addr
>         Reply-To: EAI-addr
> where the EAI-addr gets dropped in Downgrade.

I'd imagine that "something" isn't going to be happy with 2 addresses.

It seems to me that 99% of the time email can be viewed as primarily "sender side" or "recipient side".  Eg: Mail goes from a sender system to a recipient system.  It is very rare (now) that an in-between system would relay mail from an untrusted server to another 3rd party server.  If there is a relay, it'd have to trust the sender, so it's pretty much "sender side," or recognize the recipient "recipient side."

Assuming that a "sender" has an EAI aware system that is completely conformant and "works" with UTF-8 addresses, then the entire "sender side" would have to be updated to support UTF-8 addresses.  If the sender's relays aren't upgraded, then all of their mail ends up being downgraded anyway.

Similarly a recipient either has an entirely EAI aware system, or they don't.  

So I'm wondering how interesting downgrade really is.  If my sending system trusts the sender, presumably it could request an ASCII address from the trusted sender-side server if it needed to downgrade.  (Through some other mechanism, like asking the trusted server what other aliases were valid for that account using some new, or even proprietary, protocol).

So the proposed solution seems like overkill.

VERY worst case a client (like Outlook) can try to send an EAI email.  If it bounces, the client could resend using my ASCII address (assuming it is properly configured).  It could even do that silently, or with maybe a little warning saying that had been downgraded.

-Shawn


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.