Diferencia entre revisiones de «Mail servers»
(No se muestra una edición intermedia del mismo usuario) | |||
Línea 1: | Línea 1: | ||
− | = IMAP Servers = | + | =IMAP Servers= |
− | + | ===Cyrus vs Courier-IMAP - Comparison=== | |
− | == | ||
− | |||
− | |||
− | |||
− | |||
− | |||
I think Cyrus is one of the best Open Source IMAP servers. It's only major drawbak IMHO is that it doesn't support dots in user names. It's suitable for any site, small or large, have a filtering language (Sieve), low on resources, secure, reliable, etc. | I think Cyrus is one of the best Open Source IMAP servers. It's only major drawbak IMHO is that it doesn't support dots in user names. It's suitable for any site, small or large, have a filtering language (Sieve), low on resources, secure, reliable, etc. | ||
UW Imap is easier to install/maintain (usualy already in the distribution), but I found it slow at dealing with huge mailboxes. | UW Imap is easier to install/maintain (usualy already in the distribution), but I found it slow at dealing with huge mailboxes. | ||
---- | ---- | ||
− | Date | + | ;Date Mon Aug 13 2001 |
− | |||
− | |||
− | + | Initially I used Courier IMAP and QMAIL POP3D together, which worked fine. | |
− | + | Later I switched to Cyrus which gave me much better performance on large mailboxes. The comparison might not be fair though since I only used somewhat older versions of Courier. Also the personal mail server I tested both Courier and Cyrus on is somewhat underpowered (I486 166 running Postfix, Cyrus, Apache, Postgresql, Firewall, BIND for 4 users). On more recent hardware you might not find the Courier speed an issue. | |
+ | |||
+ | AFAIK the difference is that Cyrus caches mailbox information for faster access. To me this becomes critical when I have > 1000 emails in my inbox. (to many high traffic mailing lists). | ||
+ | |||
+ | Another reason for liking Cyrus is the SIEVE filtering language which I use a lot. | ||
---- | ---- | ||
Saturday 29/Jan/2005, @01:27 | Saturday 29/Jan/2005, @01:27 | ||
− | |||
− | + | Either the Kolab server is not using Cyrus-IMAP, or the interviewer and developers are not talking about the same thing. | |
− | + | Cyrus-IMAP uses several different database formats for message storage. It does *NOT* use Maildir for message storage. | |
− | + | Courier-IMAP uses the Maildir format, but it does not scale into the thousands of users, or the tens of thousands of messages per folder. Trust me, I've tried. | |
− | + | I have 500 MB of archived mail, with several folders with 15,000+ messages in them. Trying to get this to work on a dual-AthlonMP 2200+ system with 2 GB of RAM was not a lot of fun using Courier-IMAP and Maildir. It would take upwards of 30 seconds to load a message index, and it could take even longer to do operations on multiple messages. | |
+ | I installed Cyrus-IMAP on this same server, copied my messages over from one setup to the other (using Kontact no less), and haven't had any problems since. Folder indexing and access is in the sub 5 second range on my largest folders (just under 20,000 messages to date), and doing operations on multiple messages takes no time at all. | ||
+ | ==Analysis== | ||
+ | *http://www.usenix.org/events/lisa03/tech/full_papers/elprin/elprin_html/ | ||
+ | *http://www.geocities.com/mailsoftware42/ | ||
− | = | + | =Misc= |
− | == | + | ==Formats== |
Mail is stored in one of four different formats: | Mail is stored in one of four different formats: | ||
− | + | *The mbox format is the most common. In this format, all messages are stored in one gigantic file, which is usually /var/spool/mail/USERNAME. Other common locations include /var/mail/USERNAME and /usr/spool/mail/USERNAME. The environment variable MAIL should contain the full path to the mailbox. Messages inside an mbox are delimited by the 5-byte string "From " (note the trailing space) at the beginning of a line. That's why, when you send or receive Unix mail, you might find that your paragraphs beginning with "From " have a > symbol inserted in front of the word "From": it's an artifact of the mbox format. | |
− | + | *The MMDF format is the same as mbox, except that messages are delimited by four Ctrl-A bytes (ASCII 01). The only implementation that commonly uses MMDF format is SCO Unix. | |
− | + | *The mh format was the first mailbox format to store messages in individual files. This has the advantage that you can delete a message from the mailbox without having to copy the entire mailbox. The only common use for this format is the mh family of mail programs. (The format is named after the program.) An mh format mailbox is usually kept in the user's home directory. | |
− | + | *The maildir format is similar to the mh format, in that messages are stored in separate files. But maildir adds several extensions to this concept which make it more robust. Maildir is reputed to be safe even when the mailbox is mounted over a network file system. Many different mail programs now support the maildir format, but it is not nearly as widely supported as mbox yet. Maildir format mailboxes are usually kept in the user's home directory. | |
---- | ---- | ||
Línea 48: | Línea 47: | ||
However, Maildir is more efficient overall for general mail handling and processing, esp. if you habitually deal with large messages and/or mailboxes. For instance, Maildir is generally faster and more robust than mbox for: | However, Maildir is more efficient overall for general mail handling and processing, esp. if you habitually deal with large messages and/or mailboxes. For instance, Maildir is generally faster and more robust than mbox for: | ||
− | + | *header scanning (something which every MUA needs to do each time it opens a mailbox) | |
− | + | *deleting 20MB of email in the middle of a 200MB mailbox...with only 50MB free space available | |
---- | ---- | ||
Línea 57: | Línea 56: | ||
− | = | + | =Utilities= |
− | + | ==imapsync== | |
− | == imapsync == | ||
imapsync is a tool for facilitating incremental recursive IMAP transfers from one mailbox to another. It is useful for mailbox migration, and reduces the amount of data transferred by only copying messages that are not present on both servers. Read, unread, and deleted flags are preserved, and the process can be stopped and resumed. The original messages can optionally be deleted after a successful transfer. | imapsync is a tool for facilitating incremental recursive IMAP transfers from one mailbox to another. It is useful for mailbox migration, and reduces the amount of data transferred by only copying messages that are not present on both servers. Read, unread, and deleted flags are preserved, and the process can be stopped and resumed. The original messages can optionally be deleted after a successful transfer. |
Revisión actual del 00:37 21 sep 2007
Contenido
IMAP Servers
Cyrus vs Courier-IMAP - Comparison
I think Cyrus is one of the best Open Source IMAP servers. It's only major drawbak IMHO is that it doesn't support dots in user names. It's suitable for any site, small or large, have a filtering language (Sieve), low on resources, secure, reliable, etc. UW Imap is easier to install/maintain (usualy already in the distribution), but I found it slow at dealing with huge mailboxes.
- Date Mon Aug 13 2001
Initially I used Courier IMAP and QMAIL POP3D together, which worked fine.
Later I switched to Cyrus which gave me much better performance on large mailboxes. The comparison might not be fair though since I only used somewhat older versions of Courier. Also the personal mail server I tested both Courier and Cyrus on is somewhat underpowered (I486 166 running Postfix, Cyrus, Apache, Postgresql, Firewall, BIND for 4 users). On more recent hardware you might not find the Courier speed an issue.
AFAIK the difference is that Cyrus caches mailbox information for faster access. To me this becomes critical when I have > 1000 emails in my inbox. (to many high traffic mailing lists).
Another reason for liking Cyrus is the SIEVE filtering language which I use a lot.
Saturday 29/Jan/2005, @01:27
Either the Kolab server is not using Cyrus-IMAP, or the interviewer and developers are not talking about the same thing.
Cyrus-IMAP uses several different database formats for message storage. It does *NOT* use Maildir for message storage.
Courier-IMAP uses the Maildir format, but it does not scale into the thousands of users, or the tens of thousands of messages per folder. Trust me, I've tried.
I have 500 MB of archived mail, with several folders with 15,000+ messages in them. Trying to get this to work on a dual-AthlonMP 2200+ system with 2 GB of RAM was not a lot of fun using Courier-IMAP and Maildir. It would take upwards of 30 seconds to load a message index, and it could take even longer to do operations on multiple messages.
I installed Cyrus-IMAP on this same server, copied my messages over from one setup to the other (using Kontact no less), and haven't had any problems since. Folder indexing and access is in the sub 5 second range on my largest folders (just under 20,000 messages to date), and doing operations on multiple messages takes no time at all.
Analysis
- http://www.usenix.org/events/lisa03/tech/full_papers/elprin/elprin_html/
- http://www.geocities.com/mailsoftware42/
Misc
Formats
Mail is stored in one of four different formats:
- The mbox format is the most common. In this format, all messages are stored in one gigantic file, which is usually /var/spool/mail/USERNAME. Other common locations include /var/mail/USERNAME and /usr/spool/mail/USERNAME. The environment variable MAIL should contain the full path to the mailbox. Messages inside an mbox are delimited by the 5-byte string "From " (note the trailing space) at the beginning of a line. That's why, when you send or receive Unix mail, you might find that your paragraphs beginning with "From " have a > symbol inserted in front of the word "From": it's an artifact of the mbox format.
- The MMDF format is the same as mbox, except that messages are delimited by four Ctrl-A bytes (ASCII 01). The only implementation that commonly uses MMDF format is SCO Unix.
- The mh format was the first mailbox format to store messages in individual files. This has the advantage that you can delete a message from the mailbox without having to copy the entire mailbox. The only common use for this format is the mh family of mail programs. (The format is named after the program.) An mh format mailbox is usually kept in the user's home directory.
- The maildir format is similar to the mh format, in that messages are stored in separate files. But maildir adds several extensions to this concept which make it more robust. Maildir is reputed to be safe even when the mailbox is mounted over a network file system. Many different mail programs now support the maildir format, but it is not nearly as widely supported as mbox yet. Maildir format mailboxes are usually kept in the user's home directory.
I wouldn't bother with MMDF, MH or any other obscure format, unless you have a specific need for them or don't have a choice.
Choosing between mbox and Maildir is more a matter of what you normally do with your mail. mbox is more space/inode efficient, so it would be a reasonable choice for archival. It's also a good choice if portability is an issue, since almost all MxA's support it.
However, Maildir is more efficient overall for general mail handling and processing, esp. if you habitually deal with large messages and/or mailboxes. For instance, Maildir is generally faster and more robust than mbox for:
- header scanning (something which every MUA needs to do each time it opens a mailbox)
- deleting 20MB of email in the middle of a 200MB mailbox...with only 50MB free space available
Forgot to mention one more reason to use Maildir: no locking required. This is a big win if your mailboxes are on a networked file system (eg. mboxes on NFS-mounted home dirs, not an uncommon scenario).
Utilities
imapsync
imapsync is a tool for facilitating incremental recursive IMAP transfers from one mailbox to another. It is useful for mailbox migration, and reduces the amount of data transferred by only copying messages that are not present on both servers. Read, unread, and deleted flags are preserved, and the process can be stopped and resumed. The original messages can optionally be deleted after a successful transfer.