Everything MDaemon

Autoresponders and aliases

Dave Warren — Mon, 11 Mar 2013 16:33:54 +0000

The problem: You have a user with multiple aliases, such as a firstname.lastname@example.com username and a general sales@example.com alias. You want to set an autoresponder for the main mailbox, but you don’t want to send an autoresponder message to messages directed to the sales alias.

MDaemon actually can do this although it’s not immediately obvious how.

The autoresponder list has a “whitelist”, to find it, open MDaemon –> Accounts –> Account Settings –> Autoresponders –> White List. This list is primarily a list of senders and recipients who should not receive an autoresponder.

Unfortunately this list compares addresses after alias processing has finished, so you can’t just enter an alias to the list. However, you can also match user-defined headers here, and if the header containing the string mentioned is found in the current message, the message won’t receive an autoresponder.

So in this example, you could place “X-MDRcpt-To: sales@example.com” in the whitelist. Note that this header exists for all messages, not just messages where aliases are used, it simply contains the address the sender used.

For those that are curious, the \MDaemon\App\autorespexcept.dat file contains the list, for your manual editing pleasure.

Another DNSBL lost, NJABL shutdown

Dave Warren — Sat, 02 Mar 2013 00:21:31 +0000

Accordnig to NJABL’s website, they’re shutting down effective immediately:

March 1, 2013: NJABL is in the process of being shut down. The DNSBL zones have been emptied. After “the Internet” has had some time to remove NJABL from server configs, the NS’s will be pointed off into unallocated space to hopefully make the shutdown obvious to those who were slower to notice.

If you have NJABL listed in your MDaemon or SecurityGateway configuration, you should probably remove it immediately. MDaemon’s SpamAssassin automatically uses NJABL as well, but as long as you have automatic updates enabled no action is required, SpamAssassin will be disabling NJABL per bug 6913.

To NJABL’s operators: Thanks for all your time and efforts, it was appreciated!

Vulnerability in BlackBerry Enterprise Server (BES)

Dave Warren — Wed, 27 Feb 2013 02:41:00 +0000

Alt-N posted a fix to a recently discovered vulnerability in the BES component of MDaemon.

If you run MDaemon w/BES enabled, you need to install the security patch described at KBA-02500 immediately.

Using MultiPOP to pull all mail, including spam, from Gmail to MDaemon

Dave Warren — Thu, 27 Dec 2012 18:07:24 +0000

With Gmail recently dropping support for ActiveSync, I’m seeing more and more people wanting to centralize all of their mail in local MDaemon installation.

This sometimes includes a situation where you want to pull mail from your old external mailboxes into MDaemon. When pulling mail from Gmail, for example, you’ll find that MDaemon’s MultiPOP feature grabs the Inbox, but what about mail that ends up in Gmail’s spam folder?

As it turns out, it’s possible to disable Gmail’s spam filtering using a custom Gmail filter, and then rely on MDaemon’s excellent spam filtering instead.

Login to the Gmail account
Click on Settings
Click on Forwarding and POP/IMAP
Select one of the two Enable POP options
Click Save Changes
Click on Filters
Create a new filter
In the “Has the words” filter field, type “deliveredto:your-gmail-account@gmail.com” where your-gmail-account@gmail.com is the name of your Gmail box.
Click the grey Create filter with this search >> link
Enable Never send it to Spam
Click Create filter

This will not apply to any messages already marked as spam (even if you use the “Also apply filter to…”, it will not move messages out of the Spam or Trash folder), so you will need to manually move any messages now in the Spam folder into the Inbox for MDaemon to see them.

Gmail difficulties pulling mail from MDaemon

Dave Warren — Tue, 18 Dec 2012 07:19:14 +0000

If you have a mixed MDaemon+Gmail environment where Gmail retrieves mail from MDaemon via POP3 (a reverse Multi-POP), at some point in the past 24 hours you may have noticed Gmail stopped accessing mail.

It appears that Gmail has changed how their Always use a secure connection (SSL) when retrieving mail feature works, and they now require a certificate signed by an authority that they trust, they no longer accept self-signed certificates.

This is a good and bad, self-signed certificates offer little or no security against man-in-the-middle attacks, and so can lead to a false sense of security, however, it’s annoying that this breaks your working configuration.

Between this and the recent announcement that Gmail will be dropping ActiveSync support for new accounts, it might be a good time to consolidate all of your users on a locally hosted and managed MDaemon server rather than relying on the moving support target of cloud hosting.

If you don’t already have a valid certificate, I previously wrote an article on where you can get Cheap SSL Certificates (I have no affiliation, and I receive no compensation for this referral. I also have not verified that their certificates pass Gmail’s tests at this time or in the future).

MDaemon Critical vulnerability (versions 11, 12 and 13)

Dave Warren — Thu, 25 Oct 2012 21:38:03 +0000

Alt-N posted a fix to a recently discovered vulnerability, MDaemon Security Bulletin – MD102412, listing MDaemon versions 11, 12, and 13 as being affected by a flaw that was discovered during internal testing.

If you run one of the affected versions, please visit http://www.altn.com/Support/SecurityUpdate/ to find an updated build and install the update immediately. Builds are available for customers running older versions even if your upgrade protection has already expired, so there is no reason to not deploy this release immediately.

Per Alt-N’s FAQ on MD102412, MDaemon versions prior to MDaemon 11.0.0 are not affected by this issue.

Disabling weak SSL protocols and ciphers

Dave Warren — Thu, 04 Oct 2012 23:22:46 +0000

MDaemon relies upon Windows to provide SSL services. This includes modern SSL versions as well as some older, less secure protocols and cyphers. You can modify the Windows registry to increase the security of your SSL implementation, at the cost that very old clients may have issues.

To disable protocols PCT1 and SSL2.0, use the Disable-PCT-1.0-SSL-2.0-and-weak-ciphers.reg file available in RAR or ZIP format. Note that the RAR has an authenticity verification signature, signed by Dave Warren and should not be used if this signature is missing.

The contents of the .REG are located below, be aware that some word-wrap issues might occur. Please use the RAR or ZIP downloads above.

To disable PCT 1.0 and SSL 2.0:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]

And to remove weak ciphers:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 128/128]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168]

Please be sure to create a full backup of your system before proceeding, modifying the Windows Registry can be dangerous and can result in unexpected behaviours.

rfc-ignorant.org ceasing operation – Remove from your configuration

Dave Warren — Sun, 16 Sep 2012 07:36:18 +0000

Please see http://rfc-ignorant.org/endofanera.php for details.

While I never personally used their services, or found any real value, thanks to RFC-Ignorant for their services over the years.

Users of modern MDaemon releases don’t need to modify SpamAssassin, just ensure that your spam filter updates are enabled and the rules will automatically be disabled as needed.

list.dsbl.org listing the world

Dave Warren — Fri, 10 Aug 2012 16:43:15 +0000

It appears that list.dsbl.org has started listing the world as of today. This list has been inactive for around 4 years now, so if you’re using it in MDaemon, please remove it from your MDaemon DNS-BL immediately.

While we’re on the topic, if you’re running an MDaemon version earlier than 12.5.0, please either upgrade or follow the instructions in this post from 2009 to remove DSBL lookups from SpamAssassin. MDaemon 12.5.0 and higher should not query this list from SpamAssassin.

(don’t) Drop connection if transmission exceeds…

Dave Warren — Sat, 03 Dec 2011 22:17:45 +0000

MDaemon currently has two features that attempt to limit the size of messages that MDaemon will accept, both located under Setup –> Default Domain –> Servers:

… refuses all messages larger than (and a per-domain feature that does the same)
… drop connection if transmission exceeds

This article covers the second, the “drop connection if transmission exceeds” option. In short, you probably shouldn’t use it, or should think very careful before enabling it as it will probably not do what you want.

Specifically, do not attempt to use this feature to limit the size of message that you’ll accept, and do not use this feature to try to reduce your server’s bandwidth usage, it won’t work and it will cause your bandwidth usage to go way up. Oh, and it won’t inform users of the problem so they’ll manually retry sending messages, compounding the problem.

The “drop connection…”options scattered around MDaemon all have potential to increase bandwidth use in certain cases, but this is one of the worst because it only kicks in during transmission of large messages. As a result, this option potentially causes dramatic increases in bandwidth usage due to the way SMTP works. Most SMTP clients (senders) use the SIZE parameter in the MAIL FROM command, a few use it in the EHLO response. These senders are smart enough to not even try sending a too-large message, so they don’t matter here. For the few that don’t support verifying maximum sizes before sending messages, they get to the DATA stage and start sending a huge message and one of two things happens:

If it gets to the end of the DATA phase, MDaemon can return a 5xx “too-large” error and the sender bounces the message back.
If something happens during the DATA phase (connection problem, firewall, MDaemon willfully drops the connection) the sender puts the message in their queue and retries sending it again. And again. And again. And again. And again. And again. And again. And again. And again. And again. And again.
And again.

Using “Drop connection if transmission exceeds…” is almost always going to be a very idea and going to drive your bandwidth usage up dramatically if you attempt to use it to limit the size of message that MDaemon will process.

The only time it’s useful is this: If a sender actively attempts a disk-fill attack, where they open a ton of sessions at once and try to cause MDaemon to write GBs of messages until the disk is full. You can protect against this type of attack by having a reasonable amount of drive space, and by setting this limit very high (I’d suggest in the 50MB range, and at least 2x-3x of the maximum message size you’ll receive)