Re: rough sketch of a potential solution

Keith Moore <[email protected]> wrote:

> 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.

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.

> But now I remember another one of the reasons for allowing the mapping
> service to sign address mappings (and to include those signatures in
> the address mapping header extensions) - it was so that if a message
> were signed by [email protected] but shown to the recipient as if it were
> from [email protected], it would be possible for the recipient's MUA to
> verify that the two addresses really were equivalent.
>
> (unless the mappings are signed by the domain) you permit a rogue
> third-party to add additional headers that say "my.new.address@domain
> is equivalent to the From address" and sign the message with
> my.new.address@domain - making it appear that the (perhaps altered)
> message was signed by the From address, when it wasn't.

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.

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.  This would avoid the need for a separate signature on
the alternate-addresses header field.

AMC