Talk:Backscatter (email)/Archives/2020
 | This is an archive of past discussions about Backscatter (email). Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Dropping queued messages
The introduction says, "The best thing to do in this case, is to silently drop the message, rather than risk creating backscatter," in relation to scanning email after being accepted. This seems like a personal opinion and risks deleting legitimate email without any notice. Better would be to verify SPF and/or DKIM signatures and then bounce passing messages and to quarantine the messages that can't be verified. Further, RFC 5321 is quoted later in the article, which is sensible: "RFC 5321 says: 'silent dropping of messages should be considered only in those cases where there is very high confidence that the messages are seriously fraudulent or otherwise inappropriate.'" Dsm (talk) 01:15, 6 February 2020 (UTC)
I agree that verifying SPF/DKIM is a good idea to create legitimate bounces. However, in case that isn't possible for some reason, or the sender doesn't have SPF/DKIM configured, the better idea in that case is silently dropping if you are sure the message is unwanted. In many cases, mail is DKIM signed from a different domain than its return path, which also makes it unsuitable to create a bounce.
Of course, quarantine/spam folder is better if the status of the email is unsure, for example if the scanning algoritm is based on some "heuristics" or weighting. But for flat out virus infected emails, or confirmed spam, you can just toss the email into /dev/null without asking. Then you avoid bothering both the sender and receiver. Sebastiannielsen (talk) 23:52, 9 May 2020 (UTC)