Is there anywhere in existance a guide/how-to that explains how to setup an mta (Sendmail, Postfix, or QMail) and pop3/imap service that will integrate with virtualmin properly?

There are a million distro specific guides on how to set this up this way or that way, but nothing at all on how to get all this to work with virtualmin.

I use X-Mail because it is the only MTA in existance that does not require 10 other programs for proper user mail access and is simple, straight forward, fast, and secure. Unfortumatly virtualmin does not support X-Mail. Is there a guide that can explain how to successfully setup an MTA and all the stuff that needs to go with it (Courier, SASL, Dovecot, etc...) to work with virtualmin?

Howdy ciaran,

I guess using the automated install script is not an option for you?

If not, here's the basics:

Postfix, default installation and configuration on almost every Linux distro in existence is fine. You just need to set virtual_alias_maps to "hash:/etc/postfix/virtual" (or whatever an appropriate path on your OS is).

For pickup, you need Dovecot. Install it, and set the POP3 UID if it isn't already set. Start it.

For SASL, install the cyrus-saslauthd package (at least, that's what it's called on most systems). Configuring it is different on every single OS and most versions, so I can't give you any specifics...you might check the FAQ for the entry there about SASL on Red Hat based systems, or search the forum here for several posts about running it on Debian. This is actually the only difficult part of mail service with Virtualmin--and it's not hard once you know where everything lives. It's just such a poorly documented process and lacking in standards.

That's all you need for MTA, POP/IMAP, and SMTP Authentication. If you want to do interest stuff before delivery (like Spam/AV scanning) you'll want to also install Procmail. I've provided some tips on basic mail processing using procmail here in the forums, and I'm happy to answer questions.

There is a mail setup script for all supported operating systems here:

http://software.virtualmin.com/lib/mail-setup.pl

You don't want to run it on an unsupported OS, as it won't know where to find all the right bits. But you can see exactly what steps we take to set things up during our automated install process.

Don't let things intimidate you--mail under Virtualmin is pretty much exactly the defaults for all of the systems we support. We try very hard to stick with a sane, and simple, toolchain for all of the services Virtualmin manages. We don't like elaborate and overly complex solutions.

This system is an up to date Gentoo system so the install script is out.

I have emerged postfix and dovecot and made the changes that you suggested....still no go. The authentication for both SMTP and POP3 via a remote mail client does not work. The server will not accept mail for any domain that is setup.

The only function that works properly is sending a mail through the webmin interface.

If you are interested in making the install script compatable with Gentoo, I would be glad to help. Just let me know what information you need from the system and I can provide it for you.

Webmin/Usermin are managable through their ports in the Gentoo portage tree. It might be worth while to talk to the maintainer of those ports to add virtualmin specific funtions to them.

For instance you could add a virtualmin use flag that would cause the MTA and other supporting software to be added as dependancies and then add the configuration changes needed to a config option to the port. Then it would be as simple as running

#> USE="virtualmin" emerge webmin

and then

#> emerge --config webmin-<version>

to install all of the dependancies and make the configuration changes needed.

Well, I have managed to get things working to some extent. Postfix and SASL are working in so far that a user can send mail from a remote mail client. The user authentication is working properly for pop3 and IMAP through dovecot. I can not however seem to get users to recieve mail properly.

When I send a mail from an external mail server it is accepted by postfix without complaint....but seems to disapear into the great dev/null from there.

I have tried to follow your setup as closely as possible...and the hang up I am seeing at this point is that the procmail-wrapper is a custom bi8nary that is not available for a gentoo system.

I first tried removing the mail delivery command so that procmail would deliver the mail directly without procmail in the middle, and still no mail delivered. This leads me to believe that postfix is sending the mail to the wrong place.

the only line I can find n the postfix main.cf to direct this is:

home_mailbox = Maildir/

I would however like to get procmail working properly as such to allow AV/Spam filtering once I have all the basic mail functions working.

Dovecot seems to be looking for the mail in the right place, hence I get all the dovecot files in the home directorie's Maildir.

Just have to figure out what the problem with local delivery is to get the mail into the Maildir's. Any suggestions?

As for Gentoo support, there just hasn't been any real demand for it, so far. We have only two paying customers using Gentoo (out of ~800), so I can't afford to make it a priority (particularly given that it is so different from all of the other distros we support). It's in the plans, but not until after FreeBSD, for sure (which has a few dozen paying customers, even without the install script). But that's an interesting idea, with regard to implementing it. I know Webmin and Usermin are available from the Gentoo repositories, and that's nice...maybe we can work with the maintainers to get a nice to use Virtualmin GPL in there as well.

procmail-wrapper is just a simple wrapper (obviously) to allow procmail to start up with privileges it needs to read in the configuration files, and then drop privs to the user receiving the mail for processing of those files and the mail. You don't need it for the basic kinds of delivery I've talked about here in the forums in the past--it's specifically for the recipes we use in Virtualmin Professional, and can be replaced by procmail if you're using simpler rules (we have it so that individual virtual servers and users can have different policies with regard to mail and AV scanning).

It can be downloaded from here in source form:

http://software.virtualmin.com/lib/procmail-wrapper.c

Postfix doesn't need to know about Maildir, if you're handing it off to procmail. Postfix does have a simple MDA (mail delivery agent) that can be used, but if you're using a complete MDA like procmail, Postfix doesn't do any delivery, at all.

As for for troubleshooting, it sounds like you're not looking at the logs, at all. That's the only way you'll ever know where mail is going. I don't know where the maillog/mail.log lives on a Gentoo system, so you're on your own for that one.

Well, near as I can tell it is a problem with the way virtualmin is setting up the mail boxes.

When I create a mail user through virtualmin, it creates an entry in the postfix virtual domains table that maps user@domain to user-domain.com. This is wrong from what I can see hence virtualmin is setting up the mail user's home directory in /home/domain-login/homes/user with a unix user user@domain.com. If it is then telling postfix to map this to user-domain.com it has nowhere to go. Hence I get this error over and over again in the logs:

Dec 21 18:36:16 bricohosts postfix/error[28391]: D3A8511F796: to=<ryan-northeastcargo.com@com.com>, orig_to=<ryan@northeastcargo.com>, relay=none, delay=121, delays=60/60/0/0.07, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to com.com[216.239.113.101]: Connection timed out)

Where it is getting the com.com bit from i have no idea. It is so unnecessary for all this to be this complicated. You should just save your users all this trouble and make virtual support X-Mail. There it is a simple set of text files and a single mail deamon to run. None of this postfix/dovecot/SASL/procmail stuff.

If it didn't mean dumping virtualmin's supporting all the other aspects of the hosting server I would just get rid of it, no offence, but all this hassle is just rediclous.

As before the dovecot server is working properly. SASL is authenticating to send mail properly. The only thing that is still not proper is the delivery of mail to users mailboxes. Here are the config files.....see if anyone can make any sense of all this:

##### main.cf: #####

command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix
unknown_local_recipient_reject_code = 550
sendmail_path = /usr/sbin/sendmail
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq
setgid_group = postdrop
manpage_directory = /usr/share/man
sample_directory = /etc/postfix
readme_directory = /usr/share/doc/postfix-2.4.5/readme
home_mailbox = Maildir/
mydestination = $myhostname, localhost.$mydomain, $mydomain, bricohosts.com
myorigin = $mydomain
virtual_alias_maps = hash:/etc/postfix/virtual
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination permit_i$
inet_interfaces = localhost, bricohosts.com
smtpd_delay_reject = no
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME

##### procmailrc: #####


# Use maildir-style mailbox in user's home directory

LOGFILE=/var/log/procmail.log
VERBOSE=yes
MAILDIR=$HOME/Maildir/

Bump

Can anybody help here?

I'm no expert, but in regard to the com.com, it looks like postfix is stripping the host from the hostname. In your case, you're using a domain as a host and postfix is stripping off the bricohosts portion then appending to form a root network domain. Weird, eh? It wants to strip off the host portion so that it can search up the network to find the correct authenticating server ( or just the root network server, haven't figured that out). I don't use postfix (primarily that I'm too dumb or lazy to mess with all the variables) because everytime I try to get it to run it does just that, strip the hostname and try to find an MTA that works for the address. Something in the way it uses the MX records or reads along the network, not sure.

The problem you have with the name@domain and name-domain has to do with a VM fix. Postfix doesn't accept the @ addresses and Joe and Jaimie created a kludge to accomodate those who want to stay with the established address format for user names. Sendmail has been around for a long time and is still robust, though SMTP Auth is supposed to be easy, but something seems to be missing in my build.

Did you mean xmail? I went to x-mail.net and it appears to be a service. Xmail, from what I could gather looks like a complicated setup with little support and a whole passel of what appear to be non-backward compatability. I wasn't really impressed with what I saw.