On Mon, May 20, 2019 at 2:29 AM Steve Atkins via mailop <[email protected]> wrote:
> > > > On May 20, 2019, at 10:17 AM, Brent Clark via mailop <[email protected]> > wrote: > > > > Good day Guys > > > > Just want to check with the community. > > > > My colleague has proposed that at smtp time, if a mail is deemed as > spam, the server issues a reject code, but then to too accept the mail and > forward the mail the user for incase its a false positive. > > > > His logic is that, that the spammer does not build up a database. > > Rejecting at the end of data will prevent spammers^W entirely legitimate > list cleansing services from building databases about as effectively. > > > Currently what we do is, if the score is between 5 and 15, just accept > and move the spam to the users SPAM box. Above 15 we out right block. > > Telling the recipient one thing and the sender another about whether an > email was delivered is likely to cause you problems with legitimate > senders, while being mostly irrelevant to bad actors. > > Consider what mailing lists will do in response to this, and what your > user will see happen, as one example. > I know of some folks who do this with grey listing, and store those messages separately. This allows them to handle things like verification and forgot password emails better, for instance. In the same vein, I would think if you did let this mail in, it should be marked in some way so your users know what happened. Another option would be to implement sampling, where you allow some percentage of mail in that you would block at smtp time (maybe per rule or per some other factor) in order to get false positive feedback on the rules. Obviously, this takes a bunch of infrastructure and enough volume to justify it. One warning, some spammers, especially those happy enough just to reach the spam folder, will try to game the sampling as well by increasing volume, so usually you need to cap your sampling both by percentage and by absolute number (or scale the percentage down as the volume increases) Brandon
_______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
