It has been a little while, so I thought it might be appropriate to give the WG an update on the status of REQUIRETLS (draft-fenton-smtp-require-tls-02).
There are now two prototype implementations: - Exim implementation by Jeremy Harris (announced on UTA list on 2 September) - MDaemon implementation by Arvel Hathcock (I'm not counting John Levine's implementation he described in Buenos Aires, because he seems to have missed quite a few MUSTs in the specification.) At this point, Jeremy and I are running test MTAs with the Exim implementation and Arvel is running one with the MDaemon implementation. A little interoperability testing has taken place. What we have learned so far: - Some ambiguity about when the REQUIRETLS extension should be advertised. The draft had assumed that it would be advertised on any EHLO response, even before STARTTLS had occurred. Jeremy points out that the advertised extensions mean that the server is prepared to support those facilities while in its current state, and STARTTLS needs to be done in order to support REQUIRETLS. On the other hand, I thought it useful to advertise REQUIRETLS all the time, since it allows a sending MTA to determine whether it's supported before going to the trouble of setting up TLS. - Loss of DSNs if the sending MTA has a problem with its (incoming) TLS certificate (or a self-signed cert), since the DSN is also sent with REQUIRETLS. These DSNs currently get stuck in the system until they time out. One approach (trying not to spill much metadata) might be to send the non-delivery notice only to the postmaster, and include very little information about the message -- perhaps just a message-id (which I would hope to be opaque, but probably often isn't in practice). - Lack of clarity on what the must-implement pieces of the spec are. I expect that many implementations that don't currently do anything with DANE (or potentially DNSSEC) might have quite a hurdle implementing the DANE piece of REQUIRETLS, but still be interested in implementing CHAIN. I'm in favor of making DANE a should-implement, but not a must-implement. Others have suggested removing the certificate verification option from the spec entirely, but I haven't seen much consensus to do that. I'm expecting to update the spec early next year to address these issues and a few that were on the list earlier. If anyone else has an implementation or is interested in running another instance of the other ones, please let me know and we can trade information on our test MTAs. -Jim _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
