Re: rough sketch of a potential solution

>> consider a.example.com and b.example.com that were intended to
>> be equivalents. each would have a SRV record pointing to the
>> same hostname/port. sender types <stuff>@a.example.com but the
>> distinguished domain is b.example.com. sender's MUA does the
>> following.
>>
>> - lookup SRV for _ams._tcp.a.example.com, gets back ams.example.com
>>   port NNN
>> - contacts ams.example.com port NNN
>> - >>> I'm looking for address lookups on "a.example.com"
>> - <<< distinguished domain is "b.example.com"
>> - >>> lookup equivalents for "<stuff>"
>> - <<< equivalents are ...
>> - >>> (close connection)
>> - sender then looks up SRV for _ams._tcp.b.example.com. if it gets
>>   back the same result as the original SRV record, it considers the
>>   results valid (after all, it was just talking to that server). if
>>   not, it considers the entire lookup invalid and falls back to IMAA
>>   encoding
>
> Hmmm, it looks like you and I have had slightly different ideas about
> what these address mappings would mean.  You apparently want the
> alternate-address header field to state that several addresses are all
> alternates for each other.  In order to get proper permission to make
> that claim, we need to look up all the addresses and make sure they all
> list each other as alternates.

not if all of the alternates are constrained to be in the same domain 
(with the possibility for multiple names for that single domain).  
essentially what this means is that the server that supplies names for 
that domain MUST ensure that no address appears in more than one set of 
alternates.  but the sending mail client isn't expected to verify this.

> I was imagining that the "alternate for" relation is not assumed to
> be symmetric.  When I compose a message in which address1 appears, my
> MUA looks up address1, gets back address2 and address3, and puts a
> field in the header that says that address2 and address3 are alternates
> for address1 (with no implication that address2 and address3 have any
> alternates).  It is safe for the recipient's MUA to display address2 or
> address3 in place of address1 because we got address1's permission; we
> don't need permission from address2 or address3 for that.  And there
> is no need for the header to assert that anything is an alternate for
> address2 or address3, because that information wouldn't be useful to
> the recipient.  It's only address1 that appears in the real field, and
> therefore only address1's alternates that would be useful.  When the
> recipient replies to all, address1 will remain in the real field and
> address2 and address3 will remain in the alternates field.  If anyone
> ever types or pastes address2 into a real field, then it will be looked
> up in order to discover its alternates.

This isn't quite sufficient because 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.  So we want to 
ensure that sending to an alternate address  has exactly the same 
result as sending to a fallback address.

> I'm skeptical of a proposal to sign a particular kind of header field.
> There are presumably plenty of header fields that could benefit from 
> the
> ability to be signed.  I would expect a more general-purpose scheme to
> be the way to go.

I don't think of it as signing a header field; I think of it is as 
signing the mapping data, which happens to be represented in a header 
field.  It's much harder to define a way to sign an arbitrary header 
field than it is to define a way to sign data that happens to be 
storable in a header field.

> But I'm also skeptical of this roundabout way of presenting signatures:
> address1 signs the message, and signs a note saying "address2 is an
> alternate for address1", and the MUA then concludes that it's safe
> to tell the user that the message is signed by address2.  A more
> direct approach would be for the signer to sign the message with both
> addresses.  I'm not very familiar with S/MIME, but I scanned RFC 3280
> (regarding the use of X.509 certificates on the Internet) and it looks
> like a certificate can contain multiple email addresses bound to a
> single public key.  That would seem to be exactly what we need.  The 
> MUA
> could take the intersection of {the From address and its alternates} 
> and
> {the addresses in the certificate}, and from the intersection choose
> the address best suited to the user's locale, and display that as the
> author&signer.

works for me.  Not sure about OpenPGP though.

> This would avoid the need for a separate signature on
> the alternate-addresses header field.

perhaps.  I'd certainly prefer to avoid the signature if we can do 
without it.

Keith