3 ms·

It's drastic enough not to be realistic, it would break mail for too many people, who would blame it on Gmail. What the big sites can do is add a delay when re

It's drastic enough not to be realistic, it would break mail for too many people, who would blame it on Gmail. What the big sites can do is add a delay when receiving from a plaintext relay, in a manner similar to greylisting and tarpiting that are widely deployed. The mail is not rejected, just delayed. The delay can be proportional to the amount of mail sent by a domain, and set to increase in time. The same can be done for outgoing mail to domains that don't advertise STARTTLS, drop the connection and retry later. In the first phase, just issue a warning then drop the first submission attempt, to fillup the logs with a clear message that STARTTLS is strongly preferred. Gradually increase the delay so that large sites have trouble emptying their queue, and continue to increase the delay until the last holdouts can be simply shut out. The advantage with this approach is that the user of Gmail, Yahoo etc. does not see a problem with his account, while the smaller sites and users will have delays when sending mail and receiving mail and be forced to take action.

CapacitorSet 9y ago
I'm pretty sure users would also blame delays on the receiving provider, not the sender (and they wouldn't be wrong, technically). I can picture a user saying "Oh, sometimes it takes ages for mail to arrive to my Gmail address, please send that document to username@<minor provider which doesn't delay mail>".
- cornholio 9y ago
  The key here is to have an implementation schedule crafted so there is a massive differential impact on a selected group of small providers and a negligible impact on overall performance. After issuing warnings for a few months, put a cap on the number of plain-text submissions per domain, large enough to affect just the worldwide top 5-10 domains in that group. As more domains comply, roll that window, so as to keep just a very small fraction of total mail volume delayed, both incoming and outgoing. Since mail delays are common, the risk of switching by your own customers is low, and special exceptions can be made for accounts that communicate with an affected domain often. It's essential that the major email domains work together so that the users of small non-encrypting domains feel a generalized performance impact, not just a problem with Gmail or just Yahoo.

CapacitorSet 9y ago

I'm pretty sure users would also blame delays on the receiving provider, not the sender (and they wouldn't be wrong, technically). I can picture a user saying "Oh, sometimes it takes ages for mail to arrive to my Gmail address, please send that document to username@<minor provider which doesn't delay mail>".

cornholio 9y ago
The key here is to have an implementation schedule crafted so there is a massive differential impact on a selected group of small providers and a negligible impact on overall performance. After issuing warnings for a few months, put a cap on the number of plain-text submissions per domain, large enough to affect just the worldwide top 5-10 domains in that group. As more domains comply, roll that window, so as to keep just a very small fraction of total mail volume delayed, both incoming and outgoing. Since mail delays are common, the risk of switching by your own customers is low, and special exceptions can be made for accounts that communicate with an affected domain often. It's essential that the major email domains work together so that the users of small non-encrypting domains feel a generalized performance impact, not just a problem with Gmail or just Yahoo.