Re: rough sketch of a potential solution

>  Suppose Alice and Mallory are two
> unrelated people.  Alice gets an email account from example.com,
> and gets a certificate from some CA.  She doesn't trust example.com
> nearly as much as she trusts the CA, but example.com is limited to
> denial-of-service attacks; it can divert her incoming or outgoing mail,
> but because it doesn't know her private key, it can't forge signed mail
> from her, and it can't read encrypted mail to her, so she's willing to
> use an email account from this not-really-trusted entity.

only example.com can really say who [email protected] is; example.com 
is free to change this binding anyway.  so any certificate from an 
external CA that makes assertions about who [email protected] is is 
meaningless.

> Maybe there's a way to fix this, but I think we're all leaning toward
> the multiple-addresses-in-the-certificate approach anyway.

me too.

> When you say "issued in the same domain", do you mean that the 
> addresses
> have the same domain-part (the part after the at-sign)?  Or are you
> referring to some PKI-related concept of "domain"?
>
> If you mean that the addresses have the same domain-part, I think that
> restriction would destroy our whole motivation for alternate addresses.
> The point is to have one address that's memorable for users of one
> script, and another address that's memorable for users of another
> script.  The two addresses will obviously contain distinct IDNs.

we can do that if we have a way to declare that the two IDNs are 
equivalent.  what we don't want to do is build a mechanism that can map 
an arbitrary email address onto another arbitrary email address.  
that's opens Pandora's box.

>> we want people to be able to transcribe the addresses that are
>> displayed to them, or use the addresses stored in their address books,
>> which in either case may be alternate addresses rather than fallback
>> addresses.
>
> Agreed.
>
>> So we want to ensure that sending to an alternate address has exactly
>> the same result as sending to a fallback address.
>
> But I still don't see a need to do more than one lookup in the address
> mapping service.  When I send mail, I can put whatever address I like 
> in
> the From field and the Reply-To field.

It's not the originator fields that are the problem so much as the 
recipient fields.   A's MUA needs the address mapping service to obtain 
alternative addresses for B and C so that each address will be 
maximally transcribable by all recipients.