Improvement to RT_AUTHRELAY_ALERT for spam detection
Posted: 25 Apr 2013, 21:15
Currently it appears that RT_AUTHRELAY_ALERT is tracking relayed emails by IP address.
However, most of the time when large amounts of email are coming through, it is due to spammers compromising a user account and sending from many different IP addresses. Because of the multiple IP addresses, RT_AUTHRELAY_LIMIT rarely ever gets exceeded and lots of spam gets through unnoticed.
What would be nice is if the tracking key for RT_AUTHRELAY used the smtp authentication id (found in the Exim log line in the A= section). That way, no matter how many IP addresses were sending the emails, they would all get counted towards the RT_AUTHRELAY_LIMIT.
Obviously CSF wouldnt be able to block the user account, but it would at least send the alerts.
Maybe a boolean option called RT_AUTHRELAY_ACCOUNT that tracks by user instead of IP? Or perhaps changing it altogether to use username?
Right now, this is the single biggest recurring problem we have that I wish csf could handle.
However, most of the time when large amounts of email are coming through, it is due to spammers compromising a user account and sending from many different IP addresses. Because of the multiple IP addresses, RT_AUTHRELAY_LIMIT rarely ever gets exceeded and lots of spam gets through unnoticed.
What would be nice is if the tracking key for RT_AUTHRELAY used the smtp authentication id (found in the Exim log line in the A= section). That way, no matter how many IP addresses were sending the emails, they would all get counted towards the RT_AUTHRELAY_LIMIT.
Obviously CSF wouldnt be able to block the user account, but it would at least send the alerts.
Maybe a boolean option called RT_AUTHRELAY_ACCOUNT that tracks by user instead of IP? Or perhaps changing it altogether to use username?
Right now, this is the single biggest recurring problem we have that I wish csf could handle.