On Fri, 2003-09-05 at 01:14, Russell Coker wrote: > I was under the impression that Sendmail also queues everything to disk. How > does it's queue operate then?
While the message is coming in, Sendmail buffers the message to memory, optionally piping the DATA portion to a socket (for milter scanning). Only after the <CR>.<CR> does Sendmail accept responsibility for the message (providing it was not rejected by a milter) and queue it. Some might say this risky (power outages and such) but I would counter that until the entire message has been received and processed, the receiving MTA is not responsible for the message. In fact, I think this is RFC-specified. Why then, if the receiver isn't responsible, would it want to spend disk I/O queuing a message that may end up being rejected or may fail to come completely in? > I'm not sure what the situation was like in 1999, now Qmail and LDAP support > is adequate. But only with patches to the source code. And since it sounds like you can't distribute modified binaries, you'd have to patch/build qmail on every MTA. I choose not to install a development environment on my production servers. I distribute only binary packages with apt from a central repository. > You need two mail storage servers for 60,000 accounts? Yes. Actually we now have 4 mail stores. We have discovered, at least for our situation, that it is not wise to put more than 20K accounts on a single mailstore. This is not so much for the mail delivery, but for POP3. As many other ISP admins know, a large percentage of customers are the psychotic kind, prone to POPing their multi-MB mailboxes every $%^&[EMAIL PROTECTED] minute, and leaving all the messages on the server. This puts a non-trivial strain on even a fairly hefty dual-x86 box with H/W RAID5 and 2GB of RAM. Yes, I know we could set a larger minimum interval for POP, but the political implications of generating tech support calls about "why can't I POP my mail?" prevent it. Don't get me started on THAT. 8^o > Of course there are lots of things you can do to tune performance, such as > mounting with noatime and using a patched kernel to fix the performance > limiting bugs (I used a SUSE kernel for the mail servers in question). Yes, we use the noatime trick to great effect on the mail stores. While we're on the disk topic, does anyone have or know of a tool to gather I/O statistics on a DAC960? Two of our 4 mail stores have these controllers, and I'm curious how they're doing. I did some more figuring on our mail volume and found that even though each of our 4 mail routers processes 11-12 messages/second (each message requires up to 20 LDAP lookups and a milter for spam filtering), I see virtually no latency in delivery to the mail store. I don't say that to brag, I just have no idea how other folks process their mail, and I'm curious whether we're out of the ordinary or just run-of-the-mill, ho-hum. ;) Good discussion all around though. I'm learning a lot here. Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
