Naturally, this stem is the easiest one thanks to FreeBSD ports collection. During installation (make install) you might get questions (like «add tomailer.conf?» or «add to group mail?») – answer «y» to any.
Before installing Postfix let's stop sendmail:
SHELL$ cd /etc/mail$ make stop
I installed Postfix from /usr/ports/mail/postfix-current/ with all configuration options disabled except the first two:
PCRE – Perl Compatible Regular Expressions. Some tutors I saw suggested turning it off but I don't see any reason for doign so so I left it on.
SASL2 – Cyrus SASLv2 (Simple Auth. and Sec. Layer). As we're going to install Cyrus anyway it's a good thing to have (it provides different auth mechaniscs that it calls «mechs» like MD5 and NTLM).
SHELL$ cd /usr/ports/mail/postfix-current/$ make install
FreeBSD's ports tree has 3 different versions of Cyrus-IMAPd in its collection:
version 2;
version 2.2;
version 2.3.
I tried all three versions several times before I decided upon cyrus-imapd22 (v2.2) – maybe others will work for you but now that I've finally got everything working I'll just left this one be.
I installed Cyrus with no options checked (I guess this means it uses Berkeley DB even if it's unchecked).
SHELL$ cd /usr/ports/mail/cyrus-imap22/$ make install
This will also automatically install SASL 2 which we'll need later.
We need both Postfix' and Cyrus' users to be in one group mail. Do so:
SHELL$ pw user mod postfix -G mail$ pw user mod cyrus -G mail$ pw group show mail mail:*:6:postfix,cyrus
If the output of last comment is the same then everything went smoothly.
Log files can save us a lot of troubles while we're installign things if we configure them to give us as much info as possible. Add this to /etc/syslogd.conf:
CONFlocal6.debug /var/log/imapd.log auth.debug /var/log/auth.log
…create log file for imapd and restart syslogd:
SHELL$ touch /var/log/imapd$ chmod 0600 /var/log/imapd$ killall -HUP syslogd
This will log info of Cyrus IMAP daemon (imapd.log) and SASL (auth.log) operations. Don't forget to remove these lines when you're done setting up yoru server as log files will grow large pretty fast at debug log level.
You also need to add some services to your /etc/services. Make sure these are present:
CONFpop3 110/tcp imap 143/tcp imaps 993/tcp pop3s 995/tcp sieve 2000/tcp lmtp 2003/tcp fud 4201/udp
A bit of theory first. Postfix is a replacement for standard sendmail utility that doesn't only send e-mails but actually accepts them, sorts out, stores, etc. Its implementation is very old and unseure (at times when it was made there was no need to much security – just like with DNS protocols, I guess). sendmail is found on most *nix systems by default AFAIK.
An official Postfix docs are located here.
For postfix to override sendmail it needs to be reconrded into /etc/mail/mailer.conf. By default Postfix' installator already does it for you but if it didn't you can do this manually. Set /etc/mail/mailer.conf to this:
CONF# Execute the Postfix sendmail program, named /usr/local/sbin/sendmail sendmail /usr/local/sbin/sendmail send-mail /usr/local/sbin/sendmail mailq /usr/local/sbin/sendmail newaliases /usr/local/sbin/sendmail
As Postfix postinstall message suggests we also need to manually add these lines to /etc/rc.conf:
CONFpostfix_enable="YES" # let Postfix run on reboot sendmail_enable="NO" # don't let sendmail start up sendmail_submit_enable="NO" sendmail_outbound_enable="NO" sendmail_msp_queue_enable="NO"
We also can turn off some sendmail activities that it runs from time to time. This is done in /etc/periodic.conf – if it doesn't exist, create and fill with this:
CONFdaily_clean_hoststat_enable="NO" daily_status_mail_rejects_enable="NO" daily_status_include_submit_mailq="NO" daily_submit_queuerun="NO"
Most configuration is done on /usr/local/etc/postfix/main.cf file. We need to change the following options:
mail_owner
This is user name under which Postfix runs. By default it's just postfix that was created during install; no need to change it.
As comment above it says, «…must not share its user or group id with other accounts and that owns no other files or processes on the system» – in other woords, it must be a brand new user name.
myhostname
It's your machine's host name, e.g. i-forge.net. If unset it will use system-configured host name (hostname in/etc/rc.conf).
mydomain
This is the same except if mail server has its own subdomain (e.g. mail.example.com) this field needs to set «root» domain name (example.com).
by default it's set to myhostname without subdomain name, if any.
mydestination
A comma- or space-separated list of host names that Postfix accounts as its final destination points that it must take mail for. If you only accept mail for yoru hostname it's no need to set this option.
mynetworks_style
I don't completely understand how «trusted» clients mechanism work but it seems like default value (subnet) is used most of the time and itworks for me.
you can make your host only send («relay») e-mails to certain hosts – just set mynetworks_style to «host» and setrelay_domains to whatever domains you want to permit sending mails to.
inet_interfaces
This option limits Postfix to specific network interface(s) to listen on. By default it's string «all».
If you want to deny some spam messages the following settings will help:
CONFsmtpd_client_restrictions = permit_mynetworks # hosts must have PTR (reverse DNS) record and they must exist; reject all but FQDN. smtpd_helo_restrictions = permit_mynetworks, reject_unknown_hostname, reject_non_fqdn_hostname, reject_invalid_hostname # require proper HELO/EHLO SMTP greeting. smtpd_helo_required = yes # require FQDN of the sender and make sure that domain really exists. smtpd_sender_restrictions = reject_unknown_sender_domain, reject_non_fqdn_sender
Note: sometimes it's adviced to have reject_unknown_client listed in smtpd_client_restrictions – however, if you'll be sending e-mails from a machine that has no domain name assigned to IP (PTR DNS record) – e.g. from within your network – Postfix will refuse to talk to you at all.
And now final Postfix config options in main.cf:
alias_maps
A table that sets e-mail aliases (e.g. root → joe). In most cases simple hash is enough:hash:/usr/local/etc/postfix/aliases
alias_database
= hash:/etc/postfix/aliases
mailbox_transport
Since we'll be using Cyrus set this to: lmtp:unix:/var/imap/socket/lmtp
smtpd_banner
A string that Postfix shows for connecting clients (usually robots unless you're using telnet). We can output something funny – like this: $myhostname — I, the $myhostname mailer, greet thou.
As comment above says, "You must specify $myhostname at the start of the text.
That is an RFC requirement. Postfix itself does not care".
we'll see this in action when testing the server using smtptest tool of Cyrus.
We're done with main.cf; let's switch for master.cf now. Find a line that starts like the following and change it to this (uncomment them if necessary):
CONFcyrus unix - n n - - pipe flags=u user=cyrus argv=/usr/local/cyrus/bin/deliver -e -r ${sender} -m ${extension} $
It's important that lines other than the first start with at least one space.
Note that after changing Postfix' config files when it's running you need to reload it using postfix reload command.
Setting aliases
There's a handy Postfix command that will find the location of any Postfix config file:
SHELL$ postconf alias_maps alias_maps = hash:/usr/local/etc/postfix/aliases
E-mail user name aliases are specified in /usr/local/etc/postfix/main.cf – for example, if you want to receive root's mail asmyself@example.com then change this line:
CONFroot: you # change the above to: root: myself
You can add more aliases in similar fashion (merns@, erns@ and michaelerns@ will all point to mike@):
CONFmerns: michaelerns erns: michaelerns michaelerns: mike
After changing this file don't forget to rehash it (as explained in next section) using postalias or newaliases.
We need to generate hashtables for access, transport and aliases config files:
SHELL$ postmap /usr/local/etc/postfix/access$ postmap /usr/local/etc/postfix/transport$ postalias /usr/local/etc/postfix/aliases
It seems like the last command can also be ran as newaliases.
Now we can check if Postfix can run:
SHELL$ postfix start postfix/postfix-script: starting the Postfix mail system $ tail /var/log/messages
Last command should display a bunch of latest messages – if nothing is connected with Postfix then it works fine.
If you've already installed Cyrus you can use its smtptest program to talk to Postfix:
SHELL$ smtptest localhost S: 220 I, the i-forge.net mailer, greet thou. C: EHLO example.com S: 250-i-forge.net S: 250-PIPELINING S: 250-SIZE 10240000 S: 250-VRFY S: 250-ETRN S: 250-ENHANCEDSTATUSCODES S: 250-8BITMIME S: 250 DSN Authenticated. Security strength factor: 0 ^DC: QUIT 221 2.0.0 Bye Connection closed.
Here we see the result of changing smtpd_banner option in main.cf :) If you see the output similar to above then Postfix accepts mails. Exit smtptest by pressing Ctrl+D.
Now that's where things get serious. Unlike Postfix I'd spent more time tryign to get Cyrus running.
Official manual for messing with Cyrus is locatedhere.
Cyrus-IMAP daemon will serve us our mail via some e-mail client like Thunderbird.
Before we proceed I sugest you create symlinks to both config files in /etc/ – I saw comments on the Internet that complained about hardcoded config file oath in Cyrus. As they were old I don't know if it's still an issue but let's create them neverthless:
SHELL$ ln -s /usr/local/etc/imapd.conf /etc/imapd.conf$ ln -s /usr/local/etc/cyrus.conf /etc/cyrus.conf
IMAP
This is where most important configuration is defined. Change the following settings in /usr/local/etc/imapd.conf:
admins
Space-separated list of user names that Cyrus will consider admins with full rights. You don't have to have an Unix user created with this name; it's just a login name.
documentation and tutorials suggest that you don't use root or name of an account that is supposed to accept e-mails. Instead, use something like «cyrroot».
sievedir
Must be set to /var/imap/sieve.
sendmail
Must be set to /usr/local/sbin/sendmail.
sasl_pwcheck_method
Since we're using SASL we need to set this to sasldb.
if you're using SASL auth daemon (saslauthd) you need to set this to saslauthd as well; we won't be using it here, though. Somewhat more info can be found in my follow-up article.
sasl_auto_transition
Set this to «no» unless you want users to create new mailboxes on their own (by connecting tp Cyris via POP3 or IMAP.
Cyrus itself
/usr/local/etc/imapd.conf might use no configuration but for better behaviour we can tweak it like this:
Find line starting with «idled» and comment it out by prefixing with hash sign (#).
Comment lines: «imaps», «pop3», «pop3s», «lmtp» (not «lmptunix»), «notify» and «tlsprune».
protocols that end with «s» (imaps, pop3s) are TLS/SSL versions.
If you want to use prefork to boost performance set the following (taken from /usr/local/share/examples/cyrus-imapd/prefork.conf):
imap ... prefork=5
lmtpunix ... prefork=1
This is a bit of tricky thing because for some strange reason Cyrus' script creates paths with parmissions that differ even from the ones described in its own documentation.
First off, change to cyrus user and execute /usr/local/cyrus/bin/mkimap:
SHELL$ su cyrus$ /usr/local/cyrus/bin/mkimap$ exit
Then fix permissions:
SHELL$ mkdir /usr/sieve$ chown cyrus:mail /usr/sieve$ chmod 750 /usr/sieve $ $ chown cyrus:mail /var/spool/imap$ chmod 750 /var/spool/imap $ $ chown cyrus:mail /var/imap$ chmod 750 /var/imap
Fixing permissions
Permission issues have been my pain with Cyrus for a few hours so let's make sure you can avoid them right from the start.
We've already fixed perms for IMAP, IMAP spool and SIEVE dirs above; now let's go for SASL.
For some reason Cyrus installer sets wrong permissions for /usr/local/cyrus and Cyrus' programs inside/usr/local/cyrus/bin are unavailable so make sure all path components have rx for all users:
SHELL$ chmod 0755 /usr/local/cyrus
Also, after all installations /etc/mail/mailer.conf tends to be getting wrong perms too – let's fix it by setting «r» (0644) for all:
-rw-r--r-- 1 root wheel 211 Jan 18 09:34 mailer.conf
After creating IMAP structure in /var/imap and starting Cyrus its LMTP socket will probably have wrong perms (one more stranginess). You need to make it readable for mail group and make sure it belongs to mail group instead of cyrus (which it gets created with):
SHELL$ ls -l /var/imap/socket/lmtp srwxr--r-- 1 cyrus mail 0 Jan 19 13:36 /var/imap/socket/lmtp=
Note that sometime restarting Cyrus will revert LMTP socket's permissions back to whatever it thinks they must be (0777 root:mail for me).
Now let's make /etc/opieaccess and /etc/opiekeys files accessible – I've read some guesses of why they are used by Cyrus but nothing specific seemed to be known so I set their perms as the following and it worked:
SHELL$ ls -l /etc | grep opie -rw-rw---- 1 root mail 446 Nov 21 2009 opieaccess -rw-rw---- 1 root mail 0 Jan 18 10:42 opiekeys
The following error in /var/messages indicates that there's a problem with the 2 files above:
LOGJan 18 10:38:03 my imap[49632]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied
Make sure that SASL DB is owned by cyrus and mail:
SHELL$ ls -l /usr/local/etc | grep sasl -rw-r----- 1 cyrus mail 16384 Jan 18 11:37 sasldb2.db
Meke sure that SASL's auth mechanisms («mechs») in /usr/local/lib/sasl2 are accessible (rx perms for all):
SHELL$ ls -l /usr/local/lib | grep sasl2/ drwxr-xr-x 2 root wheel 1024 Jan 14 08:56 sasl2/
If you didn't do that auth.log will be filled with errors like these:
LOGJan 18 10:15:54 my lmtpunix[49185]: looking for plugins in '/usr/local/lib/sasl2', failed to open directory, error: Permission denied Jan 18 10:21:20 my imap[49364]: looking for plugins in '/usr/local/lib/sasl2', failed to open directory, error: Permission denied
…and it is also source for issues («no worthy mechs» and «generic failure» of SASL) that were driving me mad the first day:
LOGJan 14 09:58:22 my perl: No worthy mechs found Jan 14 10:29:29 my imtest: No worthy mechs found Jan 18 11:30:45 my imap[1745]: badlogin: localhost [127.0.0.1] plaintext proger SASL(-1): generic failure: checkpass failed
…which in turn resulted in cyradm not being able to connect to my host:
Login failed: generic failure at .../Cyrus/IMAP/Admin.pm line 118 cyradm: cannot authenticate to server with as cyrus
In fact, unavailable SASL modules will result in imtest displaying no AUTH=xx capabilities as well – which means you can't login because there are no means for checking your identity loaded.
Alright! We're finally at the point where we can start up our Cyrus server and see if it works.
Boot up
Boot Cyrus-IMAP up and see the log:
SHELL$ /usr/local/etc/rc.d/imapd start$ tail -20 /var/log/messages
Most likely on a freshly installed Cyrus server you'll get the following warnings:
LOGJan 18 09:55:57 my master[48708]: process started Jan 18 09:55:58 my ctl_cyrusdb[48709]: recovering cyrus databases Jan 18 09:55:58 my ctl_cyrusdb[48709]: done recovering cyrus databases Jan 18 09:55:58 my master[48708]: ready for work Jan 18 09:55:58 my ctl_cyrusdb[48710]: checkpointing cyrus databases Jan 18 09:55:58 my ctl_cyrusdb[48710]: DBERROR: error listing log files: DB_NOTFOUND: No matching key/data pair found Jan 18 09:55:58 my ctl_cyrusdb[48710]: DBERROR: archive /var/imap/db: cyrusdb error Jan 18 09:55:58 my ctl_cyrusdb[48710]: DBERROR: error listing log files: DB_NOTFOUND: No matching key/data pair found Jan 18 09:55:58 my ctl_cyrusdb[48710]: DBERROR: archive /var/imap/db: cyrusdb error Jan 18 09:55:58 my ctl_cyrusdb[48710]: DBERROR: error listing log files: DB_NOTFOUND: No matching key/data pair found Jan 18 09:55:58 my ctl_cyrusdb[48710]: DBERROR: archive /var/imap/db: cyrusdb error Jan 18 09:55:58 my ctl_cyrusdb[48710]: DBERROR: error listing log files: DB_NOTFOUND: No matching key/data pair found Jan 18 09:55:58 my ctl_cyrusdb[48710]: DBERROR: archive /var/imap/db: cyrusdb error Jan 18 09:55:58 my ctl_cyrusdb[48710]: done checkpointing cyrus databases
This is no cause for concern – I searched the 'net and didn't find anything specific but later when I got Cyrus running for some time already I understood why it happened.
It's because there are yet no log files in IMAP database. They're named like log.0000000001– so if you see no files like that in/var/imap/db then it's fine and you can ignore warnings above – when you'll get first logfile (I got mine pretty soon) they'll go away.
Just for a record, normal startup of Cyrus yields these lines in logfile:
LOGJan 19 13:37:37 my master[20111]: process started Jan 19 13:37:37 my ctl_cyrusdb[20112]: recovering cyrus databases Jan 19 13:37:37 my ctl_cyrusdb[20112]: skiplist: recovered /var/imap/mailboxes.db (4 records, 1144 bytes) in 0 seconds Jan 19 13:37:37 my ctl_cyrusdb[20112]: skiplist: recovered /var/imap/annotations.db (0 records, 144 bytes) in 0 seconds Jan 19 13:37:37 my ctl_cyrusdb[20112]: done recovering cyrus databases Jan 19 13:37:37 my master[20111]: ready for work Jan 19 13:37:37 my ctl_cyrusdb[20113]: checkpointing cyrus databases Jan 19 13:37:37 my ctl_cyrusdb[20113]: done checkpointing cyrus databases
Look inside
Let's see the talk of our new IMAP server in its nudity – run imtest that comes with Cyrus (note that user login is specified as -a instead of -u):
SHELL$ imtest -a cyrroot localhost S: * OK my.i-forge.net Cyrus IMAP4 v2.2.13p1 server ready C: C01 CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE AUTH=NTLM AUTH=GSSAPI AUTH=OTP AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR S: C01 OK Completed C: A01 AUTHENTICATE NTLM TlRMTVNTUAABAAAABwIAAAAAAAAgAAAAAAAAACAAAAA= S: + TlRMTVNTUAACAAAAHAAcADAAAAAFAgIA5cwJTQjnMNoAAAAAAAAAAAAAAAAAAAAATQBZAC4ASQAtAEYATwBSAEcARQAuAE4ARQBUAA== Please enter your password:
Let's examine what we have here: at first a usual greeting («server ready») after which a very important line follows («* CAPABILITY IMAP4…») – it tells us which features the server supports. What we need here are caps starting with «AUTH=» – they list SASL auth mechanisms that are available.
Naturally, to be able to connect we need at least one authorization mechanism listed –if you see none then go back to Fixing permissions section and recheck SASL perms.
Other notes:
AUTH=NTLM is required for MS Outlook to work with your IMAP server.
auth methods listed above are NTLM, GSSAPI, OTP, DIGEST-MD5 and CRAM-MD5 – they all come with default installation of SASL.
After more technical info (which may vary depending on auth method imtest chose to use; by default it uses the strongest available) a password prompt follows.
After you've successfully entered it you must see something like this:
S: A01 OK Success (no protection) Authenticated. Security strength factor: 0
Press Ctrl+D to logout from IMAP session.
If you examine auth.log, imapd.log or debug.log you'll see some traces of your presence.
As we're using SASL to manage user accounts the following 2 commands are useful for us:
sasldblistusers2
Lists registered users.
saslpasswd2
Mmanages users (like system adduser, pw and such).
Let's now add Cyrus admin accounts that you specified in admins option of /usr/local/etc/imapd.conf:
SHELL$ saslpasswd2 -c <admin> Password: Again (for verification):
You can delete existing accounts as -d:
SHELL$ saslpasswd2 -d user
Verify that accounts were added:
SHELL$ sasldblistusers2 cyrroot@example.com: userPassword proger@example.com: userPassword
Cyrus has an admin tool cyradm which connects to any (even remote) Cyrus server and lets you manage it.
Let's connect right now (connect with any user listed in admins config of imapd.conf):
SHELL% cyradm -u <one_of_admins> localhost Segmentation fault.
Uh, a segfault?!
That was a second deadlock I got stuck in yesterday. Why the hell would it segfault? I still have no ideas regarding possible causes of that but I've got a solution.
First check if segmentation fault is occurring because of authorization methods – likeit was for me:
SHELL$ cyradm cyradm> connect -noauth localhost localhost>
If you got localhost> prompt then segfault is happening due to an auth mechanism used by cyradm. You can fix it if you force a different mechanism.
Do you remember capabilities that Cyrus sent to us when we connected to it viaimtest? That's what we need. Let's take one of others – I hoose CRAM-MD5. It's done by --auth parameter:
SHELL$ cyradm --auth CRAM-MD5 -u <admin> localhost Password: localhost>
Hey, it works! We're inside our server. Now let's create a mailbox for ourselves that we'll use as normal users (remember – don't receive mail as an admin):
For this you need 3 things:
A mailbox – added by cm command of cyradm – see below.
A user in SASL database – it's added by saslpasswd2 -c <login>
A user in system's /etc/passwd – added by adduser or pw user add.
Note: it's adviced that users added for e-mail accounts only can't login onto your server via SSH – set their shell to/usr/sbin/nologin (or just nologin if you're using adduser) to forbid their access to terminal.
Tip: although adduser and similar will create a home directory for you (default /home/<user>) it can be safely deleted after creating the user.
If you attempt to send an e-mail to a user which has a mailbox and exists in SASL database but doesn't has system user created the mail will be rejected with message
Recipient address rejected: User unknown in local recipient table.
Last 2 steps are simple and the 2nd is even covered above so I'll only explain the first here.
Log into your Cyrus using one of administrator logins:
SHELL$ cyradm --auth CRAM-MD5 -u <admin> localhost localhost> cm user.proger localhost> lm user.proger (\HasChildren) user.proger.Sent (\HasNoChildren) user.proger.Drafts (\HasNoChildren) user.proger.Trash (\HasNoChildren)
You probably won't have all folders (Sent/Drafts/Trash) right now but at least one must exist. Exit cyradm by Ctrl+D.
As might have noticed, mailbbox names have this format: user.<login>[.<folder>]– beginning with «user.» – it's said in the documentation so let it be.
By the way, yf you like Unix-style slashes more than dots you can use them instead so mailboxes will look like«user/proger/Drafts» – just set unixhierarchysep of imapd.conf to «yes».
You can set quota and perform other useful operations – type «help» in cyradm for the lsit of commands. Note that some of them need special permissions.
localhost> setquota user.proger 512000 quota:512000 localhost> listquota user.proger STORAGE 15451/512000 (3.0177734375%)
Note that setquota takes argument in Kilobytes – not bytes.
Users will be warned by IMAP server on each connect when they come close to their limit – normally such warnings are shown as «Server message: …» by mail clients. Default threshold of showing warnings is 90%; you can change it as quotawarn inimapd.conf (don't forget to /usr/local/etc/rc.d/imapd restart after changing Cyrus' config).
Even if you're logged in as one of Cyrus admins you can't delete a mailbox by just typing delete <mbox> – this operation requires «c» right and by default Cyrus doesn't assign it to root – only to mailbox owner.
So in order to delete a mailbox you need to assign «c» perm to yourself:
SHELL$ localhost> setacl <mbbox> <your_login> c$ localhost> delete a
Postfix has 2 size limit config options that are specified in /usr/etc/postfix/main.cf:
message_size_limit
Max size in bytes of the whole message including attacheents.
due to base64 encoding used to transferr binary data actual attachment size is increased by ~33%.
mailbox_size_limit
Max size of any mailbox or folder. If you set this to lower value than message_size_limit Postfix won't send mails at all.
By default these values are 10 MiB for message size limit and 50 MiB for mailbox limit. You can set either (or both) of them to 0 to indicate that there's no limit imposed.
We've reaced a point when we can finally test all parts working together – Postfix receiving mails (via SMTP) and Cyrus serving them via IMAP.
Get your favourite e-mail client and set up new account with login/password you used when calling saslpasswd2 and cmcommand of cyradm. You should be able to see empty IMAP tree shortly.
After doing all things described above you should be able to send/receive e-mails without problems – so Send yourself an e-mail from an account on a different mail server and see if it's been received; then compose one yourself and send it somewhere via your brand-new mail host.
If things don't work well first thing you do is obvious – check the logs. However, this doesn't fix anything and sometimes they keep silent.
In this case you switch to Postfix admin tools.
Checking mail queue
Mail queue keeps messages that are yet to be processed (sent or delivered). In Postfix you can display them like this:
SHELL$ postqueue -p Mail queue is empty
Or its output might look like this:
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- C136C5C003 532 Wed Jan 19 13:42:58 proger i-forge net (host mx.pochta.ru[x.x.x.x] said: 450 Your host is greylisted, please retry later. (in reply to end of DATA command)) mailme smtp ru -- 1 Kbytes in 1 Request.
Purging mail queue
You can remove everything from the queue, discarding undelivered e-mails:
SHELL$ postsuper -d ALL postsuper: Deleted: 1 message
Unlike postqueue which needs basic priviledges postsuper can only be ran by root.
Sending mail with status report
As written at Postfix' docs you can send mails as you would with usual sendmail using -v parameter but status reports will be mailed to your account instead of being displayed in console (this is because Postfix runs as daemon and doesn't execute queries right off the bat; see postqueue and such).
Try delivering e-mail but doesn't send it actually, only report to you: $ /usr/sbin/sendmail -bv you@example.com
Deliver e-mail and send you full status report: $ /usr/sbin/sendmail -v you@example.com
In both variants you'll get the following message:
Mail Delivery Status Report will be mailed to <your login name or From-field>.
Some answers were taken from here.
LOGpostfix/lmtp[563]: …status=deferred (connect to /var/imap/socket/lmtp[/var/imap/socket/lmtp]: Permission denied
The above error message tells you that lmtp:unix:/var/imap/socket/lmtp is inaccessible by Postfix. It can be fixed by changing its perms as described here.
If you've just created a mailbox but can't connect to it make sure the user has all perms to it (by default it's the case). Assuming that mailbox is named user.proger and user name is proger:
SHELL$ cyradm -... localhost> setacl user.proger proger all
LOGJan 19 08:57:45 my lmtpunix[14917]: verify_user(user.proger) failed: Over quota
This error means a user has exceeded his quota. However, if you're sure that he hasn't (e.g. listquota of cyradm tells so) and you've just increased it then maybe it's too early yet – quota changes take up to a few minutes to apply.
I've also seen a piece of advice on the web to run these commands from within cyradm whenever you're running over problems with mailboxes:
SHELL$ localhost> reconstruct -r <mbox>$ localhost> quota -f <mbox>
It can occur in 2 cases that I'm aware of:
You're connecting using cyradm and it segfaults due to a specifiec authorization method(s) cyradm attempts to use. In this case just force a different auth method as described here.
You have upgraded Cyrus or moved existing IMAP (/var/imap) structure to new machine. In this case segfault might happen due to versions of BDB linked into old and new Cyruses doesn't match.
You can check if it's BDB's issue like this:
SHELL$ ldd /usr/local/cyrus/bin/ctl_cyrusdb | grep libdb libdb41.so.1 => /usr/local/lib/libdb41.so.1 (0x2814e000)
Compare the result on both machines and you'll get your answer. You can read more about this problem here.
reject: RCPT from example.com[x.x.x.x]: 554 <someone at example.com>: Relay access denied; from=<one at other.com> to=<someone at example.com> proto=ESMTP helo=<hello>
The above error message appears if Postfix refused to send mail to a host. Check mynetworks_style option of Postfix' main.cf,as well as relay_domains and related.
Some people talk that Cyrus has a hardcoded 2 GiB limit of mailbox quota so even if cyradm successfully sets quota above that number Cyrus itself will work as if it's just 2 GiB.
See this articlefor more information.
Possible log errors:
<root@example.com> (expanded from <root>): host i-forge.net[/var/imap/socket/lmtp] said: 550-Mailbox unknown. Either there is no mailbox associated with this 550-name or you do not have authorization to see it. 550 5.1.1 User unknown (in reply to RCPT TO command)
or:
LOGJan 20 13:14:41 my lmtpunix[1994]: verify_user(user.root) failed: Mailbox does not exist
E-mail user name alias file of Postfix is located at /usr/local/etc/postfix/aliases and defines alternative account names that can be redirected to other users, written to file(s) and more.
The format of this file is described in details here.Normally you would like to redirect root's mails to some address and the following line will do so – send all root's mail to myself:
root: myself
However, if Postfix still complains that there's no root mailbox (or whatever) and you're using hash file type of access file (alias_maps = hash:/usr/local/etc/postfix/aliases):
You might have forgotten to update hash database and/or reload Postfix:
SHELL$ newaliases$ postfix reload
Check that you have specified the same value for both alias_maps and alias_database options of main.cf – otherwise Postfix won't use aliases at all:
CONFalias_maps = hash:/usr/local/etc/postfix/aliases alias_database = hash:/usr/local/etc/postfix/aliases
Don't forget to refresh Postfix and hash DB after modifications (item #1).
LOGJan 21 11:19:47 my postfix/local[14428]: fatal: main.cf configuration error: mailbox_size_limit is smaller than message_size_limit
The above error might be output into /var/log/maillog.
In any case you need to check mailbox & message size limits as explained here.
Recipient address rejected: User unknown in local recipient table.
This usually happens when you've added a user's mailbox and added its password to SASL database but didn't create a system user (via adduser or pw user add). Please refer to the section on Adding new mailbox/user for more details.