• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 454
  • Last Modified:

Spam Problem


I think someone is using my system to send mass spam e-mails.

My server logs look like this for the past day or two:

Apr  3 15:06:29 postfix/smtp[2549]: 168383693: to=<kjonested@aol.com>, relay=mailin-01.mx.aol.com[], delay=141182, status=deferred (host mailin-01.mx.aol.com[] said: 421-:  (CON:B1)  http://postmaster.info.aol.com/errors/421conb1.html 421 SERVICE NOT AVAILABLE (in reply to end of DATA command))
Apr  3 15:08:56 postfix/smtp[4731]: 139EC398F: to=<bratzapattack@aol.com>, relay=mailin-04.mx.aol.com[], delay=48233, status=deferred (host mailin-04.mx.aol.com[] said: 421-:  (CON:B1)  http://postmaster.info.aol.com/errors/421conb1.html 421 SERVICE NOT AVAILABLE (in reply to end of DATA command))

And there are hundreds if not thousands of these entries...

How can I find out where this is happening? What userid etc. My server has a number of virtual hosts so I've found it difficult to pinpoint the problem. I've been able to identify one perl script that was being abused to send spam and I've already disabled it but it's still happening somewhere else from my server...

Thanks for your help! It would be greatly appreciated!

I have Debian Linux, Postfix and Procmail. My guess is that there's an unsafe php or perl script being abused...
Julian Matz
Julian Matz
3 Solutions
delete all the mails from the queue to see if the messages are still suck in there..

postsuper -d ALL

(note that ALL must be in captial letters)

perhaps you indeed caught it with the perl script, but the existing mails are still stuck in the queue.

Julian MatzAuthor Commented:
Hi Heem14,

That's brilliant!! I never even thought of that! Of course there were so many e-mails that the system could not cope so they ended up in the queue. Too many e-mails were being bounced:
postfix/bounce[13350]: fatal: lock file defer 1DF8D35BC: Resource temporarily unavailable

postsuper deleted 1255 messages so I expect that should be the end of that :)

Thanks a lot for your help! I greatly appreciate it!


In the postfix config file "main.cf" you can set what networks are allowed to send emails
from your mail server:

Here is a snip from the main.cf file:

# Specify "mynetworks_style = host" when Postfix should "trust"
# only the local machine.
#mynetworks_style = class
#mynetworks_style = subnet
#mynetworks_style = host

# Alternatively, you can specify the mynetworks list by hand, in
# which case Postfix ignores the mynetworks_style setting.
# Specify an explicit list of network/netmask patterns, where the
# mask specifies the number of bits in the network part of a host
# address.
# You can also specify the absolute pathname of a pattern file instead
# of listing the patterns here. Specify type:table for table-based lookups
# (the value on the table right-hand side is not used).
#mynetworks =,
#mynetworks = $config_directory/mynetworks
#mynetworks = hash:/etc/postfix/network_table

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Personally I'd error on the side of caution and believe this would happen again.  I'd recommend turning on super verbose logging for about one week.

There should be and smtp inet line in the master.cf config file (usually the first uncommented line) at the end of that line add "-v -v" to the smtpd
This will record pretty much everything happening involving smtp communication on the server.  So if this happens again you should be able to see exactly the email address the offender is using, the IP they are using, size of email, time span between attempts, etc.

Thru this you should have a better understanding of how it is happening and what your next step should be.
Julian MatzAuthor Commented:
Hi xDamox,
Thank you for your input. I appreciate it, but I don't really understand how your suggestion would help in my situation...

Hi Cyclops3590,
Yes, you're right, it could very well happen again. I do give my hosting clients a lot of 'freedom' and flexibility so it would just take one insecure script, so your input is very valuable also!! Thanks!

My master.cf line looks like this:
smtp      inet  n       -       -       -       -       smtpd

Just to be sure... This is what I should change it to: ?
smtp      inet  n       -       -       -       -       smtpd -v -v

yup that is the line I was talking about.  However, you want to keep in mind that this will increase the amount being logged by a LOT!!!
So I would check the size of your mail log file before you make the switch and watch it carefully for the first day or two.  If it gets out of control too quickly then I'd turn it off.  We don't want to fill the partition holding your logs by accident or syslog will shut down and you'll have a bigger problem on your hands because you'll need to delete saved historical logs to free up some space to restart syslog.  I accidentally did that on my server because I forgot to shut it off after I was done needing it.

Featured Post

Prep for the ITIL® Foundation Certification Exam

December’s Course of the Month is now available! Enroll to learn ITIL® Foundation best practices for delivering IT services effectively and efficiently.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now