postfix / dovecot / saslauth


I have configured postfix, dovecot, saslauth, everything is working as it should, postfix is using port 465 to send emails, dovecot is using port 993 to pull e-mails. However, mail server is using ssl certificate to send/receive mails. In /etc/postfix/ I have

smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_tls_auth_only = yes
smtpd_sasl_auth_enable = yes

when I do # telnet localhost 25
ehlo localhost 25

I see 250-STARTTLS, but there is no:

Does this mean that I establish secure connection to my server-box from remote destination, and sending username/password in “plain” not secured way?

I am not totally sure about it but I think this is how things are:

If you use port 465 for sending with your client, the connection will be encrypted (client - mail server). Also with “pulling”.

On the other hand on port 25 the tls is advertised but NOT enforced. I think that is documented in postfix manual and it’s based on a RFC which says that this option should NOT be used in case of a publicly-referenced SMTP server.

Since you have smtpd_tls_auth_only = yes the AUTH(user name and password will be done only through secure layer, i.e. the server will NOT ask for AUTH before the secure layer is established but after TLS).



Thank you for your answer. I believe dovecot has saslauth built in mechanism. :
How would it be possible to force users to use only 465 port in their e-mail clients for outgoing server, now email can be send out with 25 and 465.
What type of rule should I add to postfix/ to force only 465 port to be used for remote e-mail clients?

Doing a search on google: Dovecot SASL support is available in Postfix 2.3 and later.

I just noticed that you said that you do not see the relevant TLS lines when you telnet.

Could you try and change the order like this:

smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination

And after postfix restart see with telnet if the banner changed.

Some more info here: Postfix-SMTP-AUTH-TLS-Howto (but with cyrus-sasl)

If you did not these two should be done also:

postconf -e 'smtpd_sasl_security_options = noanonymous'
postconf -e 'broken_sasl_auth_clients = yes'

I do not think that you can force the clients to use the encrypted connection with

(“smtpd_tls_security_level = encrypt” or the obsolete “smtpd_enforce_tls = yes”),
if you do not have two mailservers: one for your clients only and one for the internet.

If all your clients are on a LAN I guess you could redirect them to the right connection but still they have to configure their e-mail clients accordingly.

Cheers and good luck.

I have figured out most of it, but still not so sure about difference between: smtpd_sender_restrictions vs smtpd_recipient_restrictions vs smtpd_client_restriction :\

Glad you’re on the right track. :slight_smile:

All those are restrictions that can appear in one of the communication steps.

First one is related to who is allowed to use MAIL FROM command (I think default is to allow everyone, tweaks are for UCE/spam control, etc.), e.g. reject_unknown_sender_domain

Have a look at this for a nice explanation: Postfix SMTP relay and access control



I still find strange that I can send an e-mail from remote location to my server just with server name “” without username and password :open_mouth:
However, if I want to send from same/remote location through “mail server (postfix)” to third party I need to provide username and password which is great.

How to force mail server (postfix) to ask for username and password when sending from remote location to mail server box? I don’t like that postfix is accepting mail for local delivery without username and password when “” is used as outgoing mail server from remote location :\


To reject all SMTP connections from unauthenticated clients, specify "smtpd_delay_reject = yes" (which is the default) and use:

smtpd_client_restrictions = permit_sasl_authenticated, reject

Of course, you would add permit_mynetworks in front.

The problem with this is if you are operating a normal mail site, it will reject all incoming mail from unauthenticated clients. But maybe you are just operating a private mail server and relay.


Thank you for a quick reply. YES, I’m operating a normal e-mail site. So there is no solution to my last post? If I still want to operate normal e-mail site, I need to leave the settings the way they are or e-mail server will not function to accept e-mails from “normal users” senders?

If you think about it, you are asking for a contradiction. Because in SMTP authentication comes before the recipient address is specified, at the authentication step you don’t know whether the destination is local or remote. By the time the recipient address is supplied, authentication has already happened, or not. So you can only allow anybody to send something to an internal mailbox. As for relaying, if no authentication is provided, it is disallowed.

However, this is for the normal port 25. If you have another listener at port 465 using TLS, you can require all clients authenticate before it can be used. But the clients have to choose to use this alternate port.


Just to verify if I understand, I’ll give an example.

“John Smith” want to send an e-mail to user on my e-mail box.
For sending an e-mail he only needs to specify “” as outgoing server (smtp) in his e-mail client (Thunderbird) and e-mail address of a user that is using address “”, “John Smith” doesn’t need user name, and a password.
“John Smith” would need to provide username, and a password only if sending to third party e-mail address which is not registered in my e-mail box. ("

P.S. What I find “strange” is that “John Smith” doesn’t need to list his own outgoing mail server (smtp) in his e-mail client (Thunderbird), his e-mail client will send out mail with name of “myhostname” :\

Think of it another way. John Smith is either one of your people or he’s not.

If he’s not, then he can only send email to a user on your system. This is the normal way for incoming mail.

If he is one of your people, then if he has to authenticate to be allowed to use postfix to relay mail to the outside. This is the case for a road warrior sending mail from working away from the office.

I don’t understand your PS. That sounds like an email client setup issue, and not your problem.

P.S. What I find “strange” is that “John Smith” doesn’t need to list his own outgoing mail server (smtp) in his e-mail client (Thunderbird), his e-mail client will send out mail with name of “myhostname” :\

My question is how to prevent (or impose username and password) “John Smith” using “”, as outgoing smtp in his e-mail client (Thunderbird)when sending e-mails to our server?

Well if his mail is for your domain, why do you want to stop him from doing that? Essentially from the point of your postfix, there is no difference from a Thunderbird connecting to your server to give it mail from another postfix passing on mail for your domain.

People outside your domain will not want to use your postfix as the outgoing smtp server if you have set it up correctly because it should ask them to authenticate to prove that they are one of your people. So why would outside people want to use your server as the outgoing smtp server if they get mail to other destinations rejected.

If an outsider is able to send mail to other outside destinations without authentication, then you have set up the checking wrong, and you should fix it up right away, because you are an open relay.


The mail server needs “auth” before third party would be able to send any e-mails out, it is also closed relay. Thank you for explanation. :slight_smile:


smtpd_use_tls = yes
smtpd_tls_auth_only = no
smtpd_recipient_restrictions =
smtp_use_tls = yes
smtp_tls_note_starttls_offer = yes
tls_random_source = dev:/dev/urandom


smtpd_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/passwd
#smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_local_domain =

SUSE LINUX Enterprise & openSUSE Community - Index