POSTFIX MAIL SERVER HOW TO
SMTP Authentication for Mail clients
This chapter deals with Authentication for mail clients that need to relay through your Postfix server. To keep in mind. There are several apps within Postfix that take care of correct mail delivery. In this chapter our focus will be on the smtpd daemon, which receives mail from clients before deciding what to do with it and passing it on to other apps.
[Note] Note
You can tell we are dealing with the smtpd, because most of our configuration settings will start with smtpd_.
1.1. Enable SASL support
To enable SASL support in Postfix we must configure some settings in the main.cf.
[root@example.com]# vi /etc/postfix/main.cf
You will notice that there is no section in the main.cf that offers preinstalled settings. Therefore we will add a new section on our own.
We add the following lines:
# SASL SUPPORT FOR CLIENTS
#
# The following options set parameters needed by Postfix to enable
# Cyrus-SASL support for authentication of mail clients.
#
1.1.1. Enable SMTP AUTH
The first thing we need to do is to tell Postfix to enable SMTP AUTH. We do this by adding the following line:
smtpd_sasl_auth_enable = yes
1.1.2. Security options
There’s a really nice, but insecure fallback feature in SMTP AUTH when authenticating. If one mechanism doesn’t work it’ll try another one. Insecure? The idea is nice, but look how it’s done…
It appears that clients try authentication methods in the order as advertised by the server (e.g., PLAIN ANONYMOUS CRAM-MD5) which means that if you disable plaintext passwords, clients will log in anonymously, even when they should be able to use CRAM-MD5. So, if you disable PLAIN logins, disable ANONYMOUS logins too. Postfix treats ANONYMOUS login as no authentication.
Since we want to use the plaintext mechanism in this HOWTO, but not anonymous we’ll simple set:
smtpd_sasl_security_options = noanonymous
This will keep Postfix from offering anonymous logins.
1.1.3. Passing the realm
When you use method sasldb Cyrus-SASL needs to know a value from a parameter that’s called realm. It’s about the same as a domain. In Cyrus-SASL this is used to authenticate users with the same username, but from different domains (e.g. joe@domain.com, joe@example.com).
Since our users don’t pass the realm when they authenticate, but Cyrus-SASL requires it in order to work properly we set a default value in Postfix. Postfix will append this when it hands over data for Cyrus-SASL to authenticate our relay-users.
In our HOWTO we’ll simply reuse a value that we’ve set when we did or first configuration:
smtpd_sasl_local_domain = $myhostname
[Note] Note
If you plan to use sasldb you might want to add this to your paper that holds the parameters that are specific to your setting.
1.1.4. Supporting non-standard mail clients
The broken_sasl_auth_clients parameter controls interoperability with SMTP clients that do not recognize that Postfix supports RFC 2554 (AUTH command). Examples of such clients are Microsoft Outlook Express version 4 and Microsoft Exchange version 5.0.
Specify yes to have Postfix also advertise SMTP AUTH in a non-standard way.
broken_sasl_auth_clients = yes
Now we have configured Postfix to enable SASL support, but one last step is still missing. We must tell Postfix that SASL authenticated clients are allowed to relay. So keep your editor on main.cf open…
1.1.5. Enable relaying for SMTP AUTH users
There are a number of values that we can add to the following parameter. For the moment we stick with a minimum to keep our setup simple and under control.
Search for relay_domains = and add the following line below:
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
check_relay_domains
1.1.6. Configuration overview
When you are done with the configurations from above, your should have added the following lines:
# SASL SUPPORT FOR CLIENTS
# The following options set parameters needed by Postfix to enable
# Cyrus-SASL support for authentication of mail clients.
#
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
broken_sasl_auth_clients = yes
…
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
check_relay_domains
If you have entered all of this you save the file. Now we will have to make Postfix reread it’s configuration.
1.2. Reload Postfix
You can always stop and start Postfix, but this takes time which you may not have when your online and your have lots of traffic. So we rather have Postfix reread it’s configuration by ordering it to reload. Still it will not deliver or receive messages while it reloads, but the downtime will be shorter.
[root@example.com]# postfix reload
postfix/postfix-script: refreshing the Postfix mail system
1.3. Check for SMTP AUTH support
So, now that we’ve have enabled SASL authentication in the configuration we need to verify that Postfix serves us the new feature. We check from a remote host and telnet to the Postfix server.
S: 220 mail.example.com ESMTP Postfix
C: EHLO example.com
S: 250-mail.example.com
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-VRFY
S: 250-ETRN
S: 250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI
S: 250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI
S: 250-XVERP
S: 250 8BITMIME
C: quit
S: 221 Bye
Notice the two new lines?
250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI
250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI
These are the lines that Postfix issues when it offers the use of SMTP AUTH and we can see two things from looking at them:
12.3.1. Fallback feature
First let us remember the insecure fallback feature:
PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI is the order of the mechanisms in which a Mail client would try to authenticate to. If SASL issued ANONYMOUS in between LOGIN and DIGEST-MD5 we’d be lost or rather an open relay to every spammer in the world who knew this feature…
1.3.2. Broken clients
Did you notice that there are two lines that only differ in an extra = in between AUTH and PLAIN. The AUTH=PLAIN statement is the one that broken clients need in order to recognize that they may use SMTP AUTH.
[Note] Note
If you don’t see all the mechanisms as pointed out in this HOWTO it means that you didn’t install or compile all the SASL mechanisms. Please make sure that you have at least the following as we are going to need them in the HOWTO: PLAIN LOGIN
1.4. Check if SMTP AUTH works
Before we start and configure a Mail client to relay mail using SMTP AUTH we do one more last check. If we pass this we know were done with server side SMTP AUTH configuration. In this step we will telnet to the server and pass our username and password just to see if we pass the authentication.
Since we use PLAIN as mechanism we will have to pass our credentials plaintext. But hold, the credentials must be Base64 encoded, when we issue them. This can easily be done on our server. The basic command looks like this:
[root@example.com]# printf ‘usernameusernamepassword’ | mmencode
If you rather use PERL it looks like this:
[root@example.com]# perl -MMIME::Base64 -e ‘print encode_base64(“usernameusernamepassword”);’
[Note] Note
Note that appears twice in between the values? Make sure you don’t forget them.
In our HOWTO we need to replace username and password with test and testpass. When we enter our command we get this:
[root@base readme]# printf ‘testtesttestpass’ | mmencode
dGVzdAB0ZXN0AHRlc3RwYXNz
So dGVzdAB0ZXN0AHRlc3RwYXNz is our Base64 encoded string that contains the username and password. Let’s check out if this works. We start as usual and initiate the SMTP AUTH session by telling Postfix that we want to AUTH and also provide the mechanism PLAIN that we want to use in this test.
S: 220 mail.example.com ESMTP Postfix (1.1.7)
C: EHLO example.com
S: 250-mail.example.com
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-VRFY
S: 250-ETRN
S: 250-AUTH DIGEST-MD5 CRAM-MD5 GSSAPI PLAIN LOGIN
S: 250-AUTH=DIGEST-MD5 CRAM-MD5 GSSAPI PLAIN LOGIN
S: 250-XVERP
S: 250 8BITMIME
C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3RwYXNz
S: 235 Authentication successful
C: QUIT
S: 221 Bye
We authenticated successfully. SMTP AUTH on server side is configured and we may now switch to a mail client thats a little more comfortable.
12.5. Configuring the Mail client
It’s impossible to provide configurations for all mail clients available, so I try this: Developers and sysadmins like to work using the CLI. Regular users like to work with a GUI. In most cases this means MS Windows© and very often it boils down to Outlook. So I will provide an example of an Outlook configuration. If you run a different mail client you’ll have to look how this is configured by yourself.
So what do we need to configure in Outlook in order to have the client authenticate itself before it tries to relay a message?
Open Extras –> Accounts –> mailaccount and switch to the server tab. Then check the box that reads: My server requires authentication.
Outlook Express: Properties for mail.example.com
That’s all there need to be done. Save the setting and send a test mail.
12.6. Summary
Well that should be about everything. If it worked out as it should, you are running a Postfix server that does SMTP AUTH for mail clients. This HOWTO told you how to ensure that only those relay who should, but not how to keep SPAM away from their accounts. So if this is your first Postfix installation and you started with this HOWTO you probably might want to read about Postfix and UCE control next.
[Note] Note
Don’t forget to set Postfix back to regular logging (edit master.cf) and you might also want to re-add your IP-range(s) to the $mynetworks parameter in main.cf.
If you want sasldb support when you SMTP AUTH clients, then you are just a few lines away from learning how to do that. Still you read all of this chapter, didn’t you? If not, do it before you switch to sasldb. You won’t be able to SMTP AUTH without enabling the Postfix-configuration we discussed in the lines above.
Prev Up Next
11. Basic Postfix configuration and preparation for SMTP AUTH Home
13. Limiting SASL mechanisms
Done......
This chapter deals with Authentication for mail clients that need to relay through your Postfix server. To keep in mind. There are several apps within Postfix that take care of correct mail delivery. In this chapter our focus will be on the smtpd daemon, which receives mail from clients before deciding what to do with it and passing it on to other apps.
[Note] Note
You can tell we are dealing with the smtpd, because most of our configuration settings will start with smtpd_.
1.1. Enable SASL support
To enable SASL support in Postfix we must configure some settings in the main.cf.
[root@example.com]# vi /etc/postfix/main.cf
You will notice that there is no section in the main.cf that offers preinstalled settings. Therefore we will add a new section on our own.
We add the following lines:
# SASL SUPPORT FOR CLIENTS
#
# The following options set parameters needed by Postfix to enable
# Cyrus-SASL support for authentication of mail clients.
#
1.1.1. Enable SMTP AUTH
The first thing we need to do is to tell Postfix to enable SMTP AUTH. We do this by adding the following line:
smtpd_sasl_auth_enable = yes
1.1.2. Security options
There’s a really nice, but insecure fallback feature in SMTP AUTH when authenticating. If one mechanism doesn’t work it’ll try another one. Insecure? The idea is nice, but look how it’s done…
It appears that clients try authentication methods in the order as advertised by the server (e.g., PLAIN ANONYMOUS CRAM-MD5) which means that if you disable plaintext passwords, clients will log in anonymously, even when they should be able to use CRAM-MD5. So, if you disable PLAIN logins, disable ANONYMOUS logins too. Postfix treats ANONYMOUS login as no authentication.
Since we want to use the plaintext mechanism in this HOWTO, but not anonymous we’ll simple set:
smtpd_sasl_security_options = noanonymous
This will keep Postfix from offering anonymous logins.
1.1.3. Passing the realm
When you use method sasldb Cyrus-SASL needs to know a value from a parameter that’s called realm. It’s about the same as a domain. In Cyrus-SASL this is used to authenticate users with the same username, but from different domains (e.g. joe@domain.com, joe@example.com).
Since our users don’t pass the realm when they authenticate, but Cyrus-SASL requires it in order to work properly we set a default value in Postfix. Postfix will append this when it hands over data for Cyrus-SASL to authenticate our relay-users.
In our HOWTO we’ll simply reuse a value that we’ve set when we did or first configuration:
smtpd_sasl_local_domain = $myhostname
[Note] Note
If you plan to use sasldb you might want to add this to your paper that holds the parameters that are specific to your setting.
1.1.4. Supporting non-standard mail clients
The broken_sasl_auth_clients parameter controls interoperability with SMTP clients that do not recognize that Postfix supports RFC 2554 (AUTH command). Examples of such clients are Microsoft Outlook Express version 4 and Microsoft Exchange version 5.0.
Specify yes to have Postfix also advertise SMTP AUTH in a non-standard way.
broken_sasl_auth_clients = yes
Now we have configured Postfix to enable SASL support, but one last step is still missing. We must tell Postfix that SASL authenticated clients are allowed to relay. So keep your editor on main.cf open…
1.1.5. Enable relaying for SMTP AUTH users
There are a number of values that we can add to the following parameter. For the moment we stick with a minimum to keep our setup simple and under control.
Search for relay_domains = and add the following line below:
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
check_relay_domains
1.1.6. Configuration overview
When you are done with the configurations from above, your should have added the following lines:
# SASL SUPPORT FOR CLIENTS
# The following options set parameters needed by Postfix to enable
# Cyrus-SASL support for authentication of mail clients.
#
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
broken_sasl_auth_clients = yes
…
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
check_relay_domains
If you have entered all of this you save the file. Now we will have to make Postfix reread it’s configuration.
1.2. Reload Postfix
You can always stop and start Postfix, but this takes time which you may not have when your online and your have lots of traffic. So we rather have Postfix reread it’s configuration by ordering it to reload. Still it will not deliver or receive messages while it reloads, but the downtime will be shorter.
[root@example.com]# postfix reload
postfix/postfix-script: refreshing the Postfix mail system
1.3. Check for SMTP AUTH support
So, now that we’ve have enabled SASL authentication in the configuration we need to verify that Postfix serves us the new feature. We check from a remote host and telnet to the Postfix server.
S: 220 mail.example.com ESMTP Postfix
C: EHLO example.com
S: 250-mail.example.com
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-VRFY
S: 250-ETRN
S: 250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI
S: 250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI
S: 250-XVERP
S: 250 8BITMIME
C: quit
S: 221 Bye
Notice the two new lines?
250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI
250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI
These are the lines that Postfix issues when it offers the use of SMTP AUTH and we can see two things from looking at them:
12.3.1. Fallback feature
First let us remember the insecure fallback feature:
PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI is the order of the mechanisms in which a Mail client would try to authenticate to. If SASL issued ANONYMOUS in between LOGIN and DIGEST-MD5 we’d be lost or rather an open relay to every spammer in the world who knew this feature…
1.3.2. Broken clients
Did you notice that there are two lines that only differ in an extra = in between AUTH and PLAIN. The AUTH=PLAIN statement is the one that broken clients need in order to recognize that they may use SMTP AUTH.
[Note] Note
If you don’t see all the mechanisms as pointed out in this HOWTO it means that you didn’t install or compile all the SASL mechanisms. Please make sure that you have at least the following as we are going to need them in the HOWTO: PLAIN LOGIN
1.4. Check if SMTP AUTH works
Before we start and configure a Mail client to relay mail using SMTP AUTH we do one more last check. If we pass this we know were done with server side SMTP AUTH configuration. In this step we will telnet to the server and pass our username and password just to see if we pass the authentication.
Since we use PLAIN as mechanism we will have to pass our credentials plaintext. But hold, the credentials must be Base64 encoded, when we issue them. This can easily be done on our server. The basic command looks like this:
[root@example.com]# printf ‘usernameusernamepassword’ | mmencode
If you rather use PERL it looks like this:
[root@example.com]# perl -MMIME::Base64 -e ‘print encode_base64(“usernameusernamepassword”);’
[Note] Note
Note that appears twice in between the values? Make sure you don’t forget them.
In our HOWTO we need to replace username and password with test and testpass. When we enter our command we get this:
[root@base readme]# printf ‘testtesttestpass’ | mmencode
dGVzdAB0ZXN0AHRlc3RwYXNz
So dGVzdAB0ZXN0AHRlc3RwYXNz is our Base64 encoded string that contains the username and password. Let’s check out if this works. We start as usual and initiate the SMTP AUTH session by telling Postfix that we want to AUTH and also provide the mechanism PLAIN that we want to use in this test.
S: 220 mail.example.com ESMTP Postfix (1.1.7)
C: EHLO example.com
S: 250-mail.example.com
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-VRFY
S: 250-ETRN
S: 250-AUTH DIGEST-MD5 CRAM-MD5 GSSAPI PLAIN LOGIN
S: 250-AUTH=DIGEST-MD5 CRAM-MD5 GSSAPI PLAIN LOGIN
S: 250-XVERP
S: 250 8BITMIME
C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3RwYXNz
S: 235 Authentication successful
C: QUIT
S: 221 Bye
We authenticated successfully. SMTP AUTH on server side is configured and we may now switch to a mail client thats a little more comfortable.
12.5. Configuring the Mail client
It’s impossible to provide configurations for all mail clients available, so I try this: Developers and sysadmins like to work using the CLI. Regular users like to work with a GUI. In most cases this means MS Windows© and very often it boils down to Outlook. So I will provide an example of an Outlook configuration. If you run a different mail client you’ll have to look how this is configured by yourself.
So what do we need to configure in Outlook in order to have the client authenticate itself before it tries to relay a message?
Open Extras –> Accounts –> mailaccount and switch to the server tab. Then check the box that reads: My server requires authentication.
Outlook Express: Properties for mail.example.com
That’s all there need to be done. Save the setting and send a test mail.
12.6. Summary
Well that should be about everything. If it worked out as it should, you are running a Postfix server that does SMTP AUTH for mail clients. This HOWTO told you how to ensure that only those relay who should, but not how to keep SPAM away from their accounts. So if this is your first Postfix installation and you started with this HOWTO you probably might want to read about Postfix and UCE control next.
[Note] Note
Don’t forget to set Postfix back to regular logging (edit master.cf) and you might also want to re-add your IP-range(s) to the $mynetworks parameter in main.cf.
If you want sasldb support when you SMTP AUTH clients, then you are just a few lines away from learning how to do that. Still you read all of this chapter, didn’t you? If not, do it before you switch to sasldb. You won’t be able to SMTP AUTH without enabling the Postfix-configuration we discussed in the lines above.
Prev Up Next
11. Basic Postfix configuration and preparation for SMTP AUTH Home
13. Limiting SASL mechanisms
Done......
1 comment:
Thanks for the info and good work ..
Thumps up
Post a Comment