(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)

 

CC BY-NC-ND 4.0 (don’t) Drop connection if transmission exceeds… by Dave Warren (everything-mdaemon.com) is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.

2 Replies to “(don’t) Drop connection if transmission exceeds…”

  1. Hi here in Norway we use Mdamon with a lot of users that send/receive email up to 500MB, this is done with our FrontMail system that we have created for Mdaemon. What it does when the sender send a email with huge attachents the mdaemon plugin strips out all attachments from the email and saves them on a https:// server and in the email body a link is added to fetch the attachments so that the email going out to the receiver is only about 5-10KB size.
    We have used this with great success because it removes the biggest headache of sending / receiving large emails. And loso it eliminates all of the issues you hve mentioned above.

    http://www.frontoffice.no/en/saas/frontmail

  2. Stripping attachments once they’re received is certainly an option, but it won’t actually address this particular issue as this issue occurs before MDaemon has received the message enough to call any plug-ins.

    However, using a plug-in will help address POP3 clients (and their related AV scanners) that can’t handle large messages.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.