Using an external mail filtering service

If you happen to be using an external mail filtering service or appliance, one of the critical setup steps is to ensure that MDaemon is configured to not accept messages that attempt to bypass your mail filtering service as spammers look ways to bypass filtering gateways.

There are multiple ways to accomplish this in MDaemon, but one of the easiest ones is often overlooked: IP Shield. IP Shield is a very simple feature, it provides an administrator a simple way to tell MDaemon to only accept mail from a particular domain if it matches one of the listed IP addresses. Once upon a time, this was used to prevent spammers and others from forging one’s own domain, but there are better ways to accomplish this in MDaemon now, so today, we’ll use IP Shielding in another way: By using wildcards. With a wildcarded sender domain, you can use IP Shield to ensure that MDaemon will only accept mail if it’s from a pre-defined IP address or uses authentication.

      Open the Security menu
      Click on Security Settings
      Under Sender Authentication, open the IP Shield dialog
      Uncheck Do not apply IP Shield to messages sent to valid local users
      Check Do not apply IP Shield to authenticated sessions
      Check Do not apply IP Shield to Trusted IPs
      Check IP Shield honours aliases
      Uncheck Check FROM header against IP Shield
      In the Domain field, enter *
      In the IP field, the IP address of your mail filtering gateway
      Click Add
      Repeat these steps to add any other IPs that should be allowed to send mail without authentication.

Note that you can use wildcards and CIDR notation for IP addresses here.

Since users should be configured to use authentication, this will not impact normal user traffic, but it will block any unauthenticated attempt to send mail unless the IP matches one of the entries. – Dead

If you’re currently using for spam blocking or filtering, you should probably remove it from your configuration immediately.

Luckily this DNSBL was not widely used, and is not part of a default MDaemon configuration, so most MDaemon administrators will not need to take any action. If you do have MDaemon configured to use it, you’re currently seeing either timeouts or errors, and shortly you will find a majority of inbound mail will be flagged as spam.

Mark Jeftovic of EasyDNS recently posted the following to the mailop mailing list.

As some of you may know, we recently took over and it’s customer base.

We’ve found a domain on the system: which is delegated to zoneedit nameservers, broken (it is not allowed to zone transfer from it’s designated master), unresponsive (account owner is not answering email, has an address in Sri Lanka and no telephone number), is using excessive queries (~ >500M queries per day on a “free dns” domain) and attracting repeated, multiple DDoS attacks.

As such, we will be wildcarding this zone and setting a long TTL fairly soon.

If you’re actually using this RBL in your MTAs, now’s a good time to stop. (this RBL is broken on 5 out of it’s 6 delegated nameservers across 3 separate providers).

I’d like to thank Mark for giving everyone advanced warning.

Another DNSBL lost, NJABL shutdown

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!