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