How do I use remote authentication with MailMarshal?


This article applies to:

  • Trustwave MailMarshal (SEG)

Question:

  • How do I use remote authentication for client connections to MailMarshal?
  • Can I use SMTP Authentication for outbound connections from MailMarshal?

Information:

Outbound authentication:

Current versions of SEG/MailMarshal allow SMTP authentication for outbound connections to other servers. Authentication can use several mechanisms and you can also require TLS connections.

For details, see the section "Editing Routing Table Information" in the MailMarshal User Guide, and the Help for routing table configuration.

Client or Inbound authentication:

All versions of MailMarshal SMTP allow inbound SMTP authentication. Remote users outside your network can supply a user name and password to relay through MailMarshal. Bona fide remote users are allowed to send e-mail, while unauthorized users (such as spammers) are prevented from using MailMarshal to relay.

Why use remote authentication?

There are a number of ways to allow relaying in MailMarshal:

  1. By using a receiver rule to allow relaying from a specific domain
  2. By allowing specific IP addresses to relay

A more flexible and method is to require the remote user to supply a user name and password before relaying is allowed. This can be achieved by creating a single user account on MailMarshal and by then supplying this account information to all remote users. It is also possible to create an individual user account for each remote user.

What is required on the MailMarshal server?

  • In SEG 7.2.2 and above, you can validate SMTP authentication against an AD group. For details, see Knowledgebase article Q16649.
  • In all versions, you can authenticate using locally created Accounts. Use the Configurator or Management Console to create accounts (known as POP3 accounts in earlier versions).
  • If the purpose of the accounts is for relaying authentication only, it is important to enter a false e-mail domain address in the SMTP alias (if the e-mail domain matches a local domain, the MailMarshal Sender will set aside e-mail in a POP3 folder).
    • If you want to use the POP3 function for users to retrieve mail, see Trustwave Knowledgebase article Q10472.
  • Supply the user name(s) and password(s) to the remote users.

Note: For more information about creating accounts, see the User Guide for your version of MailMarshal SMTP.

SMTP authentication is disabled by default. You can enable this option in the MailMarshal Configurator:

  • 6.5 and above: Array Properties | Receiver Properties | Advanced
    (Choose to allow authentication from all locations, or external connections only)
  • 6.0 through 6.4: Server and Array Properties | Advanced | Additional Options | Receiver
    (Choose to allow authentication from all locations, or external connections only)

You must create a Receiver rule, which specifically allows authenticated users to relay. The rule MUST apply to outbound messages and could look something like this:

When a message arrives
Where message is outgoing
Where sender has authenticated
Accept message

What is required on the remote client?

The mail account properties of the remote client need to be changed to indicate that the outgoing mail server requires authentication. In Outlook Express this is found under Tools | Accounts | Mail | Properties | Servers. Check "My Server requires Authentication" and under "Settings", enter the user name and password as supplied above. Outlook can be set to "remember password", or not, depending on preference.

Using the service

When the remote user tries to send an outbound message through MailMarshal the mail client will now prompt for a user name and password. This information is passed to the MailMarshal server, and if it matches an existing account, the remote user is allowed to relay. This process should be transparent to the user if the password is automatically remembered.

Is this a security risk?

If you use passwords that you have entered in MailMarshal, the security risk is minimal. This method is simply used to allow users to relay through your system. The user name and password used here corresponds to a MailMarshal account only. It does not grant access to other MailMarshal services, because the services rely on Windows authentication. It does not grant access to any existing internal mail server.

For further security, MailMarshal supports CRAM-MD5 digesting of the authentication information.

Note: MailMarshal also allows you to use Windows account passwords (if the password field is blank, a Windows account is assumed.) This option represents a significantly higher security risk, as the Windows account could allow access to other items.

To use Windows passwords, you must ensure that the account name matches a valid Windows account that can be authenticated on the servers where email processing occurs (standalone server or array processing nodes). The accounts used for MailMarshal services must have administrative permissions. If you are using internal Active Directory accounts, these servers must be in the AD environment. (With MailMarshal 5.5, the Windows account must be able to access files.)

This article was previously published as:
NETIQKB29207
Marshal KB139

Last Modified 5/1/2020.
https://support.trustwave.com/kb/KnowledgebaseArticle10528.aspx