26 Jun Are you seeing spam in MDaemon and unsure how to stop it?

Some of our most common MDaemon support enquiries we get relate to users receiving spam.

Typically the amount of spam has either suddenly increased and there is a flood of junk messages or its just a specific message that looks to be obviously spam but has somehow made its way through.

Before picking up the phone to support you might find it useful to follow this simple guide to find out why MDaemon has not treated this message quite as expected.

Step 1:  Follow our recommendations for configuring MDaemon

Rather than explaining all of the MDaemon security features in this blog post we have already put together our recommendations in this guide. We recommend you run through this first and match your MDaemon settings accordingly. If you’re still getting spam messages through after using these settings read on.

Step 2:  Gather the information about how the message arrived

MDaemon can be set up in many different depending on the environment, so its important to understand your own installation. Are you using direct SMTP mail delivery? Is there a pre-filtering service before MDaemon that is masking the original sending server? Maybe you use DomainPOP to collect email from your ISP or even MultiPOP to collect individual mailboxes?

It’s even possible that a user’s Outlook client is collecting email from two mail sources, and only one of those is actually MDaemon.

Knowing how your email platform is configured is key to knowing which logs to look in to find the relevant information.

Step 3:  Look at the Subject line and message headers of the email you received

Don’t forget to check the message headers in the message you have received. A lot can be learned from the message headers, for example if MDaemon has spam scored the message, this is where it will be recorded. Also, scored messages often tag the score within the subject. If this is a minus number then this would suggest a white list has been applied. If there are no antispam related headers then it did not pass through the MDaemon filtering engine.

To view the message headers in Microsoft Outlook, right click on a message and choose ‘Message Options’.  Most other email clients have a similar option to view the message headers.

Step 4:  Following the message through the MDaemon log files

One of MDaemon’s strengths is that it has a set of detailed logs which record a large amount of information about every message it manages. Once you know how a message should arrive (SMTP, DomainPOP or MultiPOP), you can start your investigation by looking for evidence of the message arriving in the relevant log file.

MDaemon keeps the log files in the C:\MDaemon\logs folder by default, and if using the default settings there should be a daily dated log file for each service.

In most MDaemon installations, messages arrive via SMTP so scan the ‘SMTP-IN’ log file that covers when you think the message arrives. To help find the exact session search for the ‘From’ address or ‘Recipient’. If you know the ‘MessageID’ you can also search on that which will be a unique value.

Once located in the SMTP-IN log you should be able to follow the message through all the security steps and see how it was scored by each component in MDaemon.

If all of these checks have passed, the next step is to look in the antispam log as a second pass is made that includes all the message data. This log has the detailed breakdown of how the message has been scored and can often show the reason why it has been accepted.

Step 5:  Use strong passwords for all accounts!

It is becoming more common to see spammers using authenticated SMTP sessions to bypass many of the security checks performed by MDaemon. When a spammer uses an authenticated session it knows your password, so you must changes these right away. For this reason you should always check and make sure users have strong passwords that cannot be easily checked.

Step 6:  Use Whitelists with care!

Whitelists are used within MDaemon to bypass specific security checks, if you see a reference to a whitelist being matched within the MDaemon log files then this is a clear indication that there is a specific entry that has chosen to let that message passed. Use whitelists with care, and only add entries as a last resort. Using wildcard addresses in whitelists is also a common reason for passing massages claiming to be from a specific domain

If you’re finding you’re still stumped, by all means give us a call or drop us an email in support.