Difference between revisions of "Postfix: Authentikasi SMTP untuk Client"

From OnnoWiki
Jump to navigation Jump to search
Line 2: Line 2:
  
  
−
12. SMTP Authentication for Mail clients
 
−
Prev Next
 
−
12. 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.
+
How to enable user authentication for a Postfix SMTP server with SASL
−
[Note] Note
+
Last updated on January 28, 2014 Authored by Sarmed Rahman 4 Comments
  
−
You can tell we are dealing with the smtpd, because most of our configuration settings will start with smtpd_.
+
Every mail server administrator dreads his or her server becoming compromised by spammers. A lot of effort, time and even money is spent on securing mail servers and making sure that the servers do not become open relay.
−
12.1. Enable SASL support
 
  
−
To enable SASL support in Postfix we must configure some settings in the main.cf.
+
To combat against spambots in an SMTP server, Postfix in general uses the mynetworks parameter to specify the trusted sender network i.e., LAN. In a typical scenario, the users stationed in the internal LAN are legitimate users, and Postfix will happily accept SMTP requests from them, and forward the emails towards destination. Although this used to be the standard practice in the past, today's users want mobility. Everyone wants to be able to send/receive emails in their phones/tablets/laptops at work, home, on the go, or even from their favorite coffee shop around the corner. For people who are in the fields for critical services, a simple email alert could save a lot of time, effort and money.
  
−
[root@example.com]# vi /etc/postfix/main.cf
+
To cope up with the mobility need, Postfix started to support another method of validating users. Simple Authentication and Security Layer (SASL) is a framework that can be used by many connection-oriented Internet protocols for securing data, servers and users. With SASL enabled, Postfix will not accept any incoming SMTP connections without proper authentication. As smart spammer can imitate a legitimate email account, no SMTP from even internal users are accepted without authentication.
  
−
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.
+
This tutorial will focus on setting up a Postfix SMTP server to use Dovecot SASL for user authentication. As Dovecot provides mechanisms for user authentication, Postfix will simply ask Dovecot to do the work for it. That way, there is no need to re-invent the wheel.
 +
Prerequisites
  
−
We add the following lines:
+
    A working mail server running on postfix and dovecot2
 +
    SSL/TLS support for the mail server3
  
−
# SASL SUPPORT FOR CLIENTS
+
Preparing Dovecot
−
#
 
−
# The following options set parameters needed by Postfix to enable
 
−
# Cyrus-SASL support for authentication of mail clients.
 
−
#
 
  
−
12.1.1. Enable SMTP AUTH
+
Backing up configuration files prior to modification is always a good idea.
  
−
The first thing we need to do is to tell Postfix to enable SMTP AUTH. We do this by adding the following line:
+
Since Dovecot will be the one doing most of the work, we will start configuration with Dovecot.
  
−
smtpd_sasl_auth_enable = yes
+
First of all, a listener is added to Dovecot. Postfix will use this listener to communicate with Dovecot.
−
 
+
root@mail:~# vim /etc/dovecot/conf.d/10-master.conf
−
12.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...
+
## The listener is added under the service auth section ##
 +
service auth {
 +
unix_listener /var/spool/postfix/private/auth {
 +
mode = 0660
 +
        user = postfix
 +
        group = postfix
 +
  } ##end listener
 +
} ## end service auth
  
−
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.
+
The above definition places the socket to be used by Postfix at /var/spool/postfix/private/auth with permission 0660 for Postfix only.
 +
root@mail:~# vim /etc/dovecot/conf.d/10-auth.conf
  
−
Since we want to use the plaintext mechanism in this HOWTO, but not anonymous we'll simple set:
+
auth_mechanisms = plain login
  
−
smtpd_sasl_security_options = noanonymous
+
The above parameter provides the plain login authentication mechanisms for Postfix.
  
−
This will keep Postfix from offering anonymous logins.
+
Finally, for the changes to take effect, we restart the Dovecot service as follows.
−
12.1.3. Passing the realm
+
root@mail:~# service dovecot restart
  
−
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).
+
Preparing Postfix
  
−
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.
+
Necessary SST/TLS and SASL parameters are added in the configuration file main.cf.
 +
root@mail:~# vim /etc/postfix/main.cf
  
−
In our HOWTO we'll simply reuse a value that we've set when we did or first configuration:
+
#### SASL ####
 +
## specify SASL type ##
 +
smtpd_sasl_type = dovecot
  
−
smtpd_sasl_local_domain = $myhostname
+
## path to the SASL socket relative to postfix spool directory i.e. /var/spool/postfix ##
 +
smtpd_sasl_path = private/auth
  
−
[Note] Note
+
## postfix appends the domain name for SASL logins that do not have the domain part ##
 +
smtpd_sasl_local_domain = example.tst
  
−
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.
+
## SASL default policy ##
−
12.1.4. Supporting non-standard mail clients
+
smtpd_sasl_security_options = noanonymous
−
 
 
−
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.
 
  
 +
## for legacy application compatibility ##
 
broken_sasl_auth_clients = yes
 
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...
+
## enable SMTP auth ##
−
12.1.5. Enable relaying for SMTP AUTH users
+
smtpd_sasl_auth_enable = yes
−
 
 
−
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
 
  
−
12.1.6. Configuration overview
+
## smtp checks ##
 +
## these checks are based on first match, so sequence is important ##
 +
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
  
−
When you are done with the configurations from above, your should have added the following lines:
+
The official guideline can be consulted for more details on available parameters and their function.
−
 
 
−
# 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.
+
SSL/TLS specific parameters are added to the server as well.
−
12.2. Reload Postfix
+
root@mail:~# vim /etc/postfix/main.cf
  
−
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.
+
#### SSL/TLS parameters ####
  
−
[root@example.com]# postfix reload
+
## 'encrypt' will enforce SSL. Not recommended for live servers ##
−
postfix/postfix-script: refreshing the Postfix mail system
+
smtpd_tls_security_level = may
 +
#smtpd_tls_security_level = encrypt
  
−
12.3. Check for SMTP AUTH support
+
smtpd_tls_received_header = yes
 +
smtpd_tls_auth_only = no
  
−
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.
+
## loglevel 3 or 4 can be used during troubleshooting ##
 +
smtpd_tls_loglevel = 1
  
−
S: 220 mail.example.com ESMTP Postfix
+
## path to certificate and key file ##
−
C: EHLO example.com
+
smtpd_tls_cert_file = /etc/ssl/certs/postfixcert.pem
−
S: 250-mail.example.com
+
smtpd_tls_key_file = /etc/ssl/private/postfixkey.pem
−
S: 250-PIPELINING
+
smtpd_use_tls=yes
−
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?
+
## server will announce STARTTLS ##
 +
smtp_tls_note_starttls_offer = yes
  
−
250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5 GSSAPI
+
smtpd_tls_session_cache_timeout = 3600s
−
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:
+
Now Postfix is reloaded with updated settings.
−
12.3.1. Fallback feature
+
root@mail:~# service postfix restart
  
−
First let us remember the insecure fallback feature:
+
At this point, Postfix will not allow SMTP connections without authentication.
 +
Mail User Agent Configuration
  
−
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...
+
Your mail client is configured with mandatory authentication for SMTP as shown below.
−
12.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.
+
Troubleshooting
−
[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
+
If SASL is not working correctly, the following troubleshooting may help.
−
12.4. Check if SMTP AUTH works
+
Enabling Verbose Postfix Logs
  
−
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.
+
To increase the level of output in Postfix log, the "-v" parameter can be added in the following file.
 +
root@mail:/etc/postfix# vim /etc/postfix/master.cf
  
−
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:
+
smtp      inet  n      -      -      -      -      smtpd -v
  
−
[root@example.com]# printf 'username\0username\0password' | mmencode
+
Now there should be more verbose information the log file at /var/log/mail.log, which can help with the troubleshooting process.
 +
Telnet to port 25
  
−
If you rather use PERL it looks like this:
+
telnet connection to port 25 should be successful.
 +
$ telnet mail.example.tst 25
  
−
[root@example.com]# perl -MMIME::Base64 -e 'print encode_base64("username\0username\0password");'
+
ehlo  mail.example.tst
 +
250- mail.example.tst
 +
250-PIPELINING
 +
250-SIZE 10240000
 +
250-VRFY
 +
250-ETRN
 +
250-STARTTLS
 +
250-AUTH PLAIN LOGIN
 +
250-AUTH=PLAIN LOGIN
 +
250-ENHANCEDSTATUSCODES
 +
250-8BITMIME
 +
250 DSN
  
−
[Note] Note
+
Amongst other features that the SMTP server advertises, the STARTTLS and AUTH features should be available.
  
−
Note that \0 appears twice in between the values? Make sure you don't forget them.
+
Sending mails using telnet should fail, and no authentication information should be sent to the server.
 +
$ telnet mail.example.tst 25
  
−
In our HOWTO we need to replace username and password with test and testpass. When we enter our command we get this:
+
ehlo  mail.example.tst
 +
mail from:sarmed@example.tst
 +
250 2.1.0 Ok
 +
rcpt to:sarmed@example.tst
 +
554 5.7.1 : Relay access denied
  
−
[root@base readme]# printf 'test\0test\0testpass' | mmencode
+
Tuning parameter – mynetworks
−
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.
+
Earlier in the tutorial, the Postfix server was configured to allow SMTP connections originated in the trusted network i.e., mynetworks, as shown in /etc/postfix/main.cf.
  
−
S: 220 mail.example.com ESMTP Postfix (1.1.7)
+
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
−
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.
+
To make sure that mails originating from mynetworks do not pass through unauthenticated, /etc/postfix/main.cf can be modified as follows.
−
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.
+
smtpd_recipient_restrictions = permit_sasl_authenticated, reject_unauth_destination
  
−
So what do we need to configure in Outlook in order to have the client authenticate itself before it tries to relay a message?
+
Based on the requirements, permit_mynetworks can be allowed or denied later on.
  
−
Open Extras --> Accounts --> mailaccount and switch to the server tab. Then check the box that reads: My server requires authentication.
+
To sum up, SASL can provide additional security to a mail server by enforcing mandatory authentication to users for SMTP requests. As users may use a mail server from anywhere, SASL can meet with the security requirements that do not conflict with the mobility of users.
  
−
Outlook Express: Properties for mail.example.com
+
Hope this helps.
  
−
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.
 
  
  

Revision as of 13:52, 2 May 2015

Sumber: http://postfix.state-of-mind.de/patrick.koetter/smtpauth/smtp_auth_mailclients.html


How to enable user authentication for a Postfix SMTP server with SASL Last updated on January 28, 2014 Authored by Sarmed Rahman 4 Comments

Every mail server administrator dreads his or her server becoming compromised by spammers. A lot of effort, time and even money is spent on securing mail servers and making sure that the servers do not become open relay.

To combat against spambots in an SMTP server, Postfix in general uses the mynetworks parameter to specify the trusted sender network i.e., LAN. In a typical scenario, the users stationed in the internal LAN are legitimate users, and Postfix will happily accept SMTP requests from them, and forward the emails towards destination. Although this used to be the standard practice in the past, today's users want mobility. Everyone wants to be able to send/receive emails in their phones/tablets/laptops at work, home, on the go, or even from their favorite coffee shop around the corner. For people who are in the fields for critical services, a simple email alert could save a lot of time, effort and money.

To cope up with the mobility need, Postfix started to support another method of validating users. Simple Authentication and Security Layer (SASL) is a framework that can be used by many connection-oriented Internet protocols for securing data, servers and users. With SASL enabled, Postfix will not accept any incoming SMTP connections without proper authentication. As smart spammer can imitate a legitimate email account, no SMTP from even internal users are accepted without authentication.

This tutorial will focus on setting up a Postfix SMTP server to use Dovecot SASL for user authentication. As Dovecot provides mechanisms for user authentication, Postfix will simply ask Dovecot to do the work for it. That way, there is no need to re-invent the wheel. Prerequisites 

   A working mail server running on postfix and dovecot2
   SSL/TLS support for the mail server3

Preparing Dovecot

Backing up configuration files prior to modification is always a good idea.

Since Dovecot will be the one doing most of the work, we will start configuration with Dovecot.

First of all, a listener is added to Dovecot. Postfix will use this listener to communicate with Dovecot. root@mail:~# vim /etc/dovecot/conf.d/10-master.conf

    1. The listener is added under the service auth section ##

service auth { unix_listener /var/spool/postfix/private/auth { mode = 0660 

       	user = postfix
       	group = postfix
 	} ##end listener

} ## end service auth

The above definition places the socket to be used by Postfix at /var/spool/postfix/private/auth with permission 0660 for Postfix only. root@mail:~# vim /etc/dovecot/conf.d/10-auth.conf

auth_mechanisms = plain login

The above parameter provides the plain login authentication mechanisms for Postfix.

Finally, for the changes to take effect, we restart the Dovecot service as follows. root@mail:~# service dovecot restart

Preparing Postfix

Necessary SST/TLS and SASL parameters are added in the configuration file main.cf. root@mail:~# vim /etc/postfix/main.cf

        1. SASL ####
    2. specify SASL type ##

smtpd_sasl_type = dovecot

    1. path to the SASL socket relative to postfix spool directory i.e. /var/spool/postfix ##

smtpd_sasl_path = private/auth

    1. postfix appends the domain name for SASL logins that do not have the domain part ##

smtpd_sasl_local_domain = example.tst

    1. SASL default policy ##

smtpd_sasl_security_options = noanonymous

    1. for legacy application compatibility ##

broken_sasl_auth_clients = yes

    1. enable SMTP auth ##

smtpd_sasl_auth_enable = yes

    1. smtp checks ##
    2. these checks are based on first match, so sequence is important ##

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

The official guideline can be consulted for more details on available parameters and their function.

SSL/TLS specific parameters are added to the server as well. root@mail:~# vim /etc/postfix/main.cf

        1. SSL/TLS parameters ####
    1. 'encrypt' will enforce SSL. Not recommended for live servers ##

smtpd_tls_security_level = may

  1. smtpd_tls_security_level = encrypt

smtpd_tls_received_header = yes smtpd_tls_auth_only = no

    1. loglevel 3 or 4 can be used during troubleshooting ##

smtpd_tls_loglevel = 1

    1. path to certificate and key file ##

smtpd_tls_cert_file = /etc/ssl/certs/postfixcert.pem smtpd_tls_key_file = /etc/ssl/private/postfixkey.pem smtpd_use_tls=yes

    1. server will announce STARTTLS ##

smtp_tls_note_starttls_offer = yes

smtpd_tls_session_cache_timeout = 3600s

Now Postfix is reloaded with updated settings. root@mail:~# service postfix restart

At this point, Postfix will not allow SMTP connections without authentication. Mail User Agent Configuration

Your mail client is configured with mandatory authentication for SMTP as shown below.

Troubleshooting

If SASL is not working correctly, the following troubleshooting may help. Enabling Verbose Postfix Logs

To increase the level of output in Postfix log, the "-v" parameter can be added in the following file. root@mail:/etc/postfix# vim /etc/postfix/master.cf

smtp inet n - - - - smtpd -v

Now there should be more verbose information the log file at /var/log/mail.log, which can help with the troubleshooting process. Telnet to port 25

telnet connection to port 25 should be successful. $ telnet mail.example.tst 25

ehlo mail.example.tst 250- mail.example.tst 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN

Amongst other features that the SMTP server advertises, the STARTTLS and AUTH features should be available.

Sending mails using telnet should fail, and no authentication information should be sent to the server. $ telnet mail.example.tst 25

ehlo mail.example.tst mail from:sarmed@example.tst 250 2.1.0 Ok rcpt to:sarmed@example.tst 554 5.7.1 : Relay access denied

Tuning parameter – mynetworks

Earlier in the tutorial, the Postfix server was configured to allow SMTP connections originated in the trusted network i.e., mynetworks, as shown in /etc/postfix/main.cf.

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

To make sure that mails originating from mynetworks do not pass through unauthenticated, /etc/postfix/main.cf can be modified as follows.

smtpd_recipient_restrictions = permit_sasl_authenticated, reject_unauth_destination

Based on the requirements, permit_mynetworks can be allowed or denied later on.

To sum up, SASL can provide additional security to a mail server by enforcing mandatory authentication to users for SMTP requests. As users may use a mail server from anywhere, SASL can meet with the security requirements that do not conflict with the mobility of users.

Hope this helps.






Referensi

Retrieved from "https://onnocenter.or.id/wiki/index.php?title=Postfix:_Authentikasi_SMTP_untuk_Client&oldid=42847"