Re: New draft, new idea
Grant Baillie <[email protected]> Thu, 5 Feb 2004 09:23:03 -0800
| Newsgroups | gmane.ietf.imaa |
|---|---|
| Message-ID | <[email protected]> |
On 04 Feb 2004, at 4:58 PM, Paul Hoffman / IMC wrote: > Greetings again. Based on an idea originally proposed here by Keith > Moore, I have created yet another proposal. See > <http://www.imc.org/ietf-imaa/hoffman-iea-headermap-00.txt>, at least > until the Internet Drafts directory gets it published. > > This proposal starts were Adam and I did with IMAA (be client-only), > but goes even further in making it unobtrusive. Basically, there is an > optional map in the headers which tell an MUA how to display mailbox > names in headers. Mailbox names remain the same: they just get > displayed differently. I'm new to the discussion, but here are some issues I see: (1) What's to stop me from sending you a mail from some email address, using address-map: to change its display value to "[email protected]", and asking you to reply with your credit card #? It seems that there's a potential for a new kind of social engineering attack here, unless MUAs are quite careful about how mapped addresses are displayed. (2) So far as the following goes: > Clearly, users of enhanced MUAs will expect to be able to enter mailbox > names in the native scripts. Therefore, MUAs that follow this > specification SHOULD keep mappings in their address book function. > Similarly, MUAs that follow this specification MUST be able to add > Address-map headers to outgoing mail messages. I think there's more to it than just maintaining a mapping in the client's local address book: Formats like vcard (and LDAP, I think) would need to have some kind of standardized "display email address" field to remain interoperable. (3) There are implications for IMAP clients that fetch the ENVELOPE message attribute to show message summary information: They wouldn't be able to display addresses properly without issuing an extra header fetch. -------------------- Grant Baillie Mac OS X Mail Apple Computer, Inc. --------------------