SMTP In

The Protocols page lets system administrators configure settings for messages received into the SmarterMail server.

Connection and Session Settings

Use this card to specify the following inbound SMTP settings:

• SMTP Banner - The text that is displayed when initially connecting to the port. By default, the banner is #HostName#. The banner supports the use of the following variables, which will be replaced with their corresponding values:
  • #HostName# - The hostname of the IP address to which the connection is made.
  • #ConnectedIP# - The IP address of the remote computer.
  • #Time# - The system's local time.
  • #TimeUTC# - The time in UTC.
  • #UnixTime# - The number of seconds since January 1, 1970.
  For example, a banner of #HostName# ESMTP ready at #Time# would be sent to a connecting client as something like mail.example.com ESMTP ready at Thu, 06 Jan 2022 10:07:54 -07:00. Date/time variables can also include a custom .NET format string by appending a colon and the format inside the variable, e.g., #Time:yyyy-MM-dd#. Since this banner is sent before authentication, in cleartext, on every connection — including from other mail servers doing reconnaissance — many administrators deliberately avoid putting version numbers or product names in it.
• Allow Relay - Controls who is permitted to use this server as an SMTP relay (i.e., to send a message through this server where neither the sender nor the recipient is a local mailbox on this server). If you are concerned about spammers using the relay function to send mail through your server, or do not want any other mail server to use your SMTP server as a gateway, set this to Nobody.
  Note: Setting this to Nobody is strongly recommended. An open or loosely restricted relay is one of the fastest ways a server ends up blacklisted, since spammers actively scan the internet looking for mail servers that will forward their messages on to other domains.
  • Nobody - Restricts sent mail to only work via SMTP authentication and with accounts on the local SmarterMail Server (except for IPs on the White List). This is the safe default: a message can only be relayed if the sender either authenticates with valid SmarterMail credentials or connects from an explicitly whitelisted IP.
  • Only Local Users - Limits relay access to users (email accounts) for a valid domain on your SmarterMail Server. This distinction matters for domains that exist only as alias or catch-all destinations with no real mailboxes behind them: a domain configured purely for forwarding (for example, a legacy domain where every address is an alias pointing to accounts on a different domain) has no local users, so mail addressed to it would still be rejected for relay purposes under this option even though the domain itself is locally hosted.
  • Only Local Domains - Limits relay access only to mail hosts (domains) on your SmarterMail Server, regardless of whether the specific address involved corresponds to a real user account. Using the same example, a catch-all/alias-only domain with no individual user accounts would still be allowed to relay under this option, since the check is against the domain existing on the server rather than against a specific mailbox existing within it.
  • Anyone - Allows any other mail server to pass messages through your mail server, increasing the chances of your mail server being used for sending large volumes of messages with domains not associated with your local mail server. Selecting this option turns off statistics for all domains, due to the high amount of messages that are passed through the mail server with an open relay.
• Session Timeout (Minutes) - After a connection fails to respond or issue new commands for this number of minutes, the connection will be closed. By default, the session times out after 15 minutes.
• Enabled - This setting is enabled by default.
• Command Timeout (Seconds) - If the server receives a command that sends large amounts of data but the data stops coming in for this number of seconds, the command will be aborted. By default, the command times out after 120 seconds.
• Max Connections (0 = Unlimited) - Some protocols in SmarterMail allow you to specify the maximum number of connections. Increasing this value allows SmarterMail to handle more connections of that type at once, but results in higher CPU and memory utilization. By default, the maximum number of connections is 1000.
• Max Messages Per Session (0 = Unlimited) - The maximum number of messages that can be sent in one session. This is useful in handling cases where spammers will make one connection and then send a large amount of messages with that connection.
• Continue delivery if session is disconnected by client - When enabled, this setting allows your mail server to receive deliveries from legacy mailers, such as PHP Mailer, which do not wait for any feedback from the receiving server before disconnecting a session. This setting is disabled, by default.
  Note: This is a tradeoff between compatibility and duplicate mail. If disabled (the default) and a legacy or misbehaving client disconnects before SmarterMail finishes acknowledging the message, SmarterMail treats that as a failed delivery attempt and rejects it, which can cause the sending client to never successfully deliver the message at all. If enabled, SmarterMail instead accepts and processes the message despite the early disconnect — but because the sending server also saw what looked like a failed connection, it is very possible it will retry delivery on its own, meaning the mail server may receive duplicate copies of the same message from legitimate servers that disconnected early. In practice, this setting should only be enabled if a specific, identified sending system requires it.

Message Limits and Delivery

• Max Bad Commands - After this many unrecognized or improper commands, a connection will be automatically terminated. By default, the maximum number of bad commands is 8.
• Max Hop Count - After a message gets delivered through this many mail servers, it is aborted by the software. This prevents looping due to DNS problems or misconfigurations. By default, the max hop count is 20.
• Max Message Size (KB) - This controls incoming messages, and outbound messages sent via email clients configured with IMAP or POP. As such, this setting should match, if not exceed, the Max Message Size set for domains. This will help prevent email client users from having their outbound messages rejected due to the message size. By default, the max message size is 10,240 KB (10 MB), and this number includes text, HTML, images and attachments. The value can be raised up to a hard-coded maximum of 512,000 KB (500 MB); SmarterMail will not accept a value higher than that cap regardless of what is entered here.
  Note: Base64 encoding of attachments increases their size by approximately 35%. Knowing this, and in order to provide a better user experience, SmarterMail allows messages to be sent that are technically over the limit set for Max Message Size, since the comparison is made against the original attachment size rather than its base64-encoded size on the wire. For example, if Max Message Size is set to 100,000 KB (roughly 97.6 MB) and a message arrives with a 90 MB attachment, that message will still be accepted even though the attachment's base64-encoded representation — roughly 121 MB once the 35% overhead is factored in — technically exceeds the configured 100,000 KB limit.
• Max Bad Recipients (0 = Unlimited) - At times, spammers will hammer a domain with a dictionary harvesting attack. This means that software is used to send messages to many of the most common mailbox addresses (e.g., admin, user, contact, etc.) or username variations (e.g., alan@, alana@, alanb@, etc.) in order to find valid email addresses. Setting the max bad recipients means that after this many bad recipients (those that don't exist for the domain) are given in a single SMTP session, the session will be terminated. This setting allows you to better protect yourself against email harvesting attacks. A value of 20 is recommended in most cases, and is also the SmarterMail default.
• Max Recipients Per Unauthenticated SMTP Session (0 = Unlimited) - In order to prevent memory issues, this would be the max number of recipients allowed for unauthenticated SMTP sessions. This limit only applies when a domain's Recipients per Message is set to 0 (Unlimited) and only applies to unauthenticated senders that are not using a local address as the From address.
• Append Received Line - Every hop a message passes through on its way to the inbox is supposed to stamp a Received header onto the message recording where it came from, when, and over what connection (SmarterMail's version includes the HELO/EHLO name the connecting client presented, its reverse-DNS hostname and IP address, and whether the connection was encrypted). This header chain is one of the primary tools used to trace a message's actual path and diagnose delivery or spoofing problems. This setting selects whether SmarterMail appends its own Received header for All Inbound Messages, only for Non-authenticated Messages (i.e., mail arriving from senders who did not authenticate, meaning external mail, while omitting the header for messages sent by authenticated local users), or for None at all. Choosing Non-authenticated Messages or None is sometimes used to avoid exposing an authenticated user's originating client IP address and hostname to external recipients when that user's message is later relayed onward, since that information becomes visible to anyone who views the message's full headers.
  Note: Regardless of this setting, if a message arrives with no Received headers at all, SmarterMail will still add one to prevent issues with some mail clients that expect at least one to be present.
• Enable Delivery Status Notifications (DSN) - Delivery status notifications are automated messages notifying a sender about the delivery status of a message: if it bounces, if it was delayed or if delivery was successful. This setting is the master switch for whether SmarterMail generates these notifications at all; the actual subject, body, and language of each DSN type (Delivery Status Success, Delivery Status - No Notification, Delivery Status Delayed, and Delivery Status Failure) are configured separately as system message templates. If this setting is disabled, none of those templates will ever be sent, regardless of how they're configured.

Authentication and Security

• Require Auth Match - Select this to force a user's From: address to match their SMTP authenticated address. This setting helps keep authenticated senders from spoofing a From: address that isn't theirs when sending through this server. It has three options:
  • None - Does not require the authenticated user's address to match the From: address at all.
  • Email Address - Requires the MAIL FROM (return path) and From: address to match the exact, entire email address of the authenticated user. For example, a user authenticated as alice@example.com would be blocked from sending a message with a From: address of bob@example.com or alice@otherdomain.com.
  • Domain - Requires only that the MAIL FROM and From: address share the same domain as the authenticated user, rather than matching the exact address. Using the same example, a user authenticated as alice@example.com would be allowed to send as sales@example.com or support@example.com, since all three addresses belong to the same domain, but would still be blocked from sending as alice@otherdomain.com.
• Include MIME headers for auth match - This setting works in conjunction with Require Auth Match. When enabled:
  • If "Require Auth Match" is set to "Email Address", the MAIL FROM (Return Path) and either the From or Sender header must match the authenticated user. If the Sender is present and matches the authenticated user but the From does not match, the account associated with the Sender header must have permission to send as the account associated with the From header.
  • If "Require Auth Match" is set to "Domain", the MAIL FROM (Return Path), From, and Sender (if present) must be in the same domain as the authenticated user.
• Allow relay for authenticated users - This setting enables the "Allow Relay" setting when users are required to use SMTP Authentication for sending messages. This is enabled by default, and is what allows a properly authenticated user to relay mail out to any destination domain even when Allow Relay above is set to Nobody — the Nobody restriction is aimed at anonymous/unauthenticated relay attempts, not at your own authenticated users sending legitimate outbound mail.
• Enable Domain's SMTP auth setting for local deliveries - Enable this setting to enforce SMTP authentication for all local deliveries. For example, mail from user1@example.com to user2@example.com must be authenticated even though the message is bound for local delivery.
• Disable AUTH PLAIN method for non-SSL SMTP authentication - When enabled, and the connection is not already using SSL/TLS, SmarterMail removes the SASL AUTH PLAIN mechanism from the list of authentication methods it advertises and rejects any client that attempts to use it anyway. AUTH PLAIN sends the username and password together as a single base64-encoded string in one step, so blocking it over unencrypted connections prevents credentials from being transmitted in a form that's trivial to decode if intercepted.
• Disable AUTH LOGIN method for non-SSL SMTP authentication - When enabled, and the connection is not already using SSL/TLS, SmarterMail removes the SASL AUTH LOGIN mechanism from the list of authentication methods it advertises and rejects any client that attempts to use it anyway. AUTH LOGIN sends the base64-encoded username and password as two separate server prompt/response exchanges rather than in a single step, but like AUTH PLAIN, it is still just base64 (not encryption), so it offers no real protection against interception over a plain-text connection.
• Disable AUTH CRAM-MD5 methods for non-SSL SMTP authentication - When enabled, and the connection is not already using SSL/TLS, SmarterMail removes the SASL AUTH CRAM-MD5 mechanism from the list of authentication methods it advertises and rejects any client that attempts to use it anyway. Unlike AUTH PLAIN and AUTH LOGIN, CRAM-MD5 is a challenge-response mechanism that never sends the password itself over the wire, so it is somewhat more resistant to passive interception than the other two — but it is still considered weak by modern standards (it relies on MD5, and a captured exchange can be vulnerable to offline attacks), which is why many administrators disable it as well on non-SSL connections.
• Enable VRFY command - VRFY is a legacy SMTP command that asks the server to confirm whether a specific email address exists on the server (e.g., VRFY alice@example.com) without actually sending a message. Enable this setting to allow others (including other mail servers) to verify an email address on the server.
  Note: Some people believe enabling VRFY commands is a security risk, so be sure to research the possible ramifications before enabling this feature. Because VRFY gives a direct, message-free way to confirm valid addresses, it can make it easier for a spammer to build or refine a list of known-good addresses on your domain before ever sending mail.
• Enable EXPN command - EXPN is a legacy SMTP command that asks the server to expand a mailing list or alias and return the individual addresses that belong to it. Enable this setting to allow others to list all users associated with an alias or list.
  Note: Some people believe enabling EXPN commands is a security risk, so be sure to research the possible ramifications before enabling this feature. Since EXPN can reveal the individual member addresses behind a distribution list or alias, enabling it can expose addresses that were never meant to be publicly discoverable.