postfix - dovecot problems

hi there , i have a little problem with my email …

first of all , some numbers …

os : ubuntu 606
virtualmin 3.30

after a few problems with php4 and mysql ( need to reinstall both manually ) i get a new problem .

dovecot wont start with the message … error in dovecot.conf line 648 unknown userdb

so i googled a bit around and found a solution .
old entry : userdb = passwd / passdb = passwd
i changed it to :
userdb passwd{ }
passdb passwd { }
now, dovecot starts normally , also i can use squirrelmail, to send and recive mails ( auth = plain , else dovecot wont start )
but, if i try to recive my mails by outlook or thunderbird , i get a message, that there is a timeout or a networkproblem …

maybe someone has an idea, where to serch the misstake …

greethings from switzerland :slight_smile:

I had similar trouble with Ubuntu 6.06 as well and Dovecot. Seem that the first time you click SAVE on the general configuration in Webmin for Dovecot it write those entries to the file and then it won’t start. I too tried several things and then finally my resolution was somewhat different.

I went in search of a newer Dovecot playing on a hunch that this latest Webmin module might include things for a newer version. Sure enough. Ubuntu latest version of Dovecot supplied in the Ubuntu repositories is v1.0 beta3. The latest verion released of Dovecot is v1.0 RC15. I obtained the 3 .deb packages assocated with Dovecot and used dpkg -i to install them. That complained a little bit and then I did apt-get update and apt-get -force-yes upgrade. The finished the configurations on Dovecot.

Now, I can click save, those items go in the Dovecot config and it runs just fine.

Now I personally am running into problems with SMTP Auth in Postfix for sending from an outside client.

Joe has split out the Ubuntu stuff into a seperate package and is working on the modifications as I understand it. With a little time and luck, this’ll all be a distant memory and all of the Ubuntoos will just work. :slight_smile: Good luck Joe!

Hey guys,

Yep, the prelease of Dovecot isn’t being correctly recognized by Webmin’s Dovecot module. The 1.0 format is supported, but it detects it based on the appearance of the configuration file, and it doesn’t seem to recognize this particular version as 1.0.

So, it’s a subtle bug in Webmin, which I’ll report to Jamie and it should be fixed in Webmin in the next release.

The problem with SASL authentication is that Postfix runs in a chroot environment on Debian/Ubuntu, but saslauthd isn’t in that chroot! So the two can’t talk to each other. Fixing this problem is relatively simple, I think (I’m working on incomplete information, as I haven’t actually tested this yet). I believe the following steps will get things talking correctly:

mkdir -p /var/spool/postfix/var/run/saslauthd

And then edit /etc/default/saslauthd to set the following option as shown:

PARAMS="-m /var/spool/postfix/var/run/saslauthd -r"

Then, when you restart saslauthd and postfix they should be able to talk (again, I’m pretty sure, I need to test it).

It all feels kinda clunky, since all of our other platforms have this bit working out of the box. But Ubuntu is pretty slick in a lot of other areas, so we can forgive it this failing. I’ll get this tested and made automatic during install very soon.

If this doesn’t make things act normal, Tom, let me know and I’ll dig some more.

Oops. I forgot a step. You’ll want also want to remove the old /var/run/saslauthd and hardlink it to /var/spool/postfix/var/run/saslauthd.

Actually, now that I think of it, hardlinking the /var/spool/postfix/var/run/saslauthd to /var/run/saslauthd might work just as well without needing a third step.

So, I think we can replace the first step with:

ln /var/run/saslauthd /var/spool/postfix/var/run/saslauthd

Maybe. (Forgive all of my indecision on this…I’m going from reading lots of docs, and not much actual experimental evidence. The real world experience will come tomorrow, I hope.) :wink:

Renamed /var/run/saslauthd to .bak then executed the command ln /var/run/saslauthd /var/spool/postfix/var/run/saslauthd

THis after doing steps one and two in the first email. Response from Dapper was:

root@ns1:/var/run# ln /var/run/saslauthd /var/spool/postfix/var/run/saslauthd
ln: `/var/run/saslauthd’: hard link not allowed for directory

UPDATE: Even without the hardlink (and the OOPS part) :wink: it’s working now!

Oops… Righto. Can’t hard link a directory, indeed.

Somewhere in the back of my mind, I knew there was a reason for doing it the first way, and then symlinking in the other direction.

So, ignore the second, incorrect advice, and redo the first step.

Then create a symbolic link for /var/run/saslauthd.

ln -s /var/spool/postfix/var/run/saslauthd /var/run/saslauthd

I think that’ll work. The /var/run thing it just so that the initscript and Webmin knows whether Dovecot is running (since they expect the pid file to be in /var/run/saslauthd). Complicated.

chroots are often pretty complex. If postfix didn’t have an absolutely stellar security history I would say it’s worth it. But since it does have a stellar security record, I can’t say it’s worth the extra hassle and complexity. But we’ll get it all invisible to the user soon enough, and only I’ll have to think about the added complexity. :wink:

Oh, and I’ll mention for those who might be interested, the reason we can’t just symlink the /var/run directory into the postfix chroot is because symlinks don’t work from within a chroot to files outside of the chroot. (But they can go into a chroot from outside of it…so for those services outside of the chroot, like Webmin and the initscript, the symlink in /var/run will work fine.)

UPDATE: Even without the hardlink (and the OOPS part) :wink: it’s working now!

Rock! Thanks for the update. That makes my job easier. I’ll just plug that change into the installer and have it rolled out by tomorrow.

The “even without the hardlink” is right, to a degree. The link was intended to make the initscript and other various bits capable of checking the PID of the Dovecot process. I think Webmin wants to see it, as well. So, when you need to restart, check status, etc. of your Dovecot process, I suspect it needs the symbolic link in /var/run. I’m not certain of that, though. :wink:

Hmmm… I guess when it was working it just ignored that I was sending a username and password then for SMTP before I created the symlink back. I created that symlink and then restarted saslauthd and postfix and then it wouldn’t accept my username and password again. :frowning: I know you are testing stuff tomorrow (or later today in my case now) so it’s kewl. I gotta get some sleep anyhow right now. :slight_smile:

Thanks again for everything Joe! :slight_smile:

OH yeah, forgot to mention. WIthout anything there in /var/run/saslauthd, saslauthd failed to start and I didn’t notice at first so I think my assumption about being open relay a that point was probably not that far from true.

thx for the fast answers …

but now i am a bit confused …

i i have done the steps from joe, without the replacement of dovecot …

but i get the same error message in outlook and outlook express as before

maybe, one of u can give me a step by step instruction, what to do now ( my gf is a bit angry about using webmail all the time and gf angry = no dinner and no … urgs )


ok, i tried to install dovecot again, like tom did…
made steps joe mentioned

no go :frowning:

dovecot seems to be a real great piece of software, but … its not useable for me at the moment, cuz all external clients fails to login allways the same error in outlook : network or timeout error.
and i cant tell all people, to use the webmailclient, this is not the intend and the most companys i know, have locked all web ports for their users, without the ports for outlook/outlook-express).

so, the question is , if there is a working solution for this problem, or is there an alternative to dovecot within webmin-virtualmin ( without setting up the whole box again) ?

actually, my mailbox is full of mails releating to the missing outlook support, by my girlfriends company, so that i need to think about an external mailserver and deactivat all email features for domains inside virtualmin-webmin.

greez from switzerland

Hey Richard,

Contact me via email. I can login and straighten it out for you.

Dovecot does work. It’s just ornery to configure on Debian/Ubuntu (it doesn’t require installing different versions–the stock version works, and any version requires the extra configuration to make them work within the Postfix chroot).

Oops…Silly me. Dovecot doesn’t need to be in the chroot. saslauthd is the bit that has to be tweaked for the chroot.

But, nonetheless, we can make Dovecot work–and the bug in Webmin that misdetects the odd default version will be corrected soon (and there is a workaround).

send u an mail with all logins and ports yesterday :slight_smile:

but i f u are short of time, maybe u can explain me, what to do, to fix this damn problem …

greez from switzerland :slight_smile:

hmm, seems, the problem is not solvable at the moment … so
i will setup an extra mailserver on a different box , maybe with plesk ( arrghh ) but thx for the help anyway

Hey Richard,

It’s solvable. I’m just swamped and working on a dozen different client boxes (so I’m actually losing track of who has what problem!). But I’ll get it straightened out for you tonight.

You just had the Dovecot configuration file format confusion issue right?

WIthout anything there in /var/run/saslauthd, saslauthd failed to start and I didn’t notice at first so I think my assumption about being open relay a that point was probably not that far from true.

I wanted to reply to this (despite the conversation having moved well past it) as mentions of open relays are nothing to leave hanging.

In this case, you wouldn’t have an open relay. Postfix would always fail to authenticate–this wouldn’t result in an open relay. Instead it would result in a completely closed relay (except for local clients and those otherwise explicitly allowed by other rules). If you were seeing anything resembling open relay behavior we need to look really closely at your smtpd_recipient_restrictions. Something would have to be wrong with them. Our default is:

permit_mynetworks permit_sasl_authenticated reject_unauth_destination

Anything beyond that (or any change of order) could very well open your server up in unintended ways.