You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #771 we created a detailed blacklisting guideline which however is rather conservative especially when it comes to aggressive campaigns which repeatedly spam a large number of apparently unrelated domain names which are however part of the same coordinated attack.
To start the discussion, I would like to propose that we define "current campaigns", tentatively to something we can group as related over the last week or so, and for new spam incidents which belong to one of these current campaigns, lower the thresholds.
To review, the current thresholds are 5/5 for below auto and less than 6 months, falling back to 10/10 over a year, or 20/20 over a longer time.
For current campaigns, I would lower these thresholds to 3/3, 5/5, and 10/10.
We should also say something useful about x/y where y>x. This case is currently not covered, and casual reading would suggest "do not blacklist under any circumstances if there are false positives". That is arguably much too strict.
The text was updated successfully, but these errors were encountered:
In #771 we created a detailed blacklisting guideline which however is rather conservative especially when it comes to aggressive campaigns which repeatedly spam a large number of apparently unrelated domain names which are however part of the same coordinated attack.
To start the discussion, I would like to propose that we define "current campaigns", tentatively to something we can group as related over the last week or so, and for new spam incidents which belong to one of these current campaigns, lower the thresholds.
To review, the current thresholds are 5/5 for below auto and less than 6 months, falling back to 10/10 over a year, or 20/20 over a longer time.
For current campaigns, I would lower these thresholds to 3/3, 5/5, and 10/10.
We should also say something useful about x/y where y>x. This case is currently not covered, and casual reading would suggest "do not blacklist under any circumstances if there are false positives". That is arguably much too strict.
The text was updated successfully, but these errors were encountered: