Topic: Mail Delivery Delay with SpamAssassin and ClamAV?!

[sgt-spam]

Hi.

I'm using Jesper's Clam & Spam scripts / installs...  Everything's going great, except a slight mail delivery delay.

Certain users have email forwarded to their cell phones (SMS) and home email addresses.  We've noticed the delay in mail being delivered those places and also to outside addresses in general.  This delay is anywhere from a few minuts to nine hours, which is a bit much when there's business sensitive material floating around.

I'm curious if anyone else has noticed a delay in outbound mail processing.


Thanks!

[sgt-spam]

Original searches didn't return much, but I did some more digging and found a possible hit:  The mail server attempting to send bounce messages to non-existent users/domains/etc could be clogging the outbound queue.

I configured the mail server to deliver messages to unknown users to the admin box rather than sending a bounce report.  Will give it a while and see if things speed up...

To get an of the amount of spam we're dealing with, check here.

All comments / suggestions welcome.

[raem]

sgt-spam

> The mail server attempting to send bounce messages to non-existent users/domains/etc could be clogging the outbound queue.

Installing this rpm from dungog.net will cause your system to automtically reject mail sent to invalid local addressess, rather than bouncing them back with the usual subsequent doublebounce message and resultant messages waiting for delivery in the mail queue.

dungog-mailblocking-1.0-3.noarch.rpm

[sgt-spam]

Thanks Ray.

I had previously done the short set of commands to drop double-bounce messages listed on Jesper's site as well, but this will help.

What I'm most concerned about is the outgoing queue.  When I go to http://www.abuse.net/relay.html and do the relay test I come back clean, yet I have a HUGE set of messages trying to send according to 'Mail file analysis > List outgoing messages / recipients' - here's a small snipit:

Code: [Select]


23 Sep 2004 13:30:56 GMT  #7063368  7153  <>
remote atzzdgxqocukl@ayna.com
23 Sep 2004 13:31:58 GMT  #7063414  8654  <>
remote ysjvtsm@gujaratimail.com
23 Sep 2004 13:34:25 GMT  #7063460  9286  <>
remote pghroxlh@eazier.com
23 Sep 2004 19:36:24 GMT  #7063552  7750  <>
remote cfqtmfokvqy@yahoo.com
23 Sep 2004 19:36:30 GMT  #7063575  7293  <>
remote tcbyuqnydx@yahoo.com
23 Sep 2004 14:00:09 GMT  #7064265  8467  <>
remote gglcgd@oriyamail.com
23 Sep 2004 14:00:23 GMT  #7064288  7880  <>
remote btxhzny@info66.com
23 Sep 2004 14:10:24 GMT  #7064794  8091  <>
remote leuftcdwhk@taiwandot.com
23 Sep 2004 14:15:05 GMT  #7064817  8501  <>
remote ckdet@pool.domainsite.com
23 Sep 2004 14:17:40 GMT  #7064863  8886  <>
remote hjyrejf@eazier.com


Using the previously mentioned contrib I created a rule to deny mail from *@* to <> and from <> to *@*, but I've not yet seen a decrease in activity.

[raem]

sgt-spam

> What I'm most concerned about is the outgoing queue

Look in /var/log/smtpfront-qmail/current to see who those messages are coming from. Perhaps you have a virus on one of the workstations generating lots of mail to fictitious addresses, which is sitting in the queue undeliverable.
Qmail will keep trying to deliver them for 7 days and then give up and delete them so they will disappear eventually without your intervention.

Note that the pattern matching contrib (G Rowell) will block incoming and outgoing messages with infected attachments thus stopping virus propagation. The more recent implementations of clamavis also scan outgoing (& incoming) messages.

You don't need to create any rules to reject incoming mail for invalid addresses, the mailblocking contrib automatically configures that functionality.
I'm not sure what you are trying to achieve with those particular rules you mentioned.

[sgt-spam]

I guess I thought I was filtering messages with <> as the sender with those additional rules.  I've removed them.

ClamAV is installed and seems to be doing a great job as I get hundreds of quarantine / problem email notices.  Those are removed after 10 days.

I'll give the mailblocking RPM a little time.  Guess I was expecting the outgoing queue to drop to basically nothing after installing / rebooting.

Most of what I'm seeing in /var/log/smtpfront-qmail/current is incoming mail, not outgoing.  I like the fact that I'm seeing messages with incorrect recipients getting dropped.  guess I'll have to keep an eye on the outbound queue over the next few days to see if it gets smaller...

I'll investigate the patern matching you mentioned.  Is there anything else I can do?


Thanks a lot.

[raem]

sgt-spam

> Is there anything else I can do?

Is clamav set to scan outgoing messages as well as incoming ?

I assume you have spamassassin installed with RBL configured or alternatively just have RBL blocking configured as per my HOWTO ?

[sgt-spam]

Absolutely.

Clam scans normal and secure mail both incoming and outgoing, and the following RBL's are in use: dsn.rfc-ignorant.org, list.dsbl.org, relays.ordb.org, sbl-xbl.spamhaus.org.

[sgt-spam]

Here's my small oversight:

Server was set up properly - ClamAV and SpamAssassin doing their jobs.  RBL was also configured (just one list).

We used to have an outside company filter our spam.  They would just forward it on to us after it had been scanned.  In an effort to test SpamAssassin and ClamAV, I disabled all scanners / cleaners, but the mail still came from THEM ultimately.  Mail slowdowns were because the RBL wasn't dropping ANYTHING (all the mail was coming from an OK / non-listed host).  That caused SpamAssassin to have to look at every single message in and out.

After I modified our DNS zones with the ISP and waited for that to propogate, I slowly started to see more of a variety of hosts coming up in /var/log/smtpfront-qmail/current meaning the smtpfront rules were actually getting used.

CPU utilization dropped like crazy, and the RBL is now dropping 89% of the crap we get on a daily basis.

Thanks for the help here!!

[nald]

I would like to ask how come my SME 6.0 will have a delay in sending e-mails.  I already have an anti-virus and spam filtering installed.  

Another problem that i encounter is that when i tried to send e-mail to yahoo.com using SME 6.0, my messages is sent to bulk or will be registered as spam.  I tried other domains and my e-mail messages will not be receive or it has a delay.

Is there any problem on my installation??? is it the spam filtering the cause of the delay or will be registered as spam???

pls help me on this problem..thanks

[nald]

sgt-spam, i would like to know if you are able to solve the problem on the delay of the oubound process???  Is your e-mail server right now is working well???  I would like to ask if our SME 6.0 is the real problem or its our domain name???  

Will you please send me some informations regarding on my problem which i encounter right now...thnks...

Here's my small oversight:

Server was set up properly - ClamAV and SpamAssassin doing their jobs.  RBL was also configured (just one list).

We used to have an outside company filter our spam.  They would just forward it on to us after it had been scanned.  In an effort to test SpamAssassin and ClamAV, I disabled all scanners / cleaners, but the mail still came from THEM ultimately.  Mail slowdowns were because the RBL wasn't dropping ANYTHING (all the mail was coming from an OK / non-listed host).  That caused SpamAssassin to have to look at every single message in and out.

After I modified our DNS zones with the ISP and waited for that to propogate, I slowly started to see more of a variety of hosts coming up in /var/log/smtpfront-qmail/current meaning the smtpfront rules were actually getting used.

CPU utilization dropped like crazy, and the RBL is now dropping 89% of the crap we get on a daily basis.

Thanks for the help here!!

[sgt-spam]

Hi.

The delivery (outbound) delay we experienced was due to the large number of messages our mail server was attempting to send.

The SpamAssassin, ClamAV, and RBL contribs all work properly and do their job extremely well (nice work Jesper!).

Until now, a third party was filtering our mail for spam and viruses.  That third party would then forward our mail to our mail server.  The mail server saw each and every one of those messages as legitimate because it was coming from a trusted source.  Therefore, the RBL did not drop any of the messages and SpamAssassin / ClamAV were stuck scanning thousands of messages per day.

By modifying our DNS zones to not include the service we were using, internet mail started coming directly to us rather than passing through our filter.  At this point the RBLs kicked in and started dropping messages from known spammers, CPU utilization went down because SA and ClamAV weren't handling so many messages, and outbound messages were delivered in an acceptable timely fashion because the queue wasn't full of bounce reports.

SME is working beautifully for us right now...


Does that answer your question?

[nald]

Do u have any idea what's the real problem of our e-mail server???  Is it our domain that we are using is the cause of the problem???  All our e-mails has a delay in sending and it will be sent into junkmail.

Please tell me if u have any suggestion on this particular problem. Thanks...