Difference between revisions of "Saslauthd"
(→Postfix SASL) |
|||
| Line 14: | Line 14: | ||
If all of your email users are on the same network, within the same gateway as your mail server, then you can simply allow relaying of mail based on your subnet and SASL is not necessary. If you have users outside of your network that connect from a variety of networks, some users having dynamic IP addresses, and perhaps users on an ISP that doesn't offer an open port 25 relay, then SASL is a good solution for you. SASL is able to provide a mechanism to authenticate remote users by username and password who wish to send mail through the mail server. | If all of your email users are on the same network, within the same gateway as your mail server, then you can simply allow relaying of mail based on your subnet and SASL is not necessary. If you have users outside of your network that connect from a variety of networks, some users having dynamic IP addresses, and perhaps users on an ISP that doesn't offer an open port 25 relay, then SASL is a good solution for you. SASL is able to provide a mechanism to authenticate remote users by username and password who wish to send mail through the mail server. | ||
| + | |||
| + | === Encryption === | ||
| + | |||
| + | SASL is able to provide a mechanism to authenticate remote users by username and password trying to relay mail. The mechanism has users sending their authentication information as plain unencrypted text. Because packets can be intercepted, and the username password combinations easily read, there is a need to encrypt the connection. Encryption options include SSL (Secure Sockets Layer) or TLS (Transport Layer Security) - note that SSL was renamed TLS by the IETF as of version 3.1. | ||
| + | |||
| + | |||
Revision as of 12:04, 7 February 2014
SASL (Simple Authentication and Security Layer) is a framework for authentication and data security in Internet protocols. To use the SASL specification, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating a security layer for subsequent protocol interactions. The command has a required argument identifying a SASL mechanism.
Postfix SASL
SMTP servers need to decide whether an SMTP client is authorized to send mail to a remote host, which are email accounts not on the local server itself. Postfix supports SASL authentication so that a remote SMTP client can authenticate to the Postfix SMTP server, and the Postfix SMTP client can authenticate to a remote SMTP server.
The goal is to allow users to log in to the local mail server so they can send emails. Users will use the same username and password as the one they will be using for checking email. POP3 and IMAP users that have already logged in to check email will be authenticated.
The Postfix SMTP server is linked with the Cyrus SASL library libsasl allowing communication between Postfix and Cyrus SASL to take place by calling functions in the SASL library. The SASL library may use an external password verification service, or an internal plugin to connect to authentication backends and verify the SMTP client's authentication data against the system password file or other databases, such as mysql. Communication between the Postfix SMTP server and the saslauthd server takes place over a UNIX-domain socket.
Who needs SASL
If all of your email users are on the same network, within the same gateway as your mail server, then you can simply allow relaying of mail based on your subnet and SASL is not necessary. If you have users outside of your network that connect from a variety of networks, some users having dynamic IP addresses, and perhaps users on an ISP that doesn't offer an open port 25 relay, then SASL is a good solution for you. SASL is able to provide a mechanism to authenticate remote users by username and password who wish to send mail through the mail server.
Encryption
SASL is able to provide a mechanism to authenticate remote users by username and password trying to relay mail. The mechanism has users sending their authentication information as plain unencrypted text. Because packets can be intercepted, and the username password combinations easily read, there is a need to encrypt the connection. Encryption options include SSL (Secure Sockets Layer) or TLS (Transport Layer Security) - note that SSL was renamed TLS by the IETF as of version 3.1.
