Slashdot Mirror

dhammala asks: "I am responsible for setting up and maintaining a mail server for small web-hosting type business. We currently host about 75 domains, around 100 mailboxes and due to the efforts of our sales team, we are wanting to get ready for some great increases in those numbers. I am worried about my current configuration and ease of administration. More importantly (well, at least to the customers) is email deliverability -- it seems that messages delivered to some big players are being marked as SPAM or disappearing altogether. I am asking the Slashdot community for it's insight and advise on 1) if my current choice of software/configuration is a good match for this situation and 2) if there any additional measures I might take to ensure email deliverability?" "Here is an overview of our current setup:

• We lease servers at ev1servers.net.
• The servers are running RHEL ES3.
• We chose to use Postfix and have it configured to support virtual users and domains mapped in MySQL tables. The reference I used to configure this setup is located here. We initially chose Postfix over qmail because it was open and over sendmail because the config files are actually readable.
• I have added in SQLGrey grey-listing for Postfix to provide a simple level of SPAM detection for our users. We are not wanting to deal with the customer service and higher box loads of mail scanning at this time. We might choose to use a 3rd party vendor to do this as needed.
• Messages are delivered locally via maildrop in maildir format.
• Courier IMAP is running to support both IMAP and POP access to the mailboxes.
• Postfix Admin was setup for easy mailbox administration.

For deliverabilty, I have/am taking the following steps:

• I have verified that our reverse IP records are correct
• I have created SPF records for all of the domains
• I have verified that our server is not listed in any blacklists (great scanner at dnsstuff.com)
• I have started to install DomainKeys for Postfix

In doing all of that, I have found that our IP is listed in the BlarsBL. Do I need to be concerned about this rogue list? The IP was there before I even began to setup the box.

I have not yet been able to get DomainKeys to work with Postfix. It was during my configuration attempts that I started to question this setup and wondered if this was the best setup for our situation.. this inquiry has lead to this posting.

In a perfect world, I would have an email server that:

• is easy to administer,
• supports automated mailbox setup/removal (currently I can just insert rows into my tables and the mailbox setup is done)
• supports current technologies, like grey-listing, DomainKeys, etc
• is secure
• makes the best use of system resources -- I want to get the 'best bang for the buck'

So what do you think? If I stick with this setup will life be grand? I am open to something new AND even taking the time to learn a new setup. If I do need to switch to something different, my only concern would be the ability to migrate existing mailboxes and messages over to the new setup.

Are there any other technologies or configurations that I need to implement to support the best deliverabilty rates?"

Barrett Lyon writes "The FreeBSD Project just submitted this security advisory out to the masses: "FreeBSD-SA-03:07.sendmail, a second sendmail header parsing buffer overflow." It seems that the overflow is not limited to FreeBSD and that there is currently no workaround "other than not using sendmail." Yet another good reason to run Qmail!"

At first, there was mbox, then there was Maildir, and Bill begat Outlook and .mbx. CaraCalla wonders if there is a better way to store mail than the way we currently store it today. I admit, with the changes that email has undergone over the past 5 years (changes in what is being sent, not necessarily in how it is sent), it may be time to reinvent the mail format. Read on for CaraCalla's analysis of the current mail options, and his thoughts on where we may go in the future. If you were to design your own MUA, how would you design its mail storage? CaraCalla asks: "Does anybody know a good, free solution for storing mail on unix hosts? The reason that I ask this question is my discontent with available techniques:

• mbox: There are problems with locking, corruption, access-times, and bloat.
• Maildir: Do you really want to clutter your system with millions of small files? That's waste of inodes, space (unless perhaps you use Linux/ReiserFS or SGi) and just try to open a Maildir with 1000+ mails and see how long it takes your favorite Mailprogram to only display the subjects.
• Cyrus: Basically the same as Maildir with database features.
• UW-Imap mbx: That's classical mbox with extensions allowing multiple access.
• Evolution: Basically mbox with database features.
• Windows clients: Typically some proprietary db-format. Pathetic.

But the thing that bugs me most is disk space. Typical inboxes are made of 5% to 10% of Text including Headers and HTML. The rest are BASE64- (or UU-) encoded pictures, word documents, zip archives and so on. The problem here is the encoding which wastes considerable amounts of space (at least one third).

Some ideas about the ideal mail-storage:

• One file per Mailbox-folder, allowing multiple folders per user. Should those files reside in one central location or in users Homedirs?
• Compression: Should messages be broken into pieces and the MIME-attachments stored separately (thus searching of the text parts would still be possible without decompressing the whole file)?
• File format: gdbm, Sleepycat db? Something new?
• Should the security model allow users to directly access their files, grep them, copy them around?
• Shared folders, virtual domains?
• Unicode support in folder names? Imap message-IDs, flags, useragent specific state-information?
• How would MTAs deliver mail? How would clients access? File-locking (NFS)?
• What about backwards-compatibility? Writing libmailstore (anyone)? adopting UW c-client?

Does my ideal mailstorage exist somewhere? Is somebody working on a project addressing this? Does anybody have some other hints? And please no mbox/Maildir flamewar!"

At first, there was mbox, then there was Maildir, and Bill begat Outlook and .mbx. CaraCalla wonders if there is a better way to store mail than the way we currently store it today. I admit, with the changes that email has undergone over the past 5 years (changes in what is being sent, not necessarily in how it is sent), it may be time to reinvent the mail format. Read on for CaraCalla's analysis of the current mail options, and his thoughts on where we may go in the future. If you were to design your own MUA, how would you design its mail storage? CaraCalla asks: "Does anybody know a good, free solution for storing mail on unix hosts? The reason that I ask this question is my discontent with available techniques:

• mbox: There are problems with locking, corruption, access-times, and bloat.
• Maildir: Do you really want to clutter your system with millions of small files? That's waste of inodes, space (unless perhaps you use Linux/ReiserFS or SGi) and just try to open a Maildir with 1000+ mails and see how long it takes your favorite Mailprogram to only display the subjects.
• Cyrus: Basically the same as Maildir with database features.
• UW-Imap mbx: That's classical mbox with extensions allowing multiple access.
• Evolution: Basically mbox with database features.
• Windows clients: Typically some proprietary db-format. Pathetic.

But the thing that bugs me most is disk space. Typical inboxes are made of 5% to 10% of Text including Headers and HTML. The rest are BASE64- (or UU-) encoded pictures, word documents, zip archives and so on. The problem here is the encoding which wastes considerable amounts of space (at least one third).

Some ideas about the ideal mail-storage:

• One file per Mailbox-folder, allowing multiple folders per user. Should those files reside in one central location or in users Homedirs?
• Compression: Should messages be broken into pieces and the MIME-attachments stored separately (thus searching of the text parts would still be possible without decompressing the whole file)?
• File format: gdbm, Sleepycat db? Something new?
• Should the security model allow users to directly access their files, grep them, copy them around?
• Shared folders, virtual domains?
• Unicode support in folder names? Imap message-IDs, flags, useragent specific state-information?
• How would MTAs deliver mail? How would clients access? File-locking (NFS)?
• What about backwards-compatibility? Writing libmailstore (anyone)? adopting UW c-client?

Does my ideal mailstorage exist somewhere? Is somebody working on a project addressing this? Does anybody have some other hints? And please no mbox/Maildir flamewar!"

ynotds asks: "Our low profile, security-conscious specialty hosting service might have been relaying spam from an untraceable IP for around 43 hours before we tracked the source of a significant traffic increase across quite a few of our less active client IPs. After we firewalled the first spammer IP, three more appeared in quick succession trying the same thing, then after we took qmail down for a while and brought it back up, another group of four tried the same trick, all but one from 203.x.x.x IPs like our own. We now have 90Mb of mainly these unsent messages in our (appropriately named) mess directory queues, but don't want to get side tracked into duplicating others' research if this is a better known problem than it appears to be after another scan of anti-spam resources."

KingArtr writes: "qmail and djbdns have been dropped from the OpenBSD ports tree. According to the message from Theo de Raadt at the OpenBSD Ports Archive its because the license does not permit modification.". Update by nik: Note that NetBSD and FreeBSD continue to include qmail in their ports trees. DJB's license forbids redistribution of modified binaries, but does not forbid distribution of a 'framework' for modifying the source code.

gempabumi asks: "I'm in the process of setting up a production server and I need to decide on an MTA. The main function of the MTA will be to run Mailman mailing lists. Of sendmail, Postfix, exim, and qmail, which MTA do you recommend? What are the strengths/weaknesses of each?"

tjgoodwin asks: "I'm the SysAdmin in an astronomy department. Our currently supported mail user agent is pine ^[?] , but I'm looking at alternatives. I'm particularly interested in strong support for qmail's maildirs. I need to support at least one text-based UA: mutt ^[?] does what I need with maildirs, but is it really suitable for a user base, many of whom are new to Unix? I'm also considering graphical UAs, preferably gnome-based. I've failed to find any useful comparison information (the UNIX Email Software Survey FAQ is seriously out of date). Any pointers?"