3 ms·

End-to-end encryption does not invalidate most existing anti-spam technologies. However, these technologies will need to run after decrypting the content, which

by jcrites 12y ago

End-to-end encryption does not invalidate most existing anti-spam technologies. However, these technologies will need to run after decrypting the content, which may mean on the end user's machine(s). Less processing horsepower will be available than with server-side techniques, but the same techniques can still apply. If your mobile device and desktop PC both possess your decryption key, then your desktop PC could act as the anti-spam engine and transmit a list of good messages to your mobile device. A bigger problem would be ISPs who wish to keep their anti-spam techniques confidential and evaluate them only on their own servers. Allowing the end-users to download the scanning logic and run it locally would create a risk of divulging their proprietary techniques. The ability to keep software truly confidential and under its creator's control is one of the motivating factors behind the rise of software as a service. Whitelisting can also go a long way toward allowing only preapproved authorized senders to communicate with you using end-to-end encryption. The remaining senders might communicate with messages that are encrypted to your ISP instead. The DIME protocol anticipates this sort of layered encryption: https://news.ycombinator.com/item?id=8816806 https://news.ycombinator.com/item?id=8816806 When someone wishes to communicate with you using end-to-end encryption, they might first send an "introduction" message encrypted to your ISP, which can be scanned. Then the receiver can decide to authorize the sender for E2E or not.

dredmorbius 12y ago
The thing about post-receipt decryption is that: ⚫ It's expensive. Far cheaper to block in TCP or SMTP sessions. ⚫ If you cannot make and SMTP-time determination, you're going to end up with a nondelivery status message rather than an SMTP bounce. If you remember the days when these were common, the principle problem is joe-jobbing users with spoofed sender addresses. One option is not to send the NDS, which means that email becomes less reliable (than it already is). ⚫ TCP/SMTP time adjudication means you can leverage information in realtime. Waiting until keys are available means that the spammer has more time to spam before being detected (and possibly reported to spam-detection systems). ⚫ Receiver needs to spool potentially large volumes of spam. None of these are killers, but they do change the game. I'm leaning toward systems with 1) pervasive whitelisting, or 2) hold-and-notify, or 3) ticket-based permissions. Several of these would require extensions to or replacement of bits of present SMTP. Pervasive whitelisting means that you've got an approved sender list, and non-whitelisted mail is either rejected or deferred. Deferral might well be sufficient to avert much spam. Hold-and-notify would be a radical change. A system sending mail would effectively poll receiving servers "hey, I've got a message for you" (possibly with metadata), and the _receiving_ system would then poll the sender to fetch the message. This allows receiving systems to pre-fetch any verification / validation data it needs to assess message quality. It also puts the burden on the sending system to both 1) hold outgoing messages for retrieval and 2) persist online (many spam boxes are booted fairly quickly). As a bonus, nondelivery will be easier to assess (if your message isn't requested, it's not delivered). I don't see this being compatible with SMTP at all. Ticket-based permissions would require a sending system to request a ticket -- essentially an allowance to be able to deliver mail -- from the receiving host. It's a form of host-based whitelisting. This allows receiving hosts to allocate specific access levels / quality of service to specific hosts. Tickets could (and likely should) be PKI-based (to prevent forging / transfer), and would allow for a specified number of messages to be delivered within a given timeframe, after which a new ticket would have to be requested. No tickey, no laundry. This sounds in principle similar to DIME. Other concepts include wrapping or encrypting various parts of a message to different levels. Headers could be encrypted to the MX key of the receiving host, so that they would not be readable except to the server (and ultimate recipient). This is effectively what SSL accomplishes, though in a live-on-the-wire rather than static encryption model.
- dllthomas 12y ago
  It makes receiving more expensive, but it also makes sending more expensive, and it's the people doing so in bulk that are going to feel that the hardest. I don't see how this makes things worse.

by jcrites 12y ago

dredmorbius 12y ago

The thing about post-receipt decryption is that: ⚫ It's expensive. Far cheaper to block in TCP or SMTP sessions. ⚫ If you cannot make and SMTP-time determination, you're going to end up with a nondelivery status message rather than an SMTP bounce. If you remember the days when these were common, the principle problem is joe-jobbing users with spoofed sender addresses. One option is not to send the NDS, which means that email becomes less reliable (than it already is). ⚫ TCP/SMTP time adjudication means you can leverage information in realtime. Waiting until keys are available means that the spammer has more time to spam before being detected (and possibly reported to spam-detection systems). ⚫ Receiver needs to spool potentially large volumes of spam. None of these are killers, but they do change the game. I'm leaning toward systems with 1) pervasive whitelisting, or 2) hold-and-notify, or 3) ticket-based permissions. Several of these would require extensions to or replacement of bits of present SMTP. Pervasive whitelisting means that you've got an approved sender list, and non-whitelisted mail is either rejected or deferred. Deferral might well be sufficient to avert much spam. Hold-and-notify would be a radical change. A system sending mail would effectively poll receiving servers "hey, I've got a message for you" (possibly with metadata), and the _receiving_ system would then poll the sender to fetch the message. This allows receiving systems to pre-fetch any verification / validation data it needs to assess message quality. It also puts the burden on the sending system to both 1) hold outgoing messages for retrieval and 2) persist online (many spam boxes are booted fairly quickly). As a bonus, nondelivery will be easier to assess (if your message isn't requested, it's not delivered). I don't see this being compatible with SMTP at all. Ticket-based permissions would require a sending system to request a ticket -- essentially an allowance to be able to deliver mail -- from the receiving host. It's a form of host-based whitelisting. This allows receiving hosts to allocate specific access levels / quality of service to specific hosts. Tickets could (and likely should) be PKI-based (to prevent forging / transfer), and would allow for a specified number of messages to be delivered within a given timeframe, after which a new ticket would have to be requested. No tickey, no laundry. This sounds in principle similar to DIME. Other concepts include wrapping or encrypting various parts of a message to different levels. Headers could be encrypted to the MX key of the receiving host, so that they would not be readable except to the server (and ultimate recipient). This is effectively what SSL accomplishes, though in a live-on-the-wire rather than static encryption model.

dllthomas 12y ago
It makes receiving more expensive, but it also makes sending more expensive, and it's the people doing so in bulk that are going to feel that the hardest. I don't see how this makes things worse.