(don’t) Drop connection if transmission exceeds…

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

  1. … refuses all messages larger than (and a per-domain feature that does the same)
  2. … 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:

  1. 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.
  2. 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)

 

Detecting a blank header in the content filter

The content filter has a condition to trip if a header doesn’t exist.  However, there is no easy way to catch a header with no content at all.

This rule will trip on a blank subject header (where the header DOES exist, but has no content)

[Rule001]
RuleName=If subject is NOT empty, Skip next rule
Enable=Yes
ThisRuleCondition=All
ProcessQueue=LOCAL
Condition01=SUBJECT|reg exp|AND|^..+$|
Action01=skip rule|"1"
[Rule002]
RuleName=Subject IS empty!
Enable=Yes
ThisRuleCondition=All
ProcessQueue=LOCAL
Condition01=SUBJECT|exists|AND|
Action01=move to bad Msg|

UPDATE 2009/06/17: For some reason this rule was completely broken, both by WordPress inserting smartquotes, and a logic error. My apologies, it has been corrected and tested on MDaemon 10.0.5, it should now work as advertised.

Image-only adult themed spam

Lately there is a new batch of spam going out that tends to use adult themed subjects, but has no content in the body aside from a single image.

It has been reported that this SpamAssassin rule helps:

header __CTYPE_MULTIPART_MXD Content-Type =~ /multipart\/mixed/i
mimeheader __ANY_TEXT_ATTACH Content-Type =~ /text\/\w+/i
meta MIME_IMAGE_ONLY (__CTYPE_MULTIPART_MXD && __ANY_IMAGE_ATTACH && !__ANY_TEXT_ATTACH)
score MIME_IMAGE_ONLY 2.00
describe MIME_IMAGE_ONLY Image body part but no text body parts

To use it, copy these five lines into the bottom of your \MDaemon\SpamAssassin\rules\local.cf file, then either restart MDaemon or create a mdspamd.sem file in the \MDaemon\App\ directory.

You may want to tweak the “Score”, but start with 2.0 as this rule hasn’t been aggressively tested so there is a higher risk of false positives then with the default SpamAssassin rules.

Lastly, it’s also worth mentioning that Outbreak Protection (part of SecurityPlus 4 and higher) is flagging these messages as spam.

UPDATE 2009/05/19: The above rule only works in MDaemon 10 and higher, for earlier versions, you’ll need one more line:

mimeheader __ANY_IMAGE_ATTACH Content-Type =~ /image\/(?:gif|jpeg|png)/
(Thanks goes to “Greg Vancardo” for tracking this one down)