Is it still "wrong" to require STARTTLS on incoming SMTP messages
Solution 1:
Yes, it is still a bad idea.
Three reasons:
-
While the RFC you cited (RFC 2487) is in fact obsoleted by the current standard RFC 3207, the current standard keeps the MUST NOT verbiage you quoted in your question.
-
SMTP Clients are not required to implement STARTTLS. It is totally acceptable not to do so. While STARTTLS is becoming more common, it is absolutely not universal.
-
As a result of reasons 1 and 2, if you require STARTTLS on all incoming connections you will lose mail.
However:
Your server - your rules. If you want to arbitrarily reject any mail for any reason, or even no reason - that is your right and privilege. (does not mean that it is necessarily a great idea however)
Side notes:
You wont prevent spam by requiring STARTTLS, even if you require mutual STARTTLS authentication. Spammers can get certificates too - or create self-signed ones. Rejecting self-signed client certs will also result in losing legitimate mail.
STARTTLS is point-to-point encryption. The connecting system can still read the contents of the email. If you want real privacy, you need something end-to-end, such as OpenPGP or S/MIME.
That said, STARTTLS does remove one possible avenue for interception or MITM and therefore it is still a good idea to use it when feasible, ie when the other side supports it too.
Solution 2:
Google maintains open statistics on their percentage of mail that is encrypted, both inbound and outbound. This information should be extremely useful to you in determining whether this is worth implementing:
http://www.google.com/transparencyreport/saferemail/