WinGate mail security consists of two main areas of functionality:
Authentication is how the client (i.e. software sending or retrieving email) validates its identity with the server. There are a number of methods for doing this, and each method has various implications. In the main they can be classified as either secure or insecure, in terms of whether or not they transmit passwords over the network in a way that can be intercepted. The reasons for authentication for POP3 (email retrieval) are fairly obvious, since the system needs this to determine which mailbox the user is trying to access, for SMTP (email sending) this is less obvious.
The reason you may wish users to authenticate for SMTP is to make the system treat them as a trusted user. Trusted users have more privileges (like being able to send mail that requires relaying). By default, when it comes to sending mail, a user is trusted if eitherSo, if you wish users external to your network to be able to use WinGate's mail server to send mail out onto the Internet, and you do not wish to set up an assumption for their IP (it may change regularly), then authentication is the only secure way. WinGate supports the following authentication methods.
SASL (Simple Authentication and Security Layer) is a definition for a way in which authentication takes place by a certain method, so the methods PLAIN, NTLM, and CRAM-MD5 are supported for both SMTP and POP3, and furthermore for POP3 the normal USER/PASS method as well as APOP commands are supported. WinGate also allows you to specify that a connection must be secure (see below) before a certain authentication method will be allowed. This allows you to stop passwords from being sent insecurely over the network.
Depending on whether you are using the WinGate user database, or the user database of the underlying operating system (NT-based user database), various of these authentication methods are either available or not. In summary, to authenticate against the NT user database requires use of a plaintext authentication method, or the SASL NTLM method (used by Outlook). If you wish to only use the WinGate user database, then the NTLM method is not available.
In some other cases, the user account settings will also come into play. For instance, if you have specified that the user uses a POP3 override password, then if your email program uses USER/PASS method to authenticate for retrieving mail, then this password is the one that MUST be used. The normal WinGate or NT password will not work. For some other methods however, the POP3 override password is used as a second-chance check, for instance the APOP, CRAM-MD5 methods do this if you are using the NT user database. This is because these methods would otherwise not be available.
Each authentication scheme has 3 possible settings. It can be set to 'Deny', 'Allow' or 'Secure (TLS)'. Deny will block all authentication attempts that are made using that particular method. Conversely, Allow, will permit an authentication mechanism, while Secure (TLS) will allow a particular authentication scheme, as long as it takes place over an encrypted TLS/SSL connection.
Secure connections allow for a greater level of security for insecure authentication methods, since the connection is first encrypted. This allows you to use authentication methods safely where they would not be safe over an insecure connection. Furthermore the content of the email is also sent over the encrypted connection, so people sniffing network traffic on your network or on the Internet cannot see the content of your emails, as they are being sent and retrieved.
In order to use TLS support, a certificate (X.509 standard PEM format) must be available. Certificates are used to validate the authenticity of a server, and have been commonly used with secure web-servers for years. You may get WinGate to generate a certificate itself to use with mail if you wish, or in certain circumstances you may wish instead to obtain a certificate from a recognised certificate authority. If you choose the easy option of having WinGate generate its own certificate, some email clients may complain that they do not trust the certificate used by your mail server. In this case, most clients have an option whereby you can force the client to trust the certificate. So in short, you are unlikely to need to go elsewhere for a certificate unless having the mail clients manually configured to trust the certificate proves too much of a burden. There are normally costs associated with obtaining a signed certificate from a certificate agency.
Important note: When generating a certificate, you must specify a common name. This is the name attached to the certificate, which is used to identify the server. Most mail programs will complain if the name in the certificate is not the same as the name of the server they connected to. You may generate wild-card names (which match a whole range of names) as follows, for example, the Qbik mail server, uses the name
*.qbik.comThis means that if an email client connects to any name that ends in qbik.com to get their mail, then the name will match.
Finally, WinGate only supports certificates that are in a .PEM format, so if you choose to obtain a certificate from elsewhere, you may need to convert the format that they provide you with. There are many available tools that will convert certificates from other formats to this format.
This is the name by which the server is known. It defaults to the DNS name of the machine it is running on. So for example on a Windows 2000 Active Directory server this could be qbik.com, where as on older operating systems this might be WorkPC1. This is important also for certificate generation, as this name is used within the certificate generation process for the common name unless you change it, and therefore will be the name that will be displayed in peoples certificate manager programs.
Support for secure connections and/or authentication is available in many email clients, to differing levels. The following information covers some common email clients:
Supported authentication methods are:
As far as secure connections goes, Outlook supports TLS for sending mail (SMTP), but not for retrieving mail (POP3). If you specify that Outlook must use an encrypted connection for POP3, it will instead attempt to connect to a secure pop3 server (SPOP) on port 995. WinGate's TLS support for POP3 does not support this. Furthermore, Outlook is particularly lame in how it tries to authenticate if you are using the NTLM method ("secure password authentication"). It will in all cases first try to use the username and password of the currently logged in Windows user, before it will then try the username and password you specify. We hope Microsoft changes this soon!
Supported authentication methods are: