vpopmail support assumes ./Maildir/ - broken on gentoo

The title says it's all.

Error message: "delivery 13: deferral: can_not_open_new_email_file_errno=2_file=./Maildir/tmp/1343874110.14508.myhost,S=1950/system_error/"

My issue was resolved. by simply doing a violent sed inline edit one-liner on the whole virtualmin libexec directory to mass edit virtualmin's source

The Qmail-LDAP mailserver support allows for "Mail Store for Users" in configuration that allows you to set it to $HOME/.maildir/ if you want the same for Qmail+Vopmail it's hard coded so you are out of luck.

All gentoo ebuilds and qmailconfig has the /var/qmail/control/defaultdelivery (or whatever script invokes qmail-send) to default deliver to ./.maildir. More importantly the standard gentoo ebuild for vpopmail assumes this is the case too, and there is even a script included to migrate from ./Maildir/ folders.

Another idea is to detect support for .qmail files content to be inserted SQL instead, a newer feature of vpopmail.

Also vpopmail is not suid root in many distributions. Having a yes no dialogue to add mail users to the group (usally vpopmail or vkchkpwd) is a help for beginners. Vpopmail has to read in it's database configuration. The system could automatically check to see if vdelivermail is SUID or not and behave accordingly. All mail users have to be owned by the domain user. If you want disk quota's (not vpopmail quotas) then this binary has to be SUID to deliver mail as the other user.

Gentoo linux doesn't run plesk, or cpanel, but it doesn't mean it can't host well. It would be awesome to increase your support for gentoo linux, or think about the posibility of making an auto-install version for Sabayon LInux Core (etc) that is precompiled like Debian or Redhat.

Off topic feature request: implement server controlled spam filtering through spamassassin as the first port of call, and then use spamassassin to farm out virus-scanning to clamav or whatever. Spam filtering before acknowledging message delivery is the way to go, or should at least be an option.

Status: 
Closed (fixed)

Comments

Wait ... so you are saying that Gentoo uses ".maildir" with a lower-case M , instead of the default of "Maildir" . That seems odd.

Is the ".maildir" directory still in regular maildir format, with cur and new sub-directories?

Yes.

.maildir looks more sexy, and it's the default on gentoo. Take my word for it, if not check the netqmail, qmail-ldap or my very own qmail ebuild. And Gentoo has the largest base of hardcore qmail supporters that will not go over to the dark side (think the -"bat book") up until hell freezes over ;)

The option for default delivery folder is configurable in the web Qmail-LDAP settings, who's patcher was a qmail user. Qmail from the onset was configured to have flexible storage location for the default mail directory.

I'll think about making a patch that also allows for maildrop delivery (no procmail damn the procmail), mailing list support (works the same - via fastforward supports /etc/aliases). There is no reason why clamav / spamc can't be called from .mailfilter (maildrop) scripts just like from procmail. Then you can support mail and virus filtering your way with qmail.

In any case it's much ado about nothing, because spam-assassin runs best as a server instance, that can block spam at SMTP time. Let's not create backscatter from spam, or harass the users.

Let usermin manage the SQL userprefs for spamassassin. I know you are trying to accommodate all kinds of installs. It's possible to have all virtual domain configuration in SQL and nothing but the maildir on the disk. Great if you are dealing with NFS maildirs, and the less you interact with the mail volume the better.

When I'm not so busy with production work I'll patch up virtualmin properly. It will support courier-imap authlib enabled maildrop, regular site wide maildrop. I'm even thinking of supporting .qmail files in SQL and making whole new mail-server interface. Qmail-VPOPMAIL-SQL. That way we wont break existing installs. That interface would be complementary to qmailadmin cgi script that already supports all the above. That is the approach I will probably take. Some people prefer SQL instead of a LDAP. Many prefer maildrop over procmail.

Right now let's just fix the basics, allow setting the default delivery maildir configuration for qmail. It could either check /var/qmail/control/defaultdelivery (not supported on newer installs) or in a script that provides the argument to qmail-send - that in turn spawns qmail-lspawn.

root 32380 0.0 0.0 4092 468 ? S Aug02 0:00 qmail-lspawn ./.maildir/

That at least is considered a bug, not a feature request.

As you saw, currently Virtualmin assumes that all qmail+vpopmail users have mail delivered to ~/Maildir .

A simple fix would be to either make this customizable, or auto-detect it based on the defaultdelivery file.

What does that file contain on your system exactly?

like i said it needs to be user configurable

ancient qmail versions used /var/qmail/control/defaultdelivery but none of the binaries ever used it, it was just used by the very very ancient djb provided shell scripts to use with daemontools.

The only way is to gleam it from a running qmail version qmail-lspawn as I demonstrated above, or add the text input field, or make assumptions for the location based on the version of linux installed.

I just recommend making the field, like qmail-LDAP has. There is no standard place for putting this setting, so alas it can not be assumed.

Over here courier-authlib is working fine (via) and i've hacked vpopmail to use -d option when calling maildrop. Domain quota's in vpopmail is allegedly broken, yet my setup depends on all mail being dealt with by a vpopmail user. However the fix would be to change the UID's in /var/qmail/user/assign to vpopmail even though the domain quota is being done by the filesystem driver.

Your quota implementation plays nice with xfs_quota or the linux manpages out of date. Allegedly quotatools can manipulate xfs_quota's now....

Also qmail extensions isn't quiet working yet for all users, but I'll keep my project to package up my hosting system for others in the future, and include it with virtualmin.

I do have plans to migrate from plesk to my setup in the near future. Also for some reason if apache isn't installed you can only create mail users, not FTP / shell. Nginix is installed. Issue?

So would you be happy if Virtualmin just had a config option to change the Qmail+vpopmail mail directory from Maildir to .maildir ?

Oh I'm not stressed, I can sed your whole source tree every time I upgrade. I'm just saying other gentoo users will have to do the same until an option to define the default location of the maildir.

It's simply an act of replacing the hardcoded /Maildir with a variable and a configuration option.

Do you happen to know what file was the trigger for the error message can_not_open_new_email_file_errno=2_file=./Maildir/tmp/1343874110.14508.myhost,S=1950 that you mentioned in your original posting? Is Virtualmin creating a .qmail file somewhere that refers to Maildir when it should be .maildir ?

Vpopmail was creating the .maildir folder as it was configured to by gentoo. Virtualmin was making .qmail-default (domain) files I think or .qmail files for users which referred to ./Maildir Check your code - ./Maildir is hardcoded in your scripts. It's an assumption that all Qmail installs use the ./Maildir folder, and that assumption has never been made upstream since qmail 1.0.

vpopmail automatically creates maildir's on demand - but they will be in .maildir on gentoo.

Trust me we need a configuration option for this just like the Qmail-LDAP interface has.

I can send you a tarball of the prepared source code (patched by gentoo ebuild) to confirm this if you want. Email me and I'll reply with the goods. Alternatively on any synced up gentoo system type ebuild /usr/portage/net-mail/vpopmail/vpopmail-latestver.ebuild prepare.

Thanks for the info - The config option that I will add in Virtualmin 3.94 will allow you to use a custom .maildir directory instead of Maildir

Automatically closed -- issue fixed for 2 weeks with no activity.