Mailing List Archive

At 06:55 PM 3/20/97 -0800, you wrote:
>David Mandala <davidm@them.com> writes:
>>
>>Greg, I hear your feelings, but I strongly disagree with your points. James
>>Smallacombe I think is on the right track when he said "How "rock solid" is
>>an email server that stops serving all together because /var or /usr is
>>filled due to a mailbomb?" I share his feelings. Given that a serious mail
>>bombing can fill up a mail system in minutes and I have many people relying
>>on recieving mail via our server.
>>
>
>Yes, you're right, we disagree.
>
>We're both balancing the effects of a server outage (affecting all
>users) with the effects of bouncing over-quota users' mail (affecting
>a few users).
>
>The factor that makes me disagree with you is when you take time
>periods and severity into account.
>
>A server-wide outage is a short affair if you're reasonably on top
>of things. Two or three hours at the most to block the mailbomb
>and resume service. Everyone is affected, but the penalty is light.
>Mail is only deferred rather than rejected, and just for a short
>period of time.
>
>On the other hand, bouncing mail as you and James describe affects
>only a few users, but the penalty they feel is harsh. Their mail
>is bounced back to the sender rather then delayed. The general level
>of user alertness is far below that of ISP admins, so their mail
>will be bounced for far longer than a server would be down.
>
>
>Yes, a problem that affects all users is worse than one that affects
>only a few. But the severity of the penalty, and the length of time
>they suffer it, should also be factored in. At my site, those things
>tilt the balance in favor of deferring the mail instead of bouncing it.
>
>Please don't misunderstand. I'm not trying to make you change your mind
>about how to run your site. I want to explain the reasoning that led me
>to a different decision about mine.
>

I appreciate your point of view, thats why I think that a configurable
option is the best. In my case I am seriously understaffed (and will be for
the foreseeable furture) so it is quite impotant that the systems are able
to run for longer periods of time without major interuption.

It is better (for us) to have a single user with a problem then the entire
system. When I can get the funding to support a 24x7 technical staff then
the scale might change more toward your point of view. For now "The needs
of the many outweigh the needs of the few".

Davidm

David Mandala <davidm@them.com> writes:
>
>It is better (for us) to have a single user with a problem then the entire
>system. When I can get the funding to support a 24x7 technical staff then
>the scale might change more toward your point of view. For now "The needs
>of the many outweigh the needs of the few".
>

But David, you're overstating the case. It doesn't take a 24x7 tech
staff to respond quickly to after-hours outages.

It takes a pager, a computer with a modem and a log watcher script
like spatch, and scripts running on your servers that detect resource
shortages and syslog them. Set up syslog to redirect a facility like
local0 or local7 to the spatch host, and set up that host to page you
when something bad happens.

-Greg
--
Greg Andrews West Coast Online
Unix System Administrator 5800 Redwood Drive
gerg@wco.com Rohnert Park CA 94928
(yes, 'greg' backwards) 1-800-WCO-INTERNET

> We're both balancing the effects of a server outage (affecting all
> users) with the effects of bouncing over-quota users' mail (affecting
> a few users).
> The factor that makes me disagree with you is when you take time
> periods and severity into account.

This is why such behaviour needs to be customizable and configurable -
just because people have different needs.

olaf

Dax Kelson:
> I see a great need to modify "qmail-alias" (the program responsible
> for delivering mail to the user's mail drop) so that when it
> attempts to delievery mail to a user and is unable to do so because
> the user is over his/her quota to immediately bounce the message
> back to the sender with a message "Sorry, that user's mailbox is
> full.".

qmail-1.00$ grep -i quota *.c
error_str.c: X(EDQUOT,"disk quota exceeded")
qmail-1.00$ view error_str.c
qmail-1.00$ grep EDQUOT *.c
error_str.c:#ifdef EDQUOT
error_str.c: X(EDQUOT,"disk quota exceeded")
error_temp.c:#ifdef EDQUOT
error_temp.c: X(EDQUOT)
qmail-1.00$ view error_temp.c

I haven't tested this (I don't run quotas), but it looks like all you
need to do is comment out the line that says X(EDQUOT,"disk quota
exceeded") in error_temp.c

--
Raul

Scott Schwartz:
> rfc821 offers the example:
>
> 452 Requested action not taken: insufficient system storage
>
> In the event of a full mailbox, an MTA can reject the message
> with this transient error, and the preceeding MTA can resend
> it later.

This just deepens the queue, and doesn't address the end-to-end
problem.

--
Raul

At 03:37 AM 3/21/97 -0800, you wrote:
>David Mandala <davidm@them.com> writes:
>>
>>It is better (for us) to have a single user with a problem then the entire
>>system. When I can get the funding to support a 24x7 technical staff then
>>the scale might change more toward your point of view. For now "The needs
>>of the many outweigh the needs of the few".
>>
>
>But David, you're overstating the case. It doesn't take a 24x7 tech
>staff to respond quickly to after-hours outages.
>
>It takes a pager, a computer with a modem and a log watcher script
>like spatch, and scripts running on your servers that detect resource
>shortages and syslog them. Set up syslog to redirect a facility like
>local0 or local7 to the spatch host, and set up that host to page you
>when something bad happens.

I have a different system but seems like the same functionality. The
problem is the level of understaffing and the requirement of SOME time for
a life. You are right don't have to have 24X7 but something closer to it
would help. Its not fair to as the same few people to ruin their personal
life ALL the time. So my choice is to support my very limited staff and
simply make users responsible for their own quota's. Its something akin to
a libertarian viewpoint, I'm not big brother, each person is responsible
for themselves. We maintain the system, you maintain your little part of
it, if you don't then you pay, not everyone.