Vincent Lefevre <vinc...@vinc17.net> writes: > On 2022-08-13 14:05:43 -0400, joe a wrote: >> On 8/13/2022 12:38 PM, Martin Gregorie wrote: >> . . . >> > 2) There's no mandatory need to REJECT spam. It has always been up to >> > the recipient to decide whether to return it to the sender or not. >> >> Agreed in part. I see returning SPAM to sender as an exercise in futility >> or perhaps further enabling. But I do prefer labeling as SPAM to outright >> rejection in many cases.
Be careful in "returning". There is replying with 550 and not accepting it, which ensures that *you* are not generating backscatter, and there is sending a bounce later. I think that if you're going to reject it, you should 550 it. > Rejecting mail (instead of accepting it and dropping it) is useful > in case of false positives. This is a key point. A lot of mail ends up in spam folders that are so full they don't get looked at, at a number of ISPs that have a poor email recipient experience. I know people at AOL/Yahoo/Verizon and Comcast that have mail end up in spam and in practice do not cope with looking at it. (Further, this mail is wrongly classified, and people can't in practice fix that.) By rejecting spam with 550, it doesn't end up in the spam folder, and that folder becomes easier to scan. And if legit mail is rejected, at least the sender knows it didn't get there, even if the ISP is intractable. If you accept mail and then send it to /dev/null, then the recipient is unaware that it was sent, and the sender is unaware that it wasn't received, other than by implementing a human-human ack protocol. So I'm a firm believer that at SMTP time, you need to pick one of 550 and you're done accept and then sort into ham mailboxes and spam mailboxes, with the idea that the user should be checking all of them By choosing 550 you can turn up the aggressiveness of checking a bit compared to if you don't.
signature.asc
Description: PGP signature
