----- Original Message ----- From: "Kenneth Porter" <[EMAIL PROTECTED]> To: "Subscribers of Qpopper" <[EMAIL PROTECTED]> Sent: Friday, August 09, 2002 7:10 PM Subject: Re: Filesystem quotas
> On Fri, 2002-08-09 at 11:51, Chuck Yerkes wrote: > > > There are some bumps: > > If I have a quota of Q, and I get a message > Q, it will > > sit in the inbound queue failing to deliver. > > The big bump is what Alan Rateliff explained. While qpopper has the > spool "swapped out", a delivery can happen that overflows the spool when > it swaps back in. Concatenating the new message to the old spool will > overflow the spool. Pursuant to Justin Shore's message, I think a potential resolution is a soft quota at the limit you'd like the box too be, and a hard quota of at least double that. (I think someone else also mentioned this solution.) That would potentially allow you to keep your .pop's and mailfiles in the same spool directory as well. I'll be spending some time this week researching a "nicer" method to handle quotas. Since I've gotten procmail working as my local delivery agent, I'm sure I can find some recipies that handle quotas quite nicely. Once that's taken care of, a combination of permissible soft/hard quotas should handle the rest. It's nice to be able to use the filesystem quota system for the simple fact that it's just one less step to managing users. Even so, having a separate (or compatible) quota interface within the email daemons seems to be a reasonable solution as well. To illustrate, Solaris will allow you to update quotas on any filesystem that has a quota file in its root, even if quotas are not activated for that filesystem. Using Solaris' native quota utilities would allow easy management, while allowing a local delivery agent (mail.local, procmail, etc.) to access and possibly update that quota file. A potential drawback to this arrangement is "accidentally" turning the filesystem quota management on, causing minor confusion between the MDA and the OS. I'm somewhat opposed to queuing the mail locally for a box that's over quota. From what I understand of the SMTP RFC's, it should be left to the sending system to retry sending to a full mailbox, seeing how a 4xx (temporary, retryable failure) response code is recommended for this situation. Although, I've seen most systems reject with a 5xx (permanent failure) response for over-quota. The bottom line seems that some form of active quota management is absoultely necessary not just to curb usage abuse, but also to watchdog against DoS-type events, list-loops, etc, that can easily and quickly fill a filesystem. It seems that everyone here so far has come up with viable options for doing so. In this regard, Sendmail can be set to start 4xx-rejecting emails once the filesystem free space reaches a specified threshhold. Though that still allows for one person to cripple an entire mail system. -- Alan W. Rateliff, II
