From: Jesse Guardiani <[EMAIL PROTECTED]> > That's good, I use that myself, pretty common in most qmail setups.
Hmmm... I think you might have some misconceptions about the purpose of the
softlimits program. I don't think it's intended to limit message size. I think
it's intended to contain run-away processes.
No, I get that just fine.
>>However, now I have to add my max message size to the mix, so if I want a
>>max of 30 SMTP processes running simultaneously, I must set my softlimit
>>to 20M, which gives me 12.4M per message.
>
> I'm not sure I follow your math there unless your max message size just
> happens to be 5.8M
You're right, I was off by one, but I'm not sure where you get 5.8M from:
My bad, I was calculating backwards, we have clients coming in out of here on a dog and pony show. However, that's even worse, you're telling me you allow 13.4M emails? That's just not a good idea.
> True, but then your max message thruput is going to drop through the floor
> as you messages are now stored on the hard drive which is accessed in
> milliseconds instead of nanoseconds.
I could be wrong, but I don't think qmail-smtpd stores incoming SMTP messages
in RAM at all. I don't think softlimit was originally intended to limit the
incoming SMTP mail message size in a normal qmail setup, either.
Right, but we're talking about TMDA, if you don't store the message in RAM, you have to put it somewhere or how are you going to attach it for a confirmation message?
qmail defaults to allowing email messages of unlimited size to be sent, unless the databytes control file says differently.
Right, which I personally don't think is a good idea, you should crank yours down to a more reasonable level like 2M-5M
> That seems like it would end up being slower to me, though less resourse > hungry.
Not slower, but faster. We'd be eliminating a step. We currently do this:
STDIN (which is either RAM or a temp file on disk) -> RAM -> DISK but I propose we do this: STDIN -> DISK (with the exception of the headers, of course.)
We're starting to exceed my knowledge of TMDA, however I don't think it's as easy as you're making it sound.
> Because buying more ram is cheap, but trying to get a faster hard drive is
> expensive.
This argument might work on other mail servers (maybe), but not on a qmail server. Qmail servers are designed to be limited by the thruput of the disk. They don't use RAM or CPU unless they have to.
Yes, but disk is expensive nowadays while ram is cheap, adding to your disk I/O with more stuff is just silly.
And frankly, this is an excellent way to deal with email, especially when you consider that my T1's bandwidth will likely fill up before my disk will max out.
Perhaps, but buying more bandwidth is pretty easy, speeding up your hard drive is not.
> Regardless of all that though, it seems like the problem is > big messages, not how TMDA handles them.
I respectfully disagree.
> Still, I'm sure if you manage to
> write something solid that avoids the problems people have mentioned Jason
> would probably take a good look at it.
That's what I'm counting on. In my experience, programmers rarely refuse free code.
Isn't open source a beautiful thing?
Chris Berry [EMAIL PROTECTED] Systems Administrator JM Associates
"Q: How many software engineers does it take to change a lightbulb ? A: It can't be done; it's a hardware problem."
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
_________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
