Issues identified during todays meeting

[Niels Möller]

For the record, I'll list the most important issues identified during
today's meeting.

1. It's undesirable that the MAC is computed over the message body.

   One possible alternative is to compute the MAC over a string
   constructed from envelope sender + receiver + salt, where the salt
   is chosen randomly by the receiving MTA. This is analogous to the
   things that go into a hash cash challenge string.

2. Asymmetric transport, where an email and a reply are relayed
   through different administrative domains. Example: Home user with
   a vanity domain and email address user@vanity.org. There's an MTA
   for vanity.org than handles incoming mail, but all outgoing mail is
   relayed by an ISP MTA acting as a relay, e.g. mail.telia.com,
   totally unrelated to vanity.org.

   If this user subscribes to a mailinglist, the mecahnism for
   automatic key setup will fail.

3. Communication between MTA and MUA. Current plan is that the MTA
   inserts a header analogous to the Received:-header, saying which
   authentication have been used. The MTA should also have a
   control-address, which users and MUA:s can use for configuring the
   MTA. These control messages need some kind of authentication.

4. The hash cash protocol probably needs a way that lets a client MTA
   disconnect, solves the challenge off-line, and reconnect and
   provide the answer later. Perhaps we can use confirmation emails,
   analogous to those used by mailing list software.

   In general, it's preferable that the MUA and MTA communicate by
   email, rather than by SMTP or by some other protocol directly on
   top of TCP.

Regards,
/Niels