Mailing List Archive

On Wed, 19 Mar 1997, Dax Kelson wrote:

>
> Again, what is the point of mail quotas for my users if instead of using
> disk space in the user's mailbox, it uses space in the queue?
>
> I just ran this on my system:
>
> qmail-qread | grep local | grep -v done | sort | wc -l
>
> 263
>
> Of those 90% of them were users who had gone beyond their disk quotas.
> This server is only for mail, shell logins aren't permitted. Each user
> has a 5MB soft and 10MB hard quota with a 7 day time limit. We have a
> script that runs at night and send a message "you are over your soft
> limit...blah blah..delete mail..blah blah" message to each user over the
> soft limit.
>
> 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.".
>
> Doesn't anyone else think that this is a much needed feature? A
> denial-of-service attack is possible when the messages to overquota users
> are allowed be deffered to the mail queue.
>
> Dax Kelson
> Internet Connect, Inc.
>

I think your suggestion for this configurable feature has merit.
This is one of the nightmares that IS resolvable and CAN be
addressed by adding a "qmail-usr-quota" in just the way you
have described to prevent a denial of service attack. If some-one
is aware of a method to limit quotas, and bounce email BACK to the
sender with a message like suggested above, please speak up !

Regards,

Harley Silver

On Wed, 19 Mar 1997, J.T. Conklin wrote:

> >>>>> "Dax" == Dax Kelson <dkelson@inconnect.com> writes:
> Dax> Again, what is the point of mail quotas for my users if instead of using
> Dax> disk space in the user's mailbox, it uses space in the queue?

[snip]

> Dax> message "Sorry, that user's mailbox is full.".
>
> In my opinion, a change like this greatly diminishes the integrity of
> the "internet" e-mail system as a whole for a slight benefit on your
> part.
>

[snip]

> Dealing with bounced mail is an annoyance, especially if it is not
> from a real (ie. permanent) failure. I hate having to dig out the
> original message from my outbox to re-send. I think it's a waste
> of my time.
>
> --jtc
>

Of course, what might be of "slight benefit" to some may be an
"annoyance" and inconvenience to another. :) As far as my or
Dax's configuring the enforcement of user disk quotas on our
servers, "greatly diminishing the integrity of the 'internet'
email system" as you suggest, would you care to elaborate more
clearly ?

Harley Silver

On Wed, 19 Mar 1997, Dax Kelson wrote:

> Date: Wed, 19 Mar 1997 22:40:07 -0700 (MST)
> From: Dax Kelson <dkelson@inconnect.com>
> To: djb-qmail@koobera.math.uic.edu
> Subject: Mail Quota and bouncing revisted
>
>
> Again, what is the point of mail quotas for my users if instead of using
> disk space in the user's mailbox, it uses space in the queue?
>
> I just ran this on my system:
>
> qmail-qread | grep local | grep -v done | sort | wc -l
>
> 263
>
> Of those 90% of them were users who had gone beyond their disk quotas.
> This server is only for mail, shell logins aren't permitted. Each user
> has a 5MB soft and 10MB hard quota with a 7 day time limit. We have a
> script that runs at night and send a message "you are over your soft
> limit...blah blah..delete mail..blah blah" message to each user over the
> soft limit.
>
> 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.".
>
> Doesn't anyone else think that this is a much needed feature? A
> denial-of-service attack is possible when the messages to overquota users
> are allowed be deffered to the mail queue.
>
> Dax Kelson
> Internet Connect, Inc.
>
>
>
>

I would second that request. Or at least make it compile-time or
run-time configurable... I have had about 200 messages in my mail
queue ever since the beginning of our semester in January when I reduced
everyone's quotas back to the default. All of these are over-quota
students.

David Wayne Summers "Linux: The choice of a GNU generation."
david@summersoft.fay.ar.us PGP Public Key available on request.
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8

>>>>> "Dax" == Dax Kelson <dkelson@inconnect.com> writes:
Dax> Again, what is the point of mail quotas for my users if instead of using
Dax> disk space in the user's mailbox, it uses space in the queue?

Eventually the user will bring his disk usage under quota and the
messages will be delivered, or the qmail will time out and give
up and bounce the message.

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

In my opinion, a change like this greatly diminishes the integrity of
the "internet" e-mail system as a whole for a slight benefit on your
part.

When I send a piece of mail, I expect the "system" (all the MTAs
between the sender and recipient) to continue to attempt to deliver
messages whenever transient failures like out of disk space or disk
quotas are exceeded until a generous timeout is reached.

Dealing with bounced mail is an annoyance, especially if it is not
from a real (ie. permanent) failure. I hate having to dig out the
original message from my outbox to re-send. I think it's a waste
of my time.

--jtc

"J.T. Conklin" <jtc@cygnus.com> writes:
| When I send a piece of mail, I expect the "system" (all the MTAs
| between the sender and recipient) to continue to attempt to deliver
| messages whenever transient failures like out of disk space or disk
| quotas are exceeded until a generous timeout is reached.

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.

Scott Schwartz <schwartz@cse.psu.edu> writes:
>"J.T. Conklin" <jtc@cygnus.com> writes:
>| When I send a piece of mail, I expect the "system" (all the MTAs
>| between the sender and recipient) to continue to attempt to deliver
>| messages whenever transient failures like out of disk space or disk
>| quotas are exceeded until a generous timeout is reached.
>
>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.
>

But that will only work if the receiving SMTP daemon knows (or can
track down) the method by which the message will be delivered to
the user.

In qmail terms, that means qmail-smtpd would have to have built
into it parts of qmail-send (to read locals and virtualdomains),
qmail-lspawn (to get uid/gid/homedir), and qmail-alias (to parse
.qmail files).

That pulls the smtp daemon away from Dan's current security model
back toward Sendmail's security model, and I have the feeling that
would be a step backward.

-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

Greg Andrews <gerg@wco.com> writes:
| That pulls the smtp daemon away from Dan's current security model
| back toward Sendmail's security model, and I have the feeling that
| would be a step backward.

Win a few, lose a few. :-)

Hi,

I made a little program which I posted some time ago for Linux which checks
the users quota and if the mail is larger than his hard quota it bounces
the mail (This can be easily changed to anything you want, for example if
you want to bounce it if there's no room that's fine too).
As I said it's for Linux and only supports local disk quota's (not rquotad,
nfs quota's). I'm sure it's not too hard to port it to anything else.
This program would have to go into ALIAS_EMPTY as
"|/var/qmail/bin/checksize\n./Mailbox\n".

The problem with this is that if the users have shell access and they make
themselves a .qmail file this won't be executed so it's not worth too much.
I mailed Dan and asked him if he could implement something like
ALIAS_ALWAYS which will always run before .qmail. This way we could stop
bugging him for quite a few things because features like rejecting big mail
etc... could be done by the administrator. But he never answered and it'll
probably not be implemented in the near future.
If you're interested in the small program I can post it on the list but you
can find it in the archives. I posted it a few weeks ago.

Andi

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Andi Gutmans - Computer Science, Technion

Email: andi@vipe.technion.ac.il
andi@il.eu.org
PGP public key: finger andi@vipe.technion.ac.il

On 19 Mar 97 at 22:40, Dax Kelson wrote:
> 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.".

How about at the top of .qmail for that user:

if [ "`quota`" ]; then (echo "Sorry, that user's mailbox is full."; exit 1); fi

(the man page says it only displays output if usage is over quota,
not sure if it actually means soft or hard though!).


> Doesn't anyone else think that this is a much needed feature? A
> denial-of-service attack is possible when the messages to overquota users
> are allowed be deffered to the mail queue.

As others have pointed out, a reliable mail system should not be
bouncing mail for a user because it cannot deliver it at that moment,
which is a temporary faultt.

Whether you consider quota breaking to be temporary or not is up to
you (and your customers?).

C.

>>>>> "hsilver" == hsilver <hsilver@pyx.net> writes:
>> Dealing with bounced mail is an annoyance, especially if it is not
>> from a real (ie. permanent) failure. I hate having to dig out the
>> original message from my outbox to re-send. I think it's a waste
>> of my time.

hsilver> Of course, what might be of "slight benefit" to some may be an
hsilver> "annoyance" and inconvenience to another. :) As far as my or
hsilver> Dax's configuring the enforcement of user disk quotas on our
hsilver> servers, "greatly diminishing the integrity of the 'internet'
hsilver> email system" as you suggest, would you care to elaborate more
hsilver> clearly ?

Sure.

What I meant by "integrity" is a definition which I picked up from
"The Power of Product Integrity", an article by Kim Clark and Takahiro
Fujimoto which appeared in the Nov/Dec 1990 issue of Harvard Business
Review. In that article, the authors state that product integrity is
more than basic functionality or technical performance, but also
includes whether the product meets the customers (or users)
expectations.

I expect a rock solid e-mail system that attempts to deliver mail
through hell, high water, and transient failures. I believe a system
that bounces mail due to over quota mail accounts does not meet those
expectations, therefore is compromising the integrity of greater e-mail
system as a whole.

--jtc

PS. The article goes on to assert that companies with internal
integrity tend to produce products with integrity and capture more
market share, etc., etc., etc.

On Wed, 19 Mar 1997, Dax Kelson wrote:

>
> Again, what is the point of mail quotas for my users if instead of using
> disk space in the user's mailbox, it uses space in the queue?
>
> I just ran this on my system:
>
> qmail-qread | grep local | grep -v done | sort | wc -l
>
> 263
>
> Of those 90% of them were users who had gone beyond their disk quotas.
> This server is only for mail, shell logins aren't permitted. Each user
> has a 5MB soft and 10MB hard quota with a 7 day time limit. We have a
> script that runs at night and send a message "you are over your soft
> limit...blah blah..delete mail..blah blah" message to each user over the
> soft limit.
>
> 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.".
>
> Doesn't anyone else think that this is a much needed feature? A
> denial-of-service attack is possible when the messages to overquota users
> are allowed be deffered to the mail queue.

I don't usually "me too", but since you're asking for one, Me too! I
already suffered from such a DoS attack. Luckily, I was able to get ahold
of the ISP of the perp and they unplugged the offending shell machine from
their Ethernet and we identified the perp.

James Smallacombe Internet Access for Bucks County
james@pil.net And Philadelphia, PA.
PlantageNet Internet Ltd. http://www.pil.net
"I'll plant Plantagenet, root him up who dares." 3Henry Vi, I,i

There are really only two possibilities: (1) Your mail system has a
bounded, known maximum requirement for disk space, or (2) your mail
system has an unbounded requirement for disk.

In the case of (2) you risk loss of ability to deliver mail to the
entire user population when you run out of queue space. I assure
everyone that no matter how much queue space you have, you will run
out if you don't put limits on its use.

I happen to believe that a system with a *designed in* potential for
total loss of service is not better, it is worse. "Integrity",
reliability, predictability of performance are all enhanced by not
leaving yourself open to the "out of queue space" condition.

I wrote two mods to qmail 0.91 with this in mind, one to give
qmail-smtpd a MAXSIZE environment variable to limit incoming message
size, and another (hack) to qmail-alias and qmail-lspawn to bounce
messages when the user is over quota. The latter may not be widely
applicable as it only applies to Mailbox, not Maildir format and also
uses the obsolete pw_quota field as the source of the limit on mailbox size.

If there is wide enough interest I'd be happy to take a look at
porting these two mods to qmail 1.0 and possibly making the mailbox
quota more general and flexible. If you're interested let me know.

--Jeff Hayward

At 09:34 AM 3/20/97 -0500, James Smallacombe wrote:
>> 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.".
>>
>> Doesn't anyone else think that this is a much needed feature? A
>> denial-of-service attack is possible when the messages to overquota users
>> are allowed be deffered to the mail queue.
>
>I don't usually "me too", but since you're asking for one, Me too! I
>already suffered from such a DoS attack. Luckily, I was able to get ahold
>of the ISP of the perp and they unplugged the offending shell machine from
>their Ethernet and we identified the perp.

--
Jeff

On Thu, 20 Mar 1997, J.T. Conklin wrote:

> >>>>> "hsilver" == hsilver <hsilver@pyx.net> writes:
> >> Dealing with bounced mail is an annoyance, especially if it is not
> >> from a real (ie. permanent) failure. I hate having to dig out the
> >> original message from my outbox to re-send. I think it's a waste
> >> of my time.
>
> hsilver> Of course, what might be of "slight benefit" to some may be an
> hsilver> "annoyance" and inconvenience to another. :) As far as my or
> hsilver> Dax's configuring the enforcement of user disk quotas on our
> hsilver> servers, "greatly diminishing the integrity of the 'internet'
> hsilver> email system" as you suggest, would you care to elaborate more
> hsilver> clearly ?
>
> Sure.
>
> What I meant by "integrity" is a definition which I picked up from
> "The Power of Product Integrity", an article by Kim Clark and Takahiro
> Fujimoto which appeared in the Nov/Dec 1990 issue of Harvard Business
> Review. In that article, the authors state that product integrity is
> more than basic functionality or technical performance, but also
> includes whether the product meets the customers (or users)
> expectations.
>
> I expect a rock solid e-mail system that attempts to deliver mail
> through hell, high water, and transient failures. I believe a system
> that bounces mail due to over quota mail accounts does not meet those
> expectations, therefore is compromising the integrity of greater e-mail
> system as a whole.

How "rock solid" is an email server that stops serving all together
because /var or /usr is filled due to a mailbomb? That's what happened to
me. Give me the bounce feature any day.


James Smallacombe Internet Access for Bucks County
james@pil.net And Philadelphia, PA.
PlantageNet Internet Ltd. http://www.pil.net
"I'll plant Plantagenet, root him up who dares." 3Henry Vi, I,i

James Smallacombe <james@pil.net> writes:
>
>How "rock solid" is an email server that stops serving all together
>because /var or /usr is filled due to a mailbomb? That's what happened to
>me. Give me the bounce feature any day.
>

I sympathize, but I don't think it's qmail's responsibility to
prevent whole filesystems from filling up, particularly when
they're shared with other applications (such as /usr and /var).

I agree that preventing qmail's queue from becoming the culprit
is a good idea, so long as it doesn't adversely impact qmail's
performance.

However, there are many other things that can fill up filesystems
on a Unix machine, even a mere mail host. The burden of preventing
your filesystems from filling up (for any reason) rests on *your*
shoulders. It sounde like you need to implement an early warning
system to get your attention when your machines are getting short
on resources like disk space. I've done that before, and it's not
that hard.

Has anyone checked to see what qmail-smtpd and qmail-queue do when
the queue filesystem is filling up? Would it be practical to have
a control/minqueuefree parameter that allows qmail-queue to return
a temporary failure code when queue space is low, and qmail-smtpd
would reflect the temporary error back to the smtp sender?

-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

On Thu, 20 Mar 1997 06:30:30 -0800, "J.T. Conklin" <jtc@cygnus.com> said:

> I expect a rock solid e-mail system that attempts to deliver mail
> through hell, high water, and transient failures. I believe a system
> that bounces mail due to over quota mail accounts does not meet those
> expectations, therefore is compromising the integrity of greater e-mail
> system as a whole.

It depends on your system. We're an ISP with hundreds of thousands of
users. We don't want to queue the mail if the user is over quota. We
want them to have an incentive to check and delete their mail. We
can't afford to give almost unlimited disk space to users who want to
email copies of Windows NT around (it's happened).

When dealing with this order of magnitude of users, uncommon problems
suddenly become common. One (1!) user recieved 3 GB of mail from a
gateway spewing duplicate messages (that had a half meg attachment).

It seems clear to me that different people have different needs and
expectations for what a quota violation should do. An option of some
sort seems to be in order.

Drew

--
"I know that it sucks for the rest of the world that mail transport
is built around ASCII and English but you only have your ancestors
to blame for losing the wars. :)" -- Kyle Jones

On Thu, 20 Mar 1997, Jeff Hayward wrote:

> I happen to believe that a system with a *designed in* potential for
> total loss of service is not better, it is worse. "Integrity",
> reliability, predictability of performance are all enhanced by not
> leaving yourself open to the "out of queue space" condition.

I agree.

> I wrote two mods to qmail 0.91 with this in mind, one to give
> qmail-smtpd a MAXSIZE environment variable to limit incoming message
> size, and another (hack) to qmail-alias and qmail-lspawn to bounce
> messages when the user is over quota. The latter may not be widely
> applicable as it only applies to Mailbox, not Maildir format and also
> uses the obsolete pw_quota field as the source of the limit on mailbox size.
>
> If there is wide enough interest I'd be happy to take a look at
> porting these two mods to qmail 1.0 and possibly making the mailbox
> quota more general and flexible. If you're interested let me know.
>
> --Jeff Hayward


We use the Mailbox format for I/O performance reasons, and mail is
delievered locally. Both those features "MAXSIZE" and bounce on over
quota would be great. I don't use the "pw_quota" field (Solaris 2.5.1),
how about a "control/defaultquota", and a field in the assign file for
those with "nondefault" quotas.


I'm definately interested in a port to qmail 1.0.

Dax Kelson
Internet Connect, Inc.

On Thu, 20 Mar 1997, Greg Andrews wrote:

> James Smallacombe <james@pil.net> writes:
> >
> >How "rock solid" is an email server that stops serving all together
> >because /var or /usr is filled due to a mailbomb? That's what happened to
> >me. Give me the bounce feature any day.
> >
>
> I sympathize, but I don't think it's qmail's responsibility to
> prevent whole filesystems from filling up, particularly when
> they're shared with other applications (such as /usr and /var).
>
> I agree that preventing qmail's queue from becoming the culprit
> is a good idea, so long as it doesn't adversely impact qmail's
> performance.
>
> However, there are many other things that can fill up filesystems
> on a Unix machine, even a mere mail host. The burden of preventing
> your filesystems from filling up (for any reason) rests on *your*
> shoulders. It sounde like you need to implement an early warning
> system to get your attention when your machines are getting short
> on resources like disk space. I've done that before, and it's not
> that hard.

The mailbomb in question was coming in over a T1 at about 500Mbits per
second. It only took a few minutes for the volume to fill up (in this
case, /usr, since no quotas were in place) and render the server unusable
for anything. We're not talking about something that was at all gradual,
we're talking about a hostile attack, and boucing the emails in question
would have spared me alot of grief.

> Has anyone checked to see what qmail-smtpd and qmail-queue do when
> the queue filesystem is filling up? Would it be practical to have
> a control/minqueuefree parameter that allows qmail-queue to return
> a temporary failure code when queue space is low, and qmail-smtpd
> would reflect the temporary error back to the smtp sender?
>
> -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
>

James Smallacombe Internet Access for Bucks County
james@pil.net And Philadelphia, PA.
PlantageNet Internet Ltd. http://www.pil.net
"I'll plant Plantagenet, root him up who dares." 3Henry Vi, I,i

On Thu, 20 Mar 1997, Patrick Michael Kane wrote:

> Over a T1 at 500 mbit/sec? Wow, I want the compression algorithm that
> _you_ are using on that line. 500:1 is pretty damn good.

Yes, it's called the "I Can't Think Straight Right Now So I Wrote m
instead of k Algorithm" Very effective. I've heard you can even type "g"
instad and therefore get a ~50,000:1 compression ratio.

:)

> On Thu, 20 Mar 1997, James Smallacombe wrote:
>
> > On Thu, 20 Mar 1997, Greg Andrews wrote:
> >
> > > James Smallacombe <james@pil.net> writes:
> > > >
> > > >How "rock solid" is an email server that stops serving all together
> > > >because /var or /usr is filled due to a mailbomb? That's what happened to
> > > >me. Give me the bounce feature any day.
> > > >
> > >
> > > I sympathize, but I don't think it's qmail's responsibility to
> > > prevent whole filesystems from filling up, particularly when
> > > they're shared with other applications (such as /usr and /var).
> > >
> > > I agree that preventing qmail's queue from becoming the culprit
> > > is a good idea, so long as it doesn't adversely impact qmail's
> > > performance.
> > >
> > > However, there are many other things that can fill up filesystems
> > > on a Unix machine, even a mere mail host. The burden of preventing
> > > your filesystems from filling up (for any reason) rests on *your*
> > > shoulders. It sounde like you need to implement an early warning
> > > system to get your attention when your machines are getting short
> > > on resources like disk space. I've done that before, and it's not
> > > that hard.
> >
> > The mailbomb in question was coming in over a T1 at about 500Mbits per
> > second. It only took a few minutes for the volume to fill up (in this
> > case, /usr, since no quotas were in place) and render the server unusable
> > for anything. We're not talking about something that was at all gradual,
> > we're talking about a hostile attack, and boucing the emails in question
> > would have spared me alot of grief.
> >
> > > Has anyone checked to see what qmail-smtpd and qmail-queue do when
> > > the queue filesystem is filling up? Would it be practical to have
> > > a control/minqueuefree parameter that allows qmail-queue to return
> > > a temporary failure code when queue space is low, and qmail-smtpd
> > > would reflect the temporary error back to the smtp sender?
> > >
> > > -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
> > >
> >
> > James Smallacombe Internet Access for Bucks County
> > james@pil.net And Philadelphia, PA.
> > PlantageNet Internet Ltd. http://www.pil.net
> > "I'll plant Plantagenet, root him up who dares." 3Henry Vi, I,i
> >
> >
>
> Patrick Kane
> The Electronic Newsstand
> <modus@enews.com>
>
>

James Smallacombe Internet Access for Bucks County
james@pil.net And Philadelphia, PA.
PlantageNet Internet Ltd. http://www.pil.net
"I'll plant Plantagenet, root him up who dares." 3Henry Vi, I,i

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.

I agree with you many things can fill up a filesystem on a unix/linux
machine besides a mail spool, and I agree with you that I (the systems
adminstrators) have the responsbility to make sure that does not happen
(other junk filling up the file system). However I (the systems
adminstrators) have an equal responsibility to ensure the delivery of mail
to as many users as possible.

Therefor we have choosen to install the quota system and we have in our
terms of service a paragraph that state in effect "mail will bounce if in
excess of your quota, and it is your (the user) responsibility to maintain
your file area below your quota size in order to recieve mail". This
insures that in the event of a single customer (or more) being mail bombed
the rest of the customers will continue to recieve mail service
uninterrupted. In our business that is the defination of a "Rock Solid mail
system".

I totally support the concept of a configurable system that allows you to
configure your mail system in a fashion that is best for your system use
and alows me to configure it in a way the is best for my system use. It
seems to be there is no "one size fits all" design when running a business,
different sites have widley varying needs and the easier it is to
accomidate those needs the better.

As I mention above, I "need to bounce mail for users over their quota" the
fact that you "need to queue mail for users over their quota" should be
accomplishable in our unique configurations of mail (qmail, smail, etc) and
preferably in an easy runtime configurable way.

At 08:17 AM 3/20/97 -0800, you wrote:
>James Smallacombe <james@pil.net> writes:
>>
>>How "rock solid" is an email server that stops serving all together
>>because /var or /usr is filled due to a mailbomb? That's what happened to
>>me. Give me the bounce feature any day.
>>
>
>I sympathize, but I don't think it's qmail's responsibility to
>prevent whole filesystems from filling up, particularly when
>they're shared with other applications (such as /usr and /var).
>
>I agree that preventing qmail's queue from becoming the culprit
>is a good idea, so long as it doesn't adversely impact qmail's
>performance.
>
>However, there are many other things that can fill up filesystems
>on a Unix machine, even a mere mail host. The burden of preventing
>your filesystems from filling up (for any reason) rests on *your*
>shoulders. It sounde like you need to implement an early warning
>system to get your attention when your machines are getting short
>on resources like disk space. I've done that before, and it's not
>that hard.
>
>Has anyone checked to see what qmail-smtpd and qmail-queue do when
>the queue filesystem is filling up? Would it be practical to have
>a control/minqueuefree parameter that allows qmail-queue to return
>a temporary failure code when queue space is low, and qmail-smtpd
>would reflect the temporary error back to the smtp sender?
>
> -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
>
>

Count me in a interested.

At 08:50 AM 3/20/97 -0600, you wrote:
[snip]
>
>I happen to believe that a system with a *designed in* potential for
>total loss of service is not better, it is worse. "Integrity",
>reliability, predictability of performance are all enhanced by not
>leaving yourself open to the "out of queue space" condition.
>
>I wrote two mods to qmail 0.91 with this in mind, one to give
>qmail-smtpd a MAXSIZE environment variable to limit incoming message
>size, and another (hack) to qmail-alias and qmail-lspawn to bounce
>messages when the user is over quota. The latter may not be widely
>applicable as it only applies to Mailbox, not Maildir format and also
>uses the obsolete pw_quota field as the source of the limit on mailbox size.
>
>If there is wide enough interest I'd be happy to take a look at
>porting these two mods to qmail 1.0 and possibly making the mailbox
>quota more general and flexible. If you're interested let me know.
>
>--Jeff Hayward
>
[snip]

At 03:57 PM 3/20/97 -0800, you wrote:
>>
>> The mailbomb in question was coming in over a T1 at about 500Mbits per
>> second. It only took a few minutes for the volume to fill up (in this
>> case, /usr, since no quotas were in place) and render the server unusable
>> for anything. We're not talking about something that was at all gradual,
>> we're talking about a hostile attack, and boucing the emails in question
>> would have spared me alot of grief.
>>
>
>The problem is that preventing denial of service attacks is hard. For
>example, if you bounce email for a user that is over quota, someone
>malicious can fill their mailbox up with junk mail and cause
>legitimate mail to bounce. Now do this with all of your users. It
>has the same effect of rendering the server unusable and causing
>people to lose mail.

It is extremely unlikely that someone could hit all of my users at the same
time with an mailbomb attack. It would be damn near impossible for anyone
to get such a list of users. You are correct should someone manage to get
such a list and automate it correctly they could indeed cause all
legitimate mail to bounce.

On a scale of 1 to 10 (10 being the most concern) I would rate the
possiblity of such a simultaneous attack at a 1 or less.

>
>Also, bounces go into the queue. What happens when there is a
>temporary failure when delivering a bounce? If the bounce is queued,
>the mail queue can be filled up this way. If there is double bounce,
>the local postmaster can be clogged. Deliberate denial of service
>attacks can't be prevented.

Very true, but the effects can be minimized as much as possible.

>
>Bouncing when over quote is only good for controlling user behaviour.
>Forcing them to check their mail frequently, to not send large files,
>to not store extra files in their mail directory. A graded scale of
>temporary and permanent failures based on bandwidth and quota might
>work best for preventing these problems. Some mail (real large files)
>can be safely bounced all the time, but mail should be reliably
>delivered regardless of quota. What happens when one of your
>customers goes on vacation for a month and doesn't check his mail? He
>expects none of it will be permanently lost when he returns and
>finally checks his overquota account.

Here I agree it is good for controling user behaviour, but its not the only
thing its good for. As noted above it does help control the damage caused
if a single user is mailbombed, that in itself is worth the restriction. As
to what happens when a user goes on vacation for a month well, thats up to
the user. They can do 1 or more things to keep the quota from bouncing
mail. First most of my users check their mail even on vacation, Second if
they are going on vacation or an extended business trip they can notify us
and we will extend their quota for the duration of the expected trip, third
they can selectivly forward mail to other users to handle while they are
gone.

My users understand we are not going to hold their hand, nor are we going
to allow their use or lack thereof to disturb the other users use of the
system.


>
> - Ian
>
>--
> -- Ian Burrell == iburrell@leland.stanford.edu **
> <URL:http://www-leland.stanford.edu/~iburrell/>
>Murphy's Golden Rule: Whoever has the gold makes the rules.
>
>

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.


-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

Ian Burrell writes:
> Also, bounces go into the queue.

Depends on when you do the bounce. If you reject a message in
qmail-smtpd, it never hits your system.

--
-russ <nelson@crynwr.com> http://www.crynwr.com/~nelson
Crynwr Software sells network driver support | PGP ok
521 Pleasant Valley Rd. | +1 315 268 1925 voice | Peace, Justice, Freedom:
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | pick two (only mostly true)