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

 

Cheap SSL Certificates

I often see discussions about where to get reasonably priced SSL certificates, and so I’d like to share my source.

For some time I’ve been using a RapidSSL reseller called “RapidSSL Online”

Unlike much of the competition, their prices start at $14.95USD/year, offering 128 / 256 bit single root SSL certificate.

I have no affiliation with them beyond being a satisfied customer, and I receive no compensation for this referral, I simply detest some of the larger players charging substantially more for what is ultimate the same thing.

Use received date instead of date header

By default WorldClient uses the “Date” header of inbound mail rather then the time/date when the message was received. This is normally desired as it allows the receiver to see the order messages were sent, even if some mail was delayed in transit.

However, with spammers and other nefarious individuals being able to tamper with Date headers, this is not always desired and some even consider this a security issue in that it allows a sender to lie about when a message was sent.

There is a switch in WorldClient to tell WorldClient to use the timestamp when the message was retrieved, rather then relying on the date header, if you so desire:

In the WorldClient.ini file, [Special] section, look for the following key:

UseReceivedDate=No

If you set that to “Yes” then it will use the date your mailserver received the message rather then the Date header.  However, in the case of MultiPOP’d mail, it will actually list the date/time that MultiPOP retrieved the article, so it loses some effectiveness.

Note that if you change this switch, it will only apply to newly received messages.  Messages which have already been received will still use the “Date” header. Delete your “message.idx” files to cause WorldClient to rebuild it’s indexes.

Also note that this only applies to WorldClient, POP mail clients can do whatever they want, and IMAP exposes both dates to clients allowing clients to display either or both dates, depending on the client’s capabilities.

keep looking »