Mail Queues and Spam

H

haywardweb

Verified User
Joined
Jan 12, 2005
Messages
21
Location
WA
I've been a Linux administrator for years, but am new to MTAs, especially Exim.

I have a new DirectAdmin server and am seeing lots of spam messages in the mail queue (104 right now for 50 email accounts). The messages are from randomized spam addresses and addressed to my users. What causes messages to get left in the queue? Is spam there cause for alarm?

I noticed one of my domains has between 100-400 messages per day in the Sent Email bandwidth column of DA. This seems odd to me. How do I track down the source (what/where, specifically, does DA measure?)?

I can provide output from eximstats, etc., if that would be helpful.

Thanks.
 
First, those emails in your queue... are they direct spam email addressed to your users? If so, then do your users have room in their mailboxes? Have you checked to see if exim is running queue-runners? Have you tried starting any queue-runners? Mails addressed to your users should be delivered to them.

Second, if email is showing up in the sent email bandwidth, it should be leaving tracks in your exim mainlog. Grep the log for the username owning the domain.

Jeff
 
Hi Jeff,

Thanks for your response; sorry it took me so long to look in to it.

I did some searching with the new vocab you used "queue-runners". This was very helpful.

It looks like I am having multiple problems:

The mail that stays in the queue is caused by the odd From header (http://www.directadmin.com/forum/showthread.php?p=135986). I will be upgrading Exim to avoid this.

I was having problems with outgoing mail being delayed. It seems the queue got backlogged from a mailing list and didn't retry frequently enough. I changed my retry line to this, hoping it will help:
begin retry
* * F,10m,1m; F,2h,15m; G,16h,1h,1.5; F,4d,8h

I still have not looked too deep into the high mail volume from one of my customers. I think he may just get a lot of spam to one of his forwarding addresses. I set up Spamassassin to minimize the problem.
 
Please let us know how your retry settings work; On our servers we no longer retry email for four days. Even though it's been standard for so many years, on today's internet connectivity is much better and if email isn't delivered in a day or two it's generally undeliverable.

Jeff
 
Thanks for pointing that out. The only settings I modified were for the first 10 minutes. I'll cut the last setting down to 1 day--that seems much more reasonable.
 
Note that doing so may put you at odds with one or more RFCs. Nevertheless I recommend no more than two days.

Jeff
 
You must log in or register to reply here.
Back
Top