Tag Archives: SMTP

Port numbers

Posted on by — No Comments ↓

Assuming a default configuration, the following inbound ports are required (depending on which services you want to make publicly available). All ports are TCP, unless otherwise mentioned.

MDaemon
25, Inbound and Outbound – ESMTP
53, Outbound – DNS (note that return packets are required)
110, Inbound and Outbound – POP3 and MultiPOP
143, Inbound – IMAP4
366, Inbound and Outbound – ODMR (ATRN, alternate ESMTP port)
465, Inbound – SSL SMTP
587, Inbound – ESMTP MSA (Mail Submission Agent — Have your mail cilents deliver here rather then 25 to avoid ISP firewalls
993, Inbound – SSL IMAP4
995, Inbound and Outbound – SSL POP3
4069 UDP, Inbound and Outbound – Minger

Even if you intend on enforcing encrypted connections, the unencrypted ports should be left active as the STARTTLS command starts a connection unencrypted and later adds encryption.

WorldClient, SyncML, ActiveSync, WebDAV, and possibly more
3000, Inbound – HTTP
80, Inbound – HTTP
443, Inbound – HTTPS

If nothing else on your server listens on port 80 and 443, it is highly recommended to assign these ports to WorldClient. It is required for ActiveSync’s AutoDiscovery, and for some older ActiveSync clients to connect.

WebAdmin
1000, Inbound – WebAdmin’s webserver

BES
3101, Outbound – BES services

SpamAssassin
80, Outbound – SA-Update

SecurityPlus/Outbreak Protection
21, Outbound – FTP for virus definitions updates
80, Outbound – HTTP for virus definitions updates and Outbreak Protection

If you are using a software firewall, you should ensure that the following processes have unrestricted inbound and outbound access: MDaemon.exe, WorldClient.exe, WebAdmin.exe, MDSpamD.exe, AVUpdate.exe

Finally, note that various parts of MDaemon interact using sockets to localhost IP addresses, so if you use a software firewall, you should not block any traffic to/from 127.0.0.1. This includes SpamAssassin, WorldClient, BES and other features.

(don’t) Drop connection if transmission exceeds…

Posted on by — 2 Comments ↓

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)

 

Understanding DomainPOP duplicates

Posted on by — 14 Comments ↓

DomainPOP relies on retrieving mail from your ISP and delivering it to local users based on parsing the available headers and essentially guessing at the best recipient or recipients.  This is very different then SMTP which has a well defined RCPT TO command which defines exactly who the message is addressed to.

To create an analogy, imagine I write a letter addressed to Bob, and courtesy copied to Frank and Henry.

Inside the envelopes, the letters are identical, they’re all addressed to Bob, and courtesy copied to both Frank and Henry.  However, on the envelope I only write the one recipient who is to receive that copy of the message.  When the messages are delivered to your ISP via SMTP, there is both an envelope and the a body (the “letter” in this analogy)

In the case of DomainPOP, it’s like someone opens all the envelopes and throws them out, all you receive is the letter.  Without the envelope, you don’t know exactly who the message should be delivered to.  You can guess based on the available data, the TO and CC headers, but this won’t help you with BCC’d recipients (blind carbon copy, by definition, doesn’t have the recipient’s address in the TO or CC Fields)

By default MDaemon takes the safest route and delivers one copy to everyone mentioned in the various headers MDaemon reviews, taking the approach that it is better to deliver multiple copies then none at all.

Depending on your upstream ISP’s capabilities it may be possible to avoid these duplicates entirely.  There are two options, start with #1 and if that fails, go to #2.

1) A unique header.

Some ISPs are kind enough to insert the RCPT TO command of the SMTP session into the message.  MDaemon, for example, does this in both the X-MDRcpt-To and X-Rcpt-To headers, as well as a Received header (in most cases).

To test if this is the case, you’ll need an off-site email address, one that has nothing to do with your domain.  Gmail/Hotmail are perfect.  If you don’t have access to one, let me know and I’ll send the test message from here.  For the purposes of this article, I’ll use [email protected] as the address which is receiving duplicates and [email protected] as the off-site address.

In MDaemon, go to Setup –> DomainPOP –> [Security] tab, enable the “Place an extra copy” option, and set the directory to a known path.  C:\MDaemon\DomainPOP would be great as this directory doesn’t exist and is easy to find.

Go to your off-site (Gmail) mailbox, and send a message addressed to itself (it should be FROM [email protected] and TO [email protected]), and then BCC yourself ([email protected] in this example)

Once it is received by your server, go to the C:\MDaemon\DomainPOP directory and find the message, open it in Notepad.  Look for the [email protected] address, and if you find it, check out the header that contains the address.

If it’s a X-Delivered-To or X-Rcpt-To or something like that, then it means your ISP likely creates a header showing the actual recipients of the message.

Once you find a header you want to test with, go to the MDaemon –> DomainPOP dialog again, this time to the [Parsing] tab, remove all the headers in the list and add the header you found (unless it happens to be a Received header, if so, there is a checkbox for the Received header above as this header needs some special handling)

Now, you’ll want to test this before proceeding, you need to make sure that your ISP added the headers and not the sender.  If possible, test from Gmail, Hotmail and Yahoo, or have a couple friends or coworkers try emailing you and make sure it works.

2) DomainPOP’s de-dupe feature

You should only use this if #1 doesn’t reveal an appropriate header to use.

To use this feature, in the DomainPOP dialog’s parsing tab, enable the Dedupe feature.  I’d suggest using the Message-ID header, this is the safest, but some mail clients don’t generate a Message-ID so you’ll still see some duplicates.

Another possible header is the Date header, virtually all mail has a Date header, but if two senders happened to send mail at exactly the same second, from the same timezone, it’s possible that one of the messages could get lost, so there is a bit of risk involved with this choice.