Authentication can be used for a variety of purposes. This list provides some common use-cases for SMTP authentication, along with the configuration settings needed to set to enable the functionality. You may configure authentication with any combination of these settings depending on the needs of your system.
Address spoofing occurs when the sender of an email claims to be someone else, and particularly when the sender claims to be from the domain of the system they are sending a message into. This allows a malicious sender to pretend to be a user from your domain, gaining the trust of the target recipient who is unaware that the sender is not the same person that created the message.
There are a variety of ways to prevent address spoofing, each of which depend on the way your email system is implemented.
The most obvious and common way to stop spoofing is to require proof of identity. The sender needs to know the username and password of a valid user to be able to gain sender privileges from your domain.
To enable this method, set the following configuration items:
Enable SMTP AUTH (1) to turn authentication services on at the SMTP interface, preferably 'when encrypted'.
Require inbound SMTP domain authentication (9) set to 'Required always'. This setting requires authentication when messages sent to your domain that are also from your domain. It does not require messages from a different domain to authenticate.
Match AUTH user with FROM address (11). It's usually a good idea to enable this setting to prevent internal user masquerading or malware generated messages that have hijacked some of a user's credentials.
If possible, creating separate SMTP interfaces for public mail and private mail can simplify spoof prevention a lot.
SMG can run multiple SMTP interfaces, binding to different IP addresses and/or ports. With multiple interfaces, it's easy to define specific requirements for users connecting to the different interfaces. You can define a public interface to not allow authentication, and a private interface to require authentication. This both prevents attackers from using the public interface in any type of malicious authentication attempt, and also prevents users from trying to authenticate to the public interface, which can inadvertently leak credentials. The only users that can identify as being from your domain are required to authenticate on that interface.
A typical setup using this method is as follows:
Create an SMTP interface intended for public consumption
Set SMTP AUTH (1) to disabled.
Enable Require SMTP sending domain authentication (10). This setting requires senders from your domain to authenticate, but they cannot do so due to SMTP AUTH being disabled. This combination of settings prevents any sender from claiming to be from your domain.
Create a second SMTP interface intended for private consumption.
This interface may listen on the same IP address with a different port, or another IP address, depending on your internet options. It is common practice to setup this service on port 587, known as the 'message submission' port. Ensure STARTTLS is enabled for the interface for secure connections.
Set SMTP AUTH (1) to enabled, preferably when encrypted.
Enable Require authentication (2). This setting forces all senders coming in through this interface to be authenticated to send mail.
Enable Match AUTH user with FROM address (11). It is usually a good idea to enable this setting to prevent internal user masquerading or malware generated messages that have hijacked some of a users credentials.
If applicable to your environment, using the interface separation method previously described, the private interface can be secured by a VPN, further reducing the possibility of any kind of identity spoofing.
Generally, an authenticated connection can be trusted as being a valid user of the system. As a trusted user it often makes sense to apply a different set of filtering rules to these users. A couple of good examples of this are the spam filter, which should not be relevant to messages from users of your system, and notifying the administrator of viruses sent from local users.
Using the policy system on conjunction with authentication, we can utilize the policy manager to create separate policies for authenticated users and unauthenticated users.
There are a myriad of configuration combinations that can be used to achieve this setup, with the most basic being as follows:
Enable SMTP AUTH (1) to turn authentication services on at the SMTP interface, preferably when encrypted.
Require inbound SMTP domain authentication (9) set to Required always. This setting requires authentication when messages sent to your domain that are also from your domain. It does not require messages from a different domain to authenticate.
Match AUTH user with FROM address (11). It's usually a good idea to enable this setting to prevent internal user masquerading or malware generated messages that have hijacked some of a user's credentials.
Create a policy, sorted at the top of your policy list, and enable the authentication criteria (settings 19/20).
Apply appropriate filters for your users to the new policy.
If you allow users to use email client apps that connect via SMTP into your email system, relaying off your server may be something that you allow them to do. Relaying is defined when the sender and recipient of an email routed through your server are not part of the local domain. We can consider unauthenticated users to not be part of your domain, because we don't trust they are valid, especially when the connection comes from outside the network.
Using authentication allows us to create a trust with the connecting client.
To provide relay services to your external users, configure these settings:
Enable SMTP AUTH (1) to turn authentication services on at the SMTP interface, preferably when encrypted.
Require inbound SMTP domain authentication (9) set to Required always. This setting requires authentication when messages sent to your domain that are also from your domain. It does not require messages from a different domain to authenticate.
Match AUTH user with FROM address (11). It's usually a good idea to enable this setting to prevent internal users masquerading or malware generated messages that have hijacked some of a user's credentials.
Enable Allow relay if authenticated (global) (7) on the SMTP interface (or limit it to an OU depending on your system needs).
SMG provides a mechanism to allow specific SMTP connections the ability to authenticate. The use case for this configuration is where your email users connect directly to your email server, bypassing SMG, and SMG protects the email system by receiving messages coming from external users.
With this email topology, there can be situations where you have specific remote networks that need to send messages from the outside into your system via SMTP.
Normally to host these specific external systems, auth can be used to protect the system, however it also opens up authentication to all users that are able to login to the system.
To solve this problem, SMG provides a slew of settings for filtering the inbound connections by email and IP addresses (settings 3/4/5/6/12/13/14/15). With authentication enabled, use the settings from this list to isolate the systems that should be allowed to gain authenticated access.
Using this method provides isolation of specific user access to the system, and it also protects your target host server by only passing through authentication requests for the users or connection addresses that are granted access.
Where you have devices and applications in your network that require an email delivery service, it can be convenient to have a shared authentication username that all of the managed devices and applications can use.
Using an internally defined SMG user, you can provided these devices the privileges they need to send mail via SMG.
Enable SMTP AUTH (1) to turn authentication services on at the SMTP interface, preferably 'when encrypted'.
Add an SMG user and enable the appropriate AUTH method (setting 18).
Configure the device/application with the email server and login credentials of the SMG server.
The privileges afforded to the device will be dependent on the other authentication settings defined.