Mail Server setup questions

I’ve been trying to set up a mail server using postfix and dovecot (both installed via Yast), in some areas it’s working ok but not in others

I have a number of questions to address but so as not to be too confusing I’ll try them one at a time

Firstly, I can send mails to addresses located on other domains just fine from the lan, but if someone outside of the lan tries they can only send to address located on the local machine

A friend who has an account on the machine has been helping me test and this is what we get if he tries sending to an address on a different domain:

Dec 27 08:44:36 beastie postfix/smtpd[12764]: NOQUEUE: reject: RCPT from[IP]: 554 5.7.1 <address@external.domain>: Relay access denied; from=<user@local.domain> to=<address@external.domain proto=SMTP helo=<user9d02af5fab>

I’ve tried going through the postfix and dovecot confs to find the problem as well as using webmail to look and change things, but I just can’t see what I’m doing wrong

I’ve only ever set up a mail server on windoze before, never no linux so on this consider me a newb

I’m running the 64 bit version of Suse 11

Any help appreciated

Yes, this is the way it’s supposed to be. If you were to allow external users to relay mail through your machine to external addresses, and if a spammer got wind of this, then your machine will be in very short order exploited as a spam relay. Think about it a bit.

To prevent this, you must authenticate external users, who are presumably road warriors or trusted associates. This means setting up SMTP authentication, and since authentication should not send passwords in plaintext, this means also setting up SMTP over SSL.

Hi ken

In webmin’s postfix config screen there’s a section on SMTP Authentication And Encryption and in there are these settings:

Allow authenticated clients - which I enabled
Reject email to other domains - which I disabled

To my way of thinking, that’s pretty much what I want it to do, allow people who’ve successfully logged in to send mail to any address they like

Logically speaking allowing authenticated clients would mean not allowing any clients that hadn’t authenticated

Curiously though these values keep resetting to the opposite of what I’m setting them to, maybe they rely on something I don’t have set?

Mail from anyonymous logins and clients with no reverse hostname are also rejected

I’m not really sure what you mean by setting up smtp authentication, it already requires the clients to login with their username and password

I thought it would be possible to set things up without ssl and have a go at setting up the ssl later once things were working as it’s something I’ve never done before, is there much to that?

It would be pretty pointless having a mail address that can only send to addresses on the same machine so I’d really like to get this part at least resolved

I do see your point about spammers (who wouldn’t in this day and age), and some of the other questions I haven’t asked yet relate to that

I don’t use webmin so you are on your own on that aspect.

You can tell postfix to accept mail for a list of domains (and also subdomains of those if desired). This handles the case where postfix handles both and, also when it is the MX for as well. The setting is mydestination and also parent_domain_matches_subdomains which is a list of maps where this is allowed.

Generally one would set up postfix to not require login for LAN machines and require login for all other machines (if access is allowed at all). Some sites however require login always, as you have done. It does provide a little bit of protection against a maiware infected machine sending spam, but mailware has also been getting smarter at using system settings for sending out email.

To allow authenticated clients to relay, you specify in smtpd_recipient_restrictions the directive permit_sasl_authenticated ahead of reject_unauth_destination. That allows authenticated clients to relay. You should be able to find a complete suggested list for smtpd_recipient_restrictions in a tute on setting up auth for Postfix.

I’m about to look up and read some more about smtpd_recipient_restrictions, but I just spotted something else in the conf and I’m wondering if it would be of use here

smtpd_sender_restrictions = hash:/etc/postfix/access

It seems you can use it to allow access based on mail domains and also makes use of the parent_domain_matches_subdomains that you mentioned

Do you think using that to allow from my mail domain would be helpful given that I’ve set it so all clients have to authenticate?

Webmin btw I installed 2 days ago for a look because I came across a lot of references to it when searching for info on setting up the mail server, a lot of people seem to use it so I got curious

I can see why people use it but to my mind by the time you’ve logged in and found what you’re looking for you could have edited the setting in a conf half a dozen times


I’ve moved on some but hit a bit of a brick wall

Following the info on this page: Postfix SASL Howto

I added the following to dovecot.conf:

auth default {
mechanisms = plain login
passdb pam {
userdb passwd {
socket listen {
client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix

On restarting dovecot I get an error that private/auth doesn’t exist:

Dec 28 14:48:37 beastie postfix/smtpd[3138]: warning: SASL: Connect to private/auth failed: No such file or directory
Dec 28 14:48:37 beastie postfix/smtpd[3138]: fatal: no SASL authentication mechanisms
Dec 28 14:48:38 beastie postfix/master[5345]: warning: process /usr/lib/postfix/smtpd pid 3138 exit status 1
Dec 28 14:48:38 beastie postfix/master[5345]: warning: /usr/lib/postfix/smtpd: bad command startup – throttling
Dec 28 14:49:01 beastie dovecot: Killed with signal 15

Checked in /var/spool/postfix/private/ and there isn’t a file or folder called auth, I’m assuming it should be a file that handles the authentication process

There is no file called auth anywhere on the system, there are some directories called auth but none of them relate to postfix, dovecot or anything else to do with mail

Any ideas as to why this would be missing and/or how to go about fixing things so it’s there (or somewhere, anywhere will do!)

There’s also some stuff about sasl auth realms in the conf but I don’t really know whether I need to add anything for these and if I do there isn’t really much to indicate exactly what I should add there

I’m not sure whether this is driving me nuts or I’m just going nuts now!

I had the ‘bright’ idea of trying it using the dovecot-auth file, but that file has disappeared :expressionless:

It WAS there because I checked for it when I set the auth_executable = /usr/lib/dovecot/dovecot-auth parameter
But now it isn’t

I’m thinking I might be best off reinstalling and starting again

Definitely something going completely wrong

I managed to get the dovecot-auth file back by updating dovecot in yast, the same process didn’t work for getting postfix’s auth file back

However if I restart dovecot, the dovecot-auth file disappears again

I’ve decided to remove everything and do a reinstall then start again from scratch because I seem to be getting nowhere fast with this

I’ll let you know how that goes

That auth file is a Unix socket that dovecot creates to allow postfix to communicate with it and send authentication requests. If it isn’t there, then dovecot hasn’t been configured to use it. Its path is specified under the section socket listen -> client -> path. You may want to use an absolute path. Also be careful if dovecot runs chrooted in which case the socket is actually relative to the new root.


The postfix docs say the following with regards to sasl with postfix and dovecot:

    auth default {
      mechanisms = plain login
      passdb pam {
      userdb passwd {
      socket listen {
        client {
          path = /var/spool/postfix/private/auth
          mode = 0660
          user = postfix
          group = postfix

The file /var/spool/postfix/private/auth didn’t exist on my system nor was it being created as a socket or in any other way, I just kept getting an error that it didn’t exist

No auth file existed anywhere on my system so I thought it’s not a case of just changing the path to it

That’s when I tried substituting it for the dovecot-auth, it was a ‘don’t know if it will work unless I try it’ moment, it didn’t work and was giving me much the same error

I figured if the docs were telling me to use a file and it didn’t exist there must be some sort of problem so I decided to reinstall to see if it was then able to find the file

I reinstalled with postfix 2.5.1 from the opensuse build service mail server repository, still isn’t a file /var/spool/postfix/private/auth, but I haven’t even got far enough to worry about that this time round

I haven’t been able to get it working at all, even for sending mail between local accounts

I’ve followed god knows how many tutorials, most of which pretty much say that all you have to do is add your myhostname and mydomain info and it should then work, mine doesn’t

This is the sort of error I get when trying to send from one local account to another:

Dec 29 16:47:12 beastie postfix/qmgr[7532]: CEB2C11919A: from=<>, size=503, nrcpt=1 (queue active)
Dec 29 16:47:12 beastie postfix/smtp[19649]: connect to[]:10024: Connection refused
Dec 29 16:47:12 beastie postfix/smtp[19649]: 87E07119195: to=<>, relay=none, delay=72975, delays=72975/0.01/0/0, dsn=4.4.1, status=deferred (connect to[]:10024: Connection refused)

(obviously it’s a real domain not actually

Connection refused isn’t really much to go on for finding where the problem is, and I doubt anyone could tell me where I’m going wrong from that alone

Should I post the settings in my my file?

Try to figure out why that socket isn’t created. Did you actually start dovecot? Did you do:

/etc/init.d/dovecot start

Remember dovecot is a separate service, it provides imap and pop.

The postfix and dovecot on the DVD work fine, no need to go chasing for recent builds or anything like that.

It was on starting dovecot that I was getting the error about not being able to find the file

But that didn’t start happening until I changed the client path in the auth default section from /var/spool/postfix/private/auth as a test because it was reporting that it couldn’t find that file

All that’s a bit of a moot point at the moment though as I haven’t even got that far since reinstalling

At this point I’m able to send to local accounts and remote accounts from the local machine and I’ve only just got that working just before posting this, but I still can’t receive from local accounts to a mail client

The mails reach /var/mail/username but when I try checking mails with thunderbird I get a connection refused error

Until I get that sorted there I can’t even begin to start looking at setting up the sasl really

I kept the confs from the first setup though so I’m about to compare them and see if I can fix that

This might be a bug in the distro. /var/spool/postfix/private is owned by postfix but dovecot runs as dovecot, not root as in some other distros and perhaps in the past (I didn’t run dovecot auth on SUSE before, so I can’t say), so it doesn’t have permission to create that file there.

Try this:

Add dovecot to the postfix group by editing /etc/group, add dovecot to the line starting with postfix.

Chmod /var/spool/postfix/private so that it’s writable by group postfix by

chgrp postfix /var/spool/postfix/private
chmod g+rw /var/spool/postfix/private

Restart the dovecot service.

And please file a bug report.

Sorry that should be:

chmod g=rwx /var/spool/postfix/private

Hmm, I’ve just enabled dovecot auth on a 11.1 server and it looks like out of the box, once you have uncommented the appropriate lines, the path of the auth socket is:


And that is created as root, so permissions aren’t a problem. What you’ll have to do then is tell postfix this path. Instead of private/auth you have to use the full path, since it’s no longer relative to /var/spool/postfix.

Decided I needed a beer, bath and a break before I fooled around any more, my concentration isn’t the best at the moment anyway because of recovering from surgery to screw my leg back together

Ok, looking at what you’ve posted

The folder /var/spool/postfix/private on my system is owned by root and not postfix

Both dovecot and dovecot-auth are running as root, pop3-login and imap-login run as dovecot

I’ve since discovered why I couldn’t connect to dovecot from a mail client locally and I now have that working, earlier I’d tried running Yast’s MTA tool and it did this:

#listen = *
listen =

For some reason it commented out my listen = * line and put a ‘blank’ one there

Hmm, I’ve just enabled dovecot auth on a 11.1 server and it looks like out of the box, once you have uncommented the appropriate lines, the path of the auth socket is:


And that is created as root, so permissions aren’t a problem. What you’ll have to do then is tell postfix this path. Instead of private/auth you have to use the full path, since it’s no longer relative to /var/spool/postfix.

I have to admit to having gotten somewhat confused by this point, one thing I’m not sure about is you said about telling postfix to use the path to dovecot’s auth-client, the postfix docs on setting postfix up with dovecot and sasl stipulate the path to the auth file as going in dovecot’s conf

Granted the docs were saying to use an auth file in postfix and put the path to it in the auth-default section of dovecot’s conf, you on the other hand are saying to use an auth file in dovecot, so I’m really sure on what to do there

I now seem to be at the point I was before I started trying to set up the sasl first time round and it was after following what the postfix docs said to do it went completely pear-shaped

So having backed the confs up now it’s working without the sasl …

Are you perhaps able to give me some pointers on what I need to do so that addresses on the machine can safely be used from outside of my lan?

I’m running suse 11 btw not 11.1

Either way is suitable:

  1. Change the socket path in dovecot.conf and make the group and permission changes if needed, to let it create that socket in /var/spool/postfix/private. Then in postfix/, you can use a relative path: private/auth

  2. Go with the OpenSUSE default of /var/run/dovecot/auth-client for the socket in dovecot.conf and specify in postfix/ the full path /var/run/dovecot/auth-client since it isn’t in postfix’s directories any more.

I prefer 2 since it involves less change to an out-of-the box setup, and postfix has no out-of-the box preference for the parameter smtp_sasl_path. Only there would be some changes needed if postfix were to be configured to run chrooted, and that’s not recommended for newbies.

You have to realise that there is no definitive choice. The software is very flexible, and what the postfix docs suggests is just one way of doing it. Once you understand that the goal is to get dovecot and postfix to agree on a rendezvous point for the socket, you can make the needed adjustments to the instructions.

You should be able to get SMTP auth working with once you get the socket working with postfix.

As it turned out, I was interested in this topic because I had to upgrade a mailserver today. I can vouch for method 2 working, by specifying the absolute path of the socket in the postfix config.

However there is one change that needs to be made to the default dovecot config. The permissions of the socket should be 0666 so that postfix can read and write on it. There seem to be no option to change the group so that it isn’t world accessible, but as the comments say, it should be safe to export to other processes on the server.

I’m glad the topic interested you for whatever reason ken, you’re the only one who’s offered any help with it

Couple of things

I’m not 100% sure where to put the path /var/run/dovecot/auth-client in, does it go in like this:

smtpd_sasl_path = /var/run/dovecot/auth-client

Secondly, do you mean I should change the mode = 0660 parameter in the auth default section of dovecot.conf to 0666?

Assuming I’ve done those right, just need to work out all the other bits again to make the sasl work … if any lol

Then it’ll just be webmail, amavis, clamav and spamassassin … nothing to it! (chuckle)

Any idea what causes this error?

warning: dict_nis_init: NIS domain name not set - NIS lookups disabled

Any pointers in setting up amavis/clamav/spamassassin to work in conjunction with it?