Its becoming more apparent in my recent experience that the current exim.conf template used by directadmin (accept and scan) needs modifying to update to todays climate.
In the past bouncing emails in situations when a mail box is full or if the account doesnt exist was fine but now it isnt and it is instead now reccomended practice to reject such emails prior to the email been accepted by the recieving server. This avoids backscatter scenarios where you bouncing back spam to non existant addresses.
The default directadmin config can cause the server to be blacklisted in places like CBL who will list servers that backscatter spam.
I have been trying various ways to reliably prevent outgoing spam bounces but its proving diffilcult. The ultimate solution would certianly be to reject email to full/nonexistant boxes before its even scanned and accepted but this isnt easy in exim as I see on the exim mailing lists the developer wasnt cooperative and the proposed solutions not very compatible with the DA setup.
What I have done so far is configured a system_filter file that checks for the following on outgoing emails.
It checks if the email is initiated by localhost (the case for bounces)
It checks for spam headers that get created by spamassassin for spam such as ***SPAM*** subject and X-Spam-Flag: YES.
It checks for the term 'mailbox is full' in the message body.
This will block outgoing mail that has been marked as spam by spamassassin and any bounces that are as a result of a full mailbox. This isnt a reccomended practice tho since a genuine sender has no indication of a problem on failed delivery. However I feel its superior to bouncing spam.
In addition I also mark any outgoing email with a new unique key in the headers, any mail recieved with the from address that matches a domain on the server will be checked for this key, if the key doesnt exist the email is rejected. This prevents incoming spam that appears to come from yourself (backscattered spoofed).
If anyone has successfully done what I am trying to achieve it would be good if can respond here thanks, also any thoughts from you Jeff on this.
In the past bouncing emails in situations when a mail box is full or if the account doesnt exist was fine but now it isnt and it is instead now reccomended practice to reject such emails prior to the email been accepted by the recieving server. This avoids backscatter scenarios where you bouncing back spam to non existant addresses.
The default directadmin config can cause the server to be blacklisted in places like CBL who will list servers that backscatter spam.
I have been trying various ways to reliably prevent outgoing spam bounces but its proving diffilcult. The ultimate solution would certianly be to reject email to full/nonexistant boxes before its even scanned and accepted but this isnt easy in exim as I see on the exim mailing lists the developer wasnt cooperative and the proposed solutions not very compatible with the DA setup.
What I have done so far is configured a system_filter file that checks for the following on outgoing emails.
It checks if the email is initiated by localhost (the case for bounces)
It checks for spam headers that get created by spamassassin for spam such as ***SPAM*** subject and X-Spam-Flag: YES.
It checks for the term 'mailbox is full' in the message body.
This will block outgoing mail that has been marked as spam by spamassassin and any bounces that are as a result of a full mailbox. This isnt a reccomended practice tho since a genuine sender has no indication of a problem on failed delivery. However I feel its superior to bouncing spam.
In addition I also mark any outgoing email with a new unique key in the headers, any mail recieved with the from address that matches a domain on the server will be checked for this key, if the key doesnt exist the email is rejected. This prevents incoming spam that appears to come from yourself (backscattered spoofed).
If anyone has successfully done what I am trying to achieve it would be good if can respond here thanks, also any thoughts from you Jeff on this.
