Trouble with tblbl_emailsto rejections |
Post Reply |
Author | |
dotme
Newbie Joined: 27 October 2008 Status: Offline Points: 20 |
Post Options
Thanks(0)
Posted: 03 June 2009 at 3:37pm |
We manage a fair number of domains, and implemented some user detection so we don't quarantine email for users that do not exist on the destination server.
By doing this, our customers do not have to create a new user on logsat any time they add a user to their mailserver. Our system therefore doesn't use the tblwl_authorizedtoemails table.
Instead, we put invalid users in the tblbl_emailsto list.
So far, so good. But today, we had a sender who sent an email to nine users on the domain, one of which was in the tblbl_emailsto list.
Spamfilter rejected the entire list, so the sender received an NDR stating none of the recipients were valid. And the email was rejected.
Logfile....
06/03/09 10:33:34:375 -- (1792) Received MAIL FROM: <store4906@senderdomain>
06/03/09 10:33:34:422 -- (1792) Received RCPT TO: charityr@example.com 06/03/09 10:33:37:203 -- (1792) Resolving 1.2.3.4 - cmsout01.mbox.net 06/03/09 10:33:43:265 -- (1792) - SPF analysis for senderdomain done: - none 06/03/09 10:33:43:265 -- (1792) Mail from: store4906@senderdomain 06/03/09 10:34:13:203 -- (1792) - MAPS search done... 06/03/09 10:34:13:203 -- (1792) RCPT TO: charityr@example.com accepted 06/03/09 10:34:13:234 -- (1792) Received RCPT TO: davidf@example.com 06/03/09 10:34:13:234 -- (1792) Mail from: store4906@senderdomain 06/03/09 10:34:13:234 -- (1792) RCPT TO: davidf@example.com accepted 06/03/09 10:34:13:281 -- (1792) Received RCPT TO: debbiew@example.com 06/03/09 10:34:13:281 -- (1792) Mail from: store4906@senderdomain 06/03/09 10:34:13:281 -- (1792) RCPT TO: debbiew@example.com accepted 06/03/09 10:34:13:328 -- (1792) Received RCPT TO: ellenr@example.com 06/03/09 10:34:13:328 -- (1792) Mail from: store4906@senderdomain 06/03/09 10:34:13:328 -- (1792) RCPT TO: ellenr@example.com accepted 06/03/09 10:34:13:375 -- (1792) Received RCPT TO: erink@example.com 06/03/09 10:34:13:375 -- (1792) Mail from: store4906@senderdomain 06/03/09 10:34:13:375 -- (1792) RCPT TO: erink@example.com accepted 06/03/09 10:34:13:422 -- (1792) Received RCPT TO: jessm@example.com 06/03/09 10:34:13:422 -- (1792) - EmailTO is in local blacklist file... 06/03/09 10:34:13:422 -- (1792) 1.2.3.4 - Mail from: store4906@senderdomain To: jessm@example.com will be rejected 06/03/09 10:34:13:453 -- (1792) Received RCPT TO: joanns@example.com 06/03/09 10:34:13:468 -- (1792) Mail from: store4906@senderdomain 06/03/09 10:34:13:468 -- (1792) 1.2.3.4 - Mail from: store4906@senderdomain To: joanns@example.com will be rejected 06/03/09 10:34:13:500 -- (1792) Received RCPT TO: katiec@example.com 06/03/09 10:34:13:500 -- (1792) Mail from: store4906@senderdomain 06/03/09 10:34:13:500 -- (1792) 1.2.3.4 - Mail from: store4906@senderdomain To: katiec@example.com will be rejected 06/03/09 10:34:13:547 -- (1792) Received RCPT TO: kimb@example.com 06/03/09 10:34:13:547 -- (1792) Mail from: store4906@senderdomain 06/03/09 10:34:13:547 -- (1792) 1.2.3.4 - Mail from: store4906@senderdomain To: kimb@example.com will be rejected 06/03/09 10:34:13:593 -- (1792) Received RCPT TO: rondat@example.com 06/03/09 10:34:13:593 -- (1792) Mail from: store4906@senderdomain 06/03/09 10:34:13:593 -- (1792) 1.2.3.4 - Mail from: store4906@senderdomain To: rondat@example.com will be rejected 06/03/09 10:34:13:953 -- (1792) Start virus scan 06/03/09 10:34:13:984 -- (1792) Starting bayesian procedures 06/03/09 10:34:14:062 -- (1792) Blacklist cache - Added 1.2.3.4 to limbo 06/03/09 10:34:14:218 -- (1792) SFDB - Added 1.2.3.4 - Response: Error=0 06/03/09 10:34:14:218 -- (1792) Disconnect Does Logsat not have the granularity to deliver / process the message and simply NDR the single invalid recipient?
Being able to have a list of invalid recipients drastically reduces our Quarantine tables, which is great for performance. So I'd really like to be able to keep that methodology.
I'm just surprised that one bad user (jessm) prevented all the legitimate recipients from receiving the email...
Any tips/help greatly appreciated. Thanks! Edited by dotme - 03 June 2009 at 3:53pm |
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
dotme,
The granularity you're looking for is present in the "Authorized TO" email whitelist. This list is used to specify the list of valid users on the system, and administrators can then choose if they want to drop the entire connection when attempts are made to deliver emails to users not in that list, or if SpamFilter should just reject the one non-existent recipient and continue accepting the others. In your case, you're using the local emailTO blacklist to obtain the reverse of the above functionality. SpamFilter was designed so that all the blacklist are used to identify emails as spam. If any one of these blacklsits triggers a match, then the email is flagged as spam and is thus blocked. So if a recipient in the email matches an entry in the emailTO blacklist, this will indeed flag the entire email as spam, and the email will be 100% blocked. There are no workarounds for this, sorry, as this is just how SpamFilter is supposed to behave. |
|
dotme
Newbie Joined: 27 October 2008 Status: Offline Points: 20 |
Post Options
Thanks(0)
|
Fair enough. Feature request :-) It's a lot easier to detect invalid accounts than to guess valid ones. We were trying to get the best of both worlds, by not forcing our clients to enter every user yet still not quarantine email for "known invalids"The tblbl_emailsto and tblbl_honeypotemails seem to accomplish the same thing as each other today.
Maybe down the road, something to consider as an enhancement... Thanks!
|
|
Post Reply | |
Tweet
|
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |
This page was generated in 0.234 seconds.