MTA Setup How-To???

Virtualmin
#1

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?

#2

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.

#3

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.

#4

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.

#5

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?

#6

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.

#7

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.

#8

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/

#9

Bump

Can anybody help here?

#10

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.

#11

X-Mail is at:

http://www.xmailserver.org/

It’s BAY FAR the easiest unix mail system to setup. It is a single install for MTA/SMTP/POP3 out of the box. You compile/install binary, edit a few simple lints in the config, and start it…and it all works properly. It’s also far faster than other solutions I have used via any other provider.

On their home page and forums are clear instructions on how to integrate with dovecot for IMAP support, as well as a host of scripts for spam/av filtering. The whole system is configured by a simple set of config files for mail domains and users/aliases. There are also several good Win32/X/PHP front ends that make it even more simple to administer.

The config files are plain english and easily configurable/readable by human beings…no macro languages in between. They are all simply:

"setting" <tab> "value" <tab> "value" <CR/LF>

There hs also a simple command line program to interface with the mailer to maintain the config files through simple commands. All that has to be done manually to get things up and running is the edit of the master config, use a utility to crypt a password for access via a control user, symlink their sendmail replacement, and start the daemon.

It would be far easier to integrate and maintain via a system like Virtualmin, and could be setup on any linux system regaurdless of the distribution very easily. Rather than having to create a complex setup for each user of directories, multiple lines in multiple config files, all that would have to be done is aither have the perl script use the command line client through an authorized admin user to add the domain and subsequent users, or have it add a single line to a single config to create the domain and the same for every user there after.

Why things have to be so complicated with sendmail/postfix/exim/qmail/cyrus/courier/sasl/dovcecot/mbox/Maildir/etc…I will never understand.

#12
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.

No, two usernames is correct. It’s documented behavior. See this FAQ:

http://www.virtualmin.com/faq/cat/virtualmin/68/#faq30

The two usernames is not the source of your trouble.

mydestination = $myhostname, localhost.$mydomain, $mydomain, bricohosts.com

This might be an issue, but not specific to the error you’re reporting. Is “bricohosts.com” also in your virtual maps file (/etc/postfix/virtual)?

smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination permit_i$

This doesn’t look like a valid configuration line. “permit_i$” is not anything I recognize. You should be getting an error about this, and Postfix will refuse to restart (I think, anyway).

myorigin = $mydomain

This is actually probably the issue with your "com.com" thing. myorigin does bad things if the fully qualified hostname of the system is not sane and not matching DNS and not matching the value of "$mydomain". Remove this line, restart Postfix and see what happens.

#13

Well…I finally got it working. Removing myorigin = $mydomain was the fix for the com.com problem. The other problem was that the system was not sending the mail to the ~/Maildir like i had configured everything to do. For some reason mail was being placed in the ~/.maildir folder. I simply reconfigured dovecot to look there for mail and all seems to be working fine now. Thanks for the procmail-wrapper code and all your other help Joe.

The only problem I have at this point is that when a virtual server is setup it does not setup mail by default for the master account. I have looked for this setting in the server templates and the virtualmin config and can’t seem to find it. May just be over looking it…so many things in there. The other thing is that I am using user@domain format for my e-mail system and when I do manually enable the mail service for the master VS user it sets it up as just the username. Any ideas on how to change this?

Thanks again for your help, and if you are ever interested in making gentoo or xmail compatable with virtualmin, don’t hesitate to drop me a mail at ciaran29 [at] gmail [dot] com

#14
The other problem was that the system was not sending the mail to the ~/Maildir like i had configured everything to do. For some reason mail was being placed in the ~/.maildir folder.

Sounds like you’ve got Procmail misconfigured. Check your /etc/procmailrc.

The only problem I have at this point is that when a virtual server is setup it does not setup mail by default for the master account. I have looked for this setting in the server templates and the virtualmin config and can't seem to find it. May just be over looking it....so many things in there. The other thing is that I am using user@domain format for my e-mail system and when I do manually enable the mail service for the master VS user it sets it up as just the username. Any ideas on how to change this?

I’ll flip the order of your questions to answer them, because I think it’ll make it more clear the purpose of this account:

You don’t want to change the login to domain@domain.tld, because that’d be how the administrative user would have to login to Virtualmin, and that’d kinda suck and confuse people. This account is purely for administrative purposes–accepting mail is merely a side effect, and isn’t really intended for use as somebodies primary mailbox. So, the answer is no–you can’t change this to domain@domain.tld. You can, however, fill in some other email address to be the contact address for this virtual server, including one you plan to create for the virtual server once it exists. So, my contact address for virtualmin.com is joe@virtualmin.com, and not virtualmin@virtualmin.com. This can be set in the “Contact email address” field on the virtual server creation form, or it can be changed after creation.

We’d like to do a Gentoo release, eventually. But it’s quite far down the todo list (we’re just two guys, and Gentoo, while having a very loyal following, doesn’t have a very large following…at least not one that has an interest in our commercial products…so it ends up on the back burner).

#15

AHH, finally. I have been going nuts with not being able to receive any mail. Removing "myorigin = $mydomain" solved everything.

Why the heck is that line in the config file to start with?

#16