Detecting Hackers or Spammers sending email through your system.
Finding the source/cause of a spam
Use the command
to find any account sending a lot of email note down the top 1-2
accounts, next open the web admin to the msg.rec log file page and
search for the problem accounts to confirm if what they are sending
is spam or not, if it's spam change the passwords.
or in web admin use Status
or Mail queue to
examine some messages
to find if there is a bunch of email stuck in the outgoing queue,
spam messages tend to get stuck so this may help you identify some
spam, then search the msg.rec logs again to find the Received log
entry to find why the spam message was recieved.
In some instances, the outgoing message is a bounce or other
internally generated message, in this case you need to find the log
entries just 'before' the message in question to find what caused
it, so search on the time hh:mm: to find the log entries that are
Search RBL databases for your servers ip address
Use one of the many rbl services to find if your system has been
listed, you will need the ip address of your server. If you are
listed, then go to the specific RBL website to see if it will give
you more information, some of them require you register first, read
the relevant RBL listing reasons carefully to understand why you may
have been listed. Then continue your search to identify and
fix the CAUSE before you request delisting!
Reading msg*.rec log entries.
Log entries for an incoming message look like this:
9 21:35:30 Rcpt 188.8.131.52 <firstname.lastname@example.org> <email@example.com> 0 ""
9 21:35:31 Received 184.108.40.206 firstname.lastname@example.org <email@example.com> 120395 <XJkzvvWDQXeUsz7INbIxGQ@ismtpd0003p1lon1.sendgrid.net> "Relay=islocal, nrcpt=1, f="Booking.com" <firstname.lastname@example.org>, s=[Chris - Whakapapa Village and Adelaide! There's a deal with your name on it!]"
9 21:35:32 Aspam 220.127.116.11 email@example.com <firstname.lastname@example.org> 120395 <XJkzvvWDQXeUsz7INbIxGQ@ismtpd0003p1lon1.sendgrid.net> "notrust *****: 5.8 sd=5.8 l=0.00 nok=2/0 m=2 nf=0 Close 0.05(X-SpamContent:clean) 0.95(X-myrbl:Color=brown) 0.91(isclickimage2) 0.82(isclickimage1) 0.20(X-Phrase:clean) 0.37(dkimok) 0.37(genuine) 0.60(spfpass) 0.46(X-NotAscii:utf) 0.53(X-LangGuess:English) 0.49(X-Verify-Helo:+OK) SanScore 0.0 5.8 Sval 5.8"
9 21:35:32.00  Spam 18.104.22.168 <email@example.com> <firstname.lastname@example.org> 120395 <XJkzvvWDQXeUsz7INbIxGQ@ismtpd0003p1lon1.sendgrid.net> "[o4.sg.booking.com] SpamDetect"
9 21:35:32.00  Stored 22.214.171.124 <email@example.com> <firstname.lastname@example.org> 120395 <XJkzvvWDQXeUsz7INbIxGQ@ismtpd0003p1lon1.sendgrid.net> "[o4.sg.booking.com] Stored locally /home/surgemail/netwin.co.nz/hc/gf/chrisp/mdir/new/1470796532.2114_15646.netwin.netwinsite.co"
Cpu time used 0 cpu seconds
For an outgoing message it looks like this:
9 21:39:48 Rcpt 126.96.36.199 <email@example.com> <firstname.lastname@example.org> 0 ""
9 21:39:49 Received 188.8.131.52 email@example.com <firstname.lastname@example.org> 566 <email@example.com> "Relayfirstname.lastname@example.org, nrcpt=1, s=[test]"
9 21:39:49 NOSPAM 184.108.40.206 email@example.com <firstname.lastname@example.org> 566 <email@example.com> "trusted origin so skipping spam filtering g_smite_skip_relay"
9 21:39:53.00  Sent 220.127.116.11 <firstname.lastname@example.org> <email@example.com> 566 <firstname.lastname@example.org> "[115-18-8-177.jetstream.xtra.co.nz] Delivered to remote host 18.104.22.168 used SSL - 250 message sent ok "
In both cases the line you want when hunting a hacked account is the
'Received' entry, this shows you why the message was accepted by
- email@example.com (The user gave valid smtp auth
credentials, which are listed.)
- g_relay_allow_ip (The sender is from a trusted ip address you
- islocal (The message is to a local account/domain, or was
being forwarded by one)
To find this look for the Relay=... text in the line, e.g. in this
example the message is relayed because the sender authenticated
correctly as firstname.lastname@example.org
9 21:39:49 Received 22.214.171.124 email@example.com <firstname.lastname@example.org> 566
<email@example.com> "Relayfirstname.lastname@example.org, nrcpt=1, s=[test]"
The number in square brackets lets you find all related log entries,
e.g. search on 130766226 in the above example
In some cases you will need to find events just before a log entry,
to find what caused the message to be sent, to do this search on the
date and time, e.g. "9 21:39:4" in the above example...
Settings to help auto detect spammers.
One or more of your users will have their account hacked and abused
to send spam sooner or later, you can make it much harder, and you
can detect it and stop it early using these settings and policies.
# Login guesses per IP before it is automatically and permenently
locked out. Use tellmail unlock ip.address to fix...
# If hacker attempts to login to one of these then the ip is
instantly locked out. (Don't use accounts that exist)
# Only allow smtp logins if the user has previously logged in via
imap/pop from the same address
# Alert users when logins occur from unknown addresses that are not
from australia or usa...
# Max messages an authenticated user can send per 30 minutes, e.g.
# Max outgoing messages per ipaddress/return path pair, 30 minutes,
# Detect local users sending 'spam like' email and send a report to
# White list for people you know send mail that looks a bit dodgy.
# send manager an email if a local user sends more than 300
message in a day...
# Apply some more strict password checking, and alert users with
Lastly you should run this command to find any accounts with
trivially crackable passwords.
We've built a faster more extensive password checker into nwauth, if
you have the latest version of it you can do this:
+OK nwauth 4.3e capa=cluster2
+DATA Info: testing for 999 common passwords,
+DATA Cracked: email@example.com
+DATA Info: testing for variations on common
passwords, pass 2
Settings to stop spoofing of your
The problem with spoofing is that traditional email allowed it and
real legitimate systems still make use of that. Also your own users
may send email from their own accounts via other systems (gmail
etc)... so it's impossible to stop all forgeries unless your users
are prepared to 'play the game' and only send email from your
servers (or at least a list of known systems), so that's why there
is such a lot of settings to do this, each one addresses a subset of
# Maybe this next one, but some real emailers will get blocked as
they still don't obey spf properly.
Check your have spf entries for your domains.
# Optional settings depending on your tolerance for bouncing real
g_from_exact "true" # Bounce if the from doesn't match the
authenticated sender, stops your users pretending to be each
g_from_noforgeme "true" # checks for the special case of
'from=to' and blocks it if it originates from outside your
g_from_check "true" # enables some checking of the from
g_from_nofriend "true" # prevent friend matches for
apparently forged return addresses. So they don't bypass
# And one of these
g_from_bounce "true" # Bounce messages that are probably
g_from_stamp "true" # stamp forgeries in the
spam headers but don't actually stop them.
# Improve friends handling so spf matching is usually required.
g_friends_spf "true" # requires 7.3p-36
An extreme setting you may use:
SECURITY_SUFFIX - Make logins fail unless the user knows the
One other method to protect your server is to make the login
username different from the email address. You can do this on
a per domain level, lets say you have a domain MYDOMAIN.COM and you
want the users to login with username=JOHN@SECRET.MYDOMAIN.COM
note: I don't recommend using the security suffix on most
systems, it is the most complex of the settings and the most
likely to cause disruption, it does have benefits but I would only
use it for small sites where extreme security measures are