Hello all,

I read your draft, belated. I'm sure you have discussed and solved these issues already, but just for reference, below were my initial thoughts on the proposal.

I am not fully convinced by section 6 and 9.2, in particular: that it is impossible to abuse the MAC key management scheme. If a spammer can somehow fool you into talking to them, it seem the scheme is ruined. There may be subtle technical issues here. There may even be non-technical concerns with the approach; i.e., merely because you talk to someone doesn't mean you want them to talk to you.

If the idea and server implementation mature, I can probably be fooled into implementing some basic support for this in Emacs' smtpmail.el.

Thanks.

Secondary mail servers ----------------------

There is no discussion how primary and secondary MX's interact, if they do at all. If they are intended to interact, I believe that may be a serious deployment issue. My experience is that secondaries cannot be assumed to have useful out of band communication with the primaries. Inventing and deploying a protocol to keep some information synchronized between MX's appear to me complicated. One of nice properties of the mail system design is that different MX's for a domain can be separated to a big extent, making them interact more closely seem like an unwanted direction. To illustrate the degree of separation between MX's: some secondaries may not even know the complete list of which domains they are secondaries for (see sendmail FEATURE(`relay_based_on_MX')).

If however the MX's for a domain are not intended to interact, I guess I do not understand how the secret key authentication is going to work. As far as I understand, the keys are stored in a database indexed on SMTP envelope addresses corresponding to recipient and receiver. Consider then a client that is sending mail to user@domain via mail1.domain and mail2.domain. Which keys are used, and how are they negotiated?

One idea: Instead, have the keys be shared between two MTA's, and index the database on MTA names. MTA "A" share a key with MTA "B". Since MTAs can be known under many names, the canonical name should be used, i.e., the <Domain> field of the 220 initial response.

Note that policy matters, such as one disabling the use of MAC keys per-user, is still possible with this approach, as far as I can tell.

Input to MAC computation ------------------------

The draft says:

If a key is found, it is used to form a MAC on data consisting of sender and receiver id (in that order), selected headers, and the message body. The header lines included are From, To, Cc, Date, Content-type and Message-id. They are followed by an empty line, and then the message body, without transport encoding (to allow MTA's to change the transport encoding of messages in transit). The resulting MAC is provided to the receiver during the SMTP transaction.

What do you mean by "transport encoding"? MIME Content-Type-Encoding? If so, that appear to require a MIME decoder in the MTA, which is complex. Further, decoding a large e-mail may require large amounts of storage. Not all MIME libraries are written to make one-pass MAC computation easy.

Finally, the format of decoded MIME objects is not well defined, which seem to be required for MAC computations. Only the MIME encoding is well defined.

One idea: Do the MAC on the data that is actually sent on the wire.

Security properties of the MAC ------------------------------

There should be a security section on the highly specialized property required from the MAC: that it is computationally infeasible to produce a prefix MAC value with given value. As far as I am aware, existing MACs are not designed for this property. I suspect this property may collapse into more well known MAC properties. It would be neat if there was a nice reduction from this special property into more well studied properties. I.e., "if you can break the MAC for this property, you can break the same MAC for common MAC properties".

Btw, what kind of MAC's are you thinking of? HMAC-SHA1 may be the simplest choice, even though I would prefer something based on a block cipher. The choice of MAC seem critical to get "fair" computation costs, i.e., it should be difficult to optimize the MAC much more compared to typical implementations.

MUA discussions ---------------

In an ideal world, MUAs don't talk to MTAs, they talk to MSAs. See RRC 2476. There may be some consequences for how the MUA discussions are phrased. One might even consider introducing special protocol elements for MUA<->MSA, to specify policy matters. I'm not sure that is a good idea, though.