On Sat, Jun 09, 2001 at 03:11:59PM -0400, Russell Nelson allegedly wrote:
> Greg White writes:
> > I think we may have red-herringed on the OS thing -- if RH6.2, as
> > deployed, had this sort of problem, I think we would have run across it
> > before this, no?
>
> Hmmm.... I wonder. I could do a denial of service attack on
> qmail-remote by receiving email very, very slowly,
You'd also have to set the TCP/IP receive window size down, otherwise
you may think you're only receiving at one byte every, say, 20
minutes, but in fact your TCP/IP stack got a window full of data at
one time.
But yes, you could slow it down considerably and if you got to the
extreme limit of 20 minutes per byte, a 1M email will take about 9
months...
It sure is the case that some sort of gross delivery timer makes sense
and it would work around the problem that initiated this thread...
> and by sending
> email to a server which is guaranteed to be received and guaranteed to
> bounce. qmail doesn't keep track of very slow hosts, but only hosts
> that time out.
Of course it has to be your server that accepts the traffic slowly so
it's a DOS on yourself at the same time. Not the typical MO for a
successful DOS.
This is only proof of concepts, but to implement a gross timer, you
might use this program as a wrapper to qmail-remote (which of course
you move to qmail-remote.real):
main(int argc, char **argv)
{
alarm(5*60*60); /* Max of five hours for a remote delivery */
execv("/var/qmail/bin/qmail-remote.real", argv);
_exit(1);
}
This wrapper gives qmail-remote an arbitrary 5 hours to make a
delivery at which point qmail-remote gets a SIGALRM which it happens
not to have registered a handler for and thus the OS takes the default
action which is to terminate the process.
Regards.
