4 ms·
That is a clever idea but I think it'll still fail so long as email (SMTP) is a fire-and-forget architecture. As long as you have that asymmetry, your SNR is go
by kortex 4y ago
That is a clever idea but I think it'll still fail so long as email (SMTP) is a fire-and-forget architecture. As long as you have that asymmetry, your SNR is going to suck.
If it were a back-and-forth protocol, more like TCP, then you have way more options for congestion control, error reporting, load balancing, and the like. The server can choose to accept the incoming request, ask for more verification, or interrogate the client in various ways. This could be something just like DKIM / DMARC / SPF, or even something more exotic, like making the client do proof-of-work with difficulty tied to how suspicious that client is to the server, and also the delivery scope/scale. Or forcing the client to wait for ACK for valid delivery while slow-walking it.
This gets around some of the issues in cousin comments, with respect to punishing botnets and rewarding lawful players. Established, high-trust players pay no cost. Suspicious players can still get through, albeit with a tax (that should be trivial for low-volume personal MX, but expensive for high-volume spam). Furthermore, it's adaptable.
- Avamander 4y ago> If it were a back-and-forth protocol, more like TCP, then you have way more options for congestion control, error reporting, load balancing, and the like. The server can choose to accept the incoming request, ask for more verification, or interrogate the client in various ways. That's basically what graylisting aims to achieve.
- kortex 4y agoYeah, this is essentially a form of greylisting. The difference is (as I understand it, this is fairly outside my domain), with the current setup, MTAs can accept an email, and it ends up getting blackhole'd or spam-folder'd anyways. My hypothetical scheme would put more onus on the first "boundary node" to report on errors/compliance. Basically the MTA tells the client what hoops to jump through, and the client gets some indication what will happen once those conditions are met. That could be an exchange like: "Sign this nonce, and your message will be vetted", or "this is very suss, you have to do X difficulty hashes to have any chance of delivery, and regardless it'll be flagged as potential spam". Or perhaps just a guarantee on how an action would affects the message's "spam score". This could be used alongside nested packets/envelopes and various headers/trust levels in a network of trust to give a message some overall trust level.