Qmail Help

Tuesday, May 31, 2005

Deleting mails from qmail queue

Following commands can delete all mails from your qmail mail server queue.

qmailctl stop
find /var/qmail/queue/mess -type f -exec rm {} \;
find /var/qmail/queue/info -type f -exec rm {} \;
find /var/qmail/queue/local -type f -exec rm {} \;
find /var/qmail/queue/intd -type f -exec rm {} \;
find /var/qmail/queue/todo -type f -exec rm {} \;
find /var/qmail/queue/remote -type f -exec rm {} \;
qmailctl start

Do this when even you get time :-)

Monday, May 30, 2005


You can block email from reaching your server by adding email or domain name to


If you add


Your email server will not accept any email from spamer@yahoo.com and any email account @spamerhome.com

vadduser - create an email account

vadduser is used to create an email account (email user) under a virtual domain.

First we add a virtual domain.

# /usr/home/vpopmail/bin/vadddomain bizhat.com 123456

Now we will create an email account under bizhat.com domain that we just created.

# /usr/home/vpopmail/bin/vadduser info@bizhat.com 123456

This will create an email account info@bizhat.com with password 123456

freebsd# /usr/home/vpopmail/bin/vadddomain bizhat.com 123456
freebsd# /usr/home/vpopmail/bin/vadduser info@bizhat.com 123456

Now we have created an email account, you can configure email client to read this email account or use webmail.

vdeldomain - deleting a virtual domain

After you add a domain with vadddomain, you can delete the virtual domain at any time with vdeldomain command.

# /usr/home/vpopmail/bin/vdeldomain

First we will add a virtual domain

# /usr/home/vpopmail/bin/vadddomain bizhat.com 123456

This will add a virtual domain "bizhat.com" with postmaster password "123456"

Now we will delete it

# /usr/home/vpopmail/bin/vdeldomain bizhat.com

Thats all, the domain is removed from qmail.

vpopmail - Adding Virtual Domain with vadddomain

vadddomain command is used to add a virtual domain to qmail-vpopmail system.

vadddomain: usage: vadddomain [options] virtual_domain [postmaster password]
options: -v prints the version
-q quota_in_bytes (sets the quota for postmaster account)
-b (bounces all mail that doesn't match a user, default)
-e email_address (forwards all non matching user to this address [*])
-u user (sets the uid/gid based on a user in /etc/passwd)
-d dir (sets the dir to use for this domain)
-i uid (sets the uid to use for this domain)
-g gid (sets the gid to use for this domain)
-O optimize adding, for bulk adds set this for all
except the last one
-r[len] (generate a len (default 8) char random postmaster password)

[*] omit @-sign to deliver directly into user's Maildir: '-e postmaster'

Here is how we add a virtual domain "bizhat.com" to qmail-vpopmail system.

freebsd# /usr/home/vpopmail/bin/vadddomain bizhat.com
Please enter password for postmaster:
enter password again:

OR we can provide postmaster password in command line.

freebsd# /usr/home/vpopmail/bin/vadddomain bizhat.com 123456


By default qmail can only serve users in /etc/password, that is system users.

If we want to povide free email to all our visitors, we have to make system user for each email account. But we do not want this.

By using vpopmail with qmail, we can store email users info in MySQL instead of /etc/passwd

This will allow us to host more than one domain in a server (qmail installation).

vpopmail is provided by inter7.com


vpopmail usualy installed in


in FreeBSD it will be in


You can find vpopmail commands at


freebsd# pwd
freebsd# ls -l
total 3572
-rwx--x--x 1 vpopmail vchkpw 150205 May 26 01:14 clearopensmtp
-rwx--x--x 1 vpopmail vchkpw 156265 May 26 01:14 dotqmail2valias
-rwx--x--x 1 vpopmail vchkpw 154045 May 26 01:14 vaddaliasdomain
-rwx--x--x 1 vpopmail vchkpw 158436 May 26 01:14 vadddomain
-rwx--x--x 1 vpopmail vchkpw 158093 May 26 01:14 vadduser
-rwx--x--x 1 vpopmail vchkpw 157902 May 26 01:14 valias
-rwx--x--x 1 vpopmail vchkpw 153998 May 26 01:14 vchangepw
-rwx--x--x 1 vpopmail vchkpw 168220 May 26 01:14 vchkpw
-rwx--x--x 1 vpopmail vchkpw 160509 May 26 01:14 vconvert
-rwx--x--x 1 vpopmail vchkpw 153537 May 26 01:14 vdeldomain
-rwx--x--x 1 vpopmail vchkpw 177305 May 26 01:14 vdelivermail
-rwx--x--x 1 vpopmail vchkpw 155854 May 26 01:14 vdeloldusers
-rwx--x--x 1 vpopmail vchkpw 153722 May 26 01:14 vdeluser
-rwx--x--x 1 vpopmail vchkpw 155969 May 26 01:14 vdominfo
-rwx--x--x 1 vpopmail vchkpw 151539 May 26 01:14 vipmap
-rwx--x--x 1 vpopmail vchkpw 151609 May 26 01:14 vkill
-rwx--x--x 1 vpopmail vchkpw 152954 May 26 01:14 vmkpasswd
-rwx--x--x 1 vpopmail vchkpw 169898 May 26 01:14 vmoddomlimits
-rwx--x--x 1 vpopmail vchkpw 158286 May 26 01:14 vmoduser
-rwx--x--x 1 vpopmail vchkpw 154310 May 26 01:14 vpasswd
-rwx--x--x 1 vpopmail vchkpw 159823 May 26 01:14 vpopbull
-rwx--x--x 1 vpopmail vchkpw 155521 May 26 01:14 vsetuserquota
-rwx--x--x 1 vpopmail vchkpw 159903 May 26 01:14 vuserinfo

Saturday, May 28, 2005

What is Qmail rcpthosts ?

rcpthosts host is a text file, contains list of domain names one per line, that a qmail server is allowed to send/receive emails with out SMTP authentication.

All domain names hosted on a server is listed in rcpthosts, so qmail server knows the domain is local and have to accept emails coming to this domain name.

rcpthosts is located in


Let me know you the content of my rcpthosts file

freebsd# cat /var/qmail/control/rcpthosts

That is "freebsd.netfreehost.com" is my hostname. After installing qmail, i added a domain name for testing through vqadmin, so the second line "netfreehost.com", if i add more domains, that will get listed in /var/qmail/control/rcpthosts

Qmail Variable RELAYCLIENT

qmail-smtpd uses the vairable RELAYCLIENT.

When the variable RELAYCLIENT is set, qmail-smtpd will accept email for relay.

If variable RELAYCLIENT not SET, qmail-smtpd will not accept any emails for relay, it only accept emails for localdomains (site hosted on the qmail server).

Qmail SMTP Access Control with tcp.smtp

Before we can start using qmail smtpd service, we need to define some access control.

This can be done with file


To allow relaying from localhost, you have to add


This setting wil allow Qmail SMTP server to send email from any IP starting with 127.X.X.X

IP is used by localhost

If you need to allow relay from IP address and localhost, Add following


Now you need to use tcprules command to add the rule to qmail database (/etc/tcp.smtp.cdb).

# tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp < /etc/tcp.smtp



The maildirmake command creates maildirs, and maildir folders.

maildirmake [ options ... ] maildir



create a "sharable" maildir. A sharable maildir has slightly different permissions which allows creation of publicly-shared folders.

-q quota

Install a quota on the maildir. See "Maildir Quotas", below.

-f folder

Do not create a maildir, but create a folder in an existing maildir.

-s mode

create a publicly accessible folder in an existing sharable maildir. First, use the -S option to create a sharable maildir. Then, run maildirmake again with the -s option to create publicly accessible folders. mode is a comma-separated list of the following keywords:

read - readonly folder, only you can write messages to this folder

write - anyone can read and write messages to this folder

group - only allow members of your own system group to access messages in this folder (instead of everyone).

--add name=pathname, --del name

Create or delete the directories and links needed to access shared folders.

Friday, May 27, 2005

What is maildir

maildir - E-mail directory

A ``Maildir'' is a structured directory that holds E-mail messages. Maildirs were first implemented by the Qmail mail server. Qmail's maildirs were a simple data structure, nothing more than a single collection of E-mail messages. Courier builds upon Qmail's maildirs to provide extended functionality, such as folders and quotas. This document describes Courier's extended maildirs, without explicitly identify Courier-specific extensions. See maildir in Qmail's documentation for the original definition of maildirs.

Traditionally, E-mail folders were saved as plain text files, called ``mboxes''. Mboxes have known limitations. Only one application can use an mbox at the same time. Locking is required in order to allow simultaneous concurrent access by different applications. Locking is often problematic, and not very reliable in network-based filesystem requirements. Some network-based filesystems don't offer any reliable locking mechanism at all. Furthermore, even bulletproof locking won't prevent occasional mbox corruption. A process can be killed or terminated in the middle of updating an mbox. This will likely result in corruption, and a loss of most messages in the mbox.

Maildirs allow multiple concurrent access by different applications. Maildirs do not require locking. Multiple applications can update a maildir at the same time, without stepping on each other's feet.


A ``maildir'' is a directory that's created by maildirmake. Naturally, maildirs should not have any group or world permissions, unless you want other people to read your mail. A maildir contains three sub-
directories: tmp, new, and cur. These three subdirectories comprise the primary folder, where new mail is delivered by the system.

Folders are additional subdirectories in the maildir whose names begin with a period: such as .Drafts or .Sent. Each folder itself contains the same three subdirectories, tmp, new, and cur, and an additional zero-length file named maildirfolder, whose purpose is to inform any mail delivery agent that it's really delivering to a folder, and that the mail delivery agent should look in the parent directory for any maildir-related information.

Folders are not physically nested. A folder subdirectory, such as .Sent does not itself contain any subfolders. The main maildir contains a single, flat list of subfolders. These folders are logically nested, and periods serve to separate folder hierarchies. For example, .Sent.2002 is considered to be a subfolder called ``2002'' which is a subfolder of ``Sent''.


Folder names can contain any Unicode character, except for control characters. US-ASCII characters, U+0x0020 - U+0x007F, except for the period, forward-slash, and ampersand characters (U+0x002E, U+0x002F, and U+0x0026) represent themselves. The ampersand is represent by the two character sequence ``&-''. The period, forward slash, and non US-ASCII Unicode characters are represented using the UTF-7 character set, and encoded with a modified form of base64-encoding. The ``&'' character starts the modified base64-encoded sequence; the sequence is terminated by the ``-'' character. The sequence of 16-bit Unicode characters is written in big-endian order, and encoded using the base64-encoding method described in section 5.2 of RFC 1521, with the following modifications:

o The ``='' padding character is omitted. When decoding, an incomplete 16-bit character is discarded.

o The comma character, ``,'' is used in place of the ``/'' character in the base64 alphabet.

For example, the word ``Resume'' with both "e"s being the e-acute character, U+0x00e9, is encoded as ``R&AOk-sum&AOk-'' (so a folder of that name would be a maildir subdirectory called ``.R&AOk-sum&AOk-'').


Software that uses maildirs may also create additional files besides the tmp, new, and cur subdirectories -- in the main maildir or a subfolder -- for its own purposes.


E-mail messages are stored in separate, individual files, one E-mail message per file. The tmp subdirectory temporarily stores E-mail messages that are in the process of being delivered to this maildir. tmp may also store other kinds of temporary files, as long as they are created in the same way that message files are created in tmp. The new subdirectory stores messages that have been delivered to this maildir, but have not yet been seen by any mail application. The cur subdirectory stores messages that have already been seen by mail applications.


The following process delivers a new message to the maildir:

A new unique filename is created using one of two possible forms: ``time.MusecPpid.host'', or ``time.MusecPpid_unique.host''. ``time'' and ``usec'' is the current system time, obtained from gettimeofday(2). ``pid'' is the process number of the process that is delivering this message to the maildir. ``host'' is the name of the machine where the mail is being delivered. In the event that the same process creates multiple messages, a suffix unique to each message is appended to the process id; preferrably an underscore, followed by an increasing counter. This applies whether messages created by a process are all added to the same, or different, maildirs. This protocol allows multiple processes running on multiple machines on the same network to simultaneously create new messages without stomping on each other.

The filename created in the previous step is checked for existence by executing the stat(2) system call. If stat(2) results in ANYTHING OTHER than the system error ENOENT, the process must sleep for two sec- onds, then go back and create another unique filename. This is an extra step to insure that each new message has a completely unique filename.

Other applications that wish to use tmp for temporary storage should observe the same protocol (but see READING MAIL FROM MAILDIRS below, because old files in tmp will be eventually deleted).

If the stat(2) system call returned ENOENT, the process may proceed to create the file in the tmp subdirectory, and save the entire message in the new file. The message saved MUST NOT have the ``From_'' header that is used to mboxes. The message also MUST NOT have any ``From_'' lines in the contents of the message prefixed by the ``>'' character.

When saving the message, the number of bytes returned by the write(2) system call must be checked, in order to make sure that the complete message has been written out.

After the message is saved, the file descriptor is fstat(2)-ed. The file's device number, inode number, and the its byte size, are saved. The file is closed and is then immediately moved/renamed into the new subdirectory. The name of the file in new should be ``time.MusecPpid- VdevIino.host,S=cnt'', or ``time.MusecPpidVdevIino_unique.host,S=cnt''. ``dev'' is the message's device number, ``ino'' is the message's inode number (from the previous fstat(2) call); and ``cnt'' is the message's size, in bytes.

The ``,S=cnt'' part optimizes Courier's maildir quota enhancement; it allows the size of all the mail stored in the maildir to be added up without issuing the stat(2) system call for each individual message (this can be quite a performance drain with certain network filesys- tems).


Applications that read mail from maildirs should do it in the following order:

When opening a maildir or a maildir folder, read the tmp subdirectory and delete any files in there that are at least 36 hours old.

Look for new messages in the new subdirectory. Rename new/filename, as cur/filename:2,info. Here, info represents the state of the message, and it consists of zero or more boolean flags chosen from the following: ``D'' - this is a 'draft' message, ``R'' - this message has been replied to, ``S'' - this message has been viewed (seen), ``T'' - this message has been marked to be deleted (trashed), but is not yet removed (messages are removed from maildirs simply by deleting their file), ``F'' - this message has been marked by the user, for some purpose. These flags must be stored in alphabetical order. New messages contain only the :2, suffix, with no flags, indicating that the messages were not seen, replied, marked, or deleted.

Maildirs may have maximum size quotas defined, but these quotas are purely voluntary. If you need to implement mandatory quotas, you should use any quota facilities provided by the underlying filesystem that is used to store the maildirs. The maildir quota enhancement is designed to be used in certain situations where filesystem-based quotas cannot be used for some reason. The implementation is designed to avoid the use of any locking. As such, at certain times the calculated quota may be imprecise, and certain anomalous situations may result in the maildir actually going over the stated quota. One such situation would be when applications create messages without updating the quota estimate for the maildir. Eventually it will be precisely recalcu- lated, but wherever possible new messages should be created in compli- ance with the voluntary quota protocol.

The voluntary quota protocol involves some additional procedures that must be followed when creating or deleting messages within a given maildir or its subfolders. The deliverquota(8) command is a tiny application that delivers a single message to a maildir using the vol- untary quota protocol, and hopefully it can be used as a measure of last resort. Alternatively, applications can use the libmaildir.a library to handle all the low-level dirty details for them. The volun- tary quota enhancement is described in the maildirquota(7) man page.


This is a voluntary mechanism for enforcing "loose" quotas on the maxi- mum sizes of maildirs. This mechanism is enforced in software, and not by the operating system. Therefore it is only effective as long as the maildirs themselves are not directly accessible by their users, since this mechanism is trivially disabled.

If possible, operating system-enforced quotas are preferrable. Where operating system quota enforcement is not available, or not possible, this voluntary quota enforcement mechanism might be an acceptable compromise. Since it's enforced in software, all software that modifies or accesses the maildirs is required to voluntary obey and enforce a quota. The voluntary quota implementation is flexible enough to allow non quota-aware applications to also access the maildirs, without any drastic consequences. There will be some non-drastic consequences, though. Of course, non quota-aware applications will not enforce any defined quotas. Furthermore, this voluntary maildir quota mechanism works by estimating the current size of the maildir, with periodic exact recalculation. Obviously non quota-aware maildir applications will not update the maildir size estimation, so the estimate will be thrown off for some period of time, until the next recalculation.

This voluntary quota mechanism is designed to be a reasonable compromise between effectiveness, and performance. The entire purpose of using maildir-based mail storage is to avoid any kind of locking, and to permit parallel access to mail by multiple applications. In order to compute the exact size of a maildir, the maildir must be locked somehow to prevent any modifications while its contents are added up. Obviously something like that defeats the original purpose of using maildirs, therefore the voluntary quota mechanism does not use locking, and that's why the current recorded maildir size is always considered to be an estimate. Regular size recalculations will compensate for any occasional race conditions that result in the estimate to be thrown off.

A quota for an existing maildir is installed by running maildirmake with the -q option, and naming an existing maildir. The -q option takes a parameter, quota, which is a comma-separated list of quota specifications. A quota specification consists of a number followed by either 'S', indicating the maximum message size in bytes, or 'C', maximum number of messages. For example:

maildirmake -q 5000000S,1000C ./Maildir

This sets the quota to 5,000,000 bytes or 1000 messages, whichever comes first.

maildirmake -q 1000000S ./Maildir

This sets the quota to 1,000,000 bytes, without limiting the number of messages.

A quota of an existing maildir can be changed by rerunning the maildirmake command with a new -q option.

To delete a quota entirely, delete the Maildir/maildirsize file.