On Fri, Jan 28, 2000 at 09:53:28AM -0800, Mark Delany wrote:
> > > > I can't imagine that this could be entirely the OS's fault, considering this
> > > > tends to be a consistent problem regardless of architecture or OS.
> > >
> > > Which problem in particular? qmail has no clue as to whether it is really
>
> > Err, the "large attachment" problem. I don't consider this a resource issue
> > per se; the problem i've experienced more so is the poor handling of
> > extremely large messages.
>
> > To elaborate, users who retrieve large messages via pop3, or transmit large
> > messages via smtp often complain about being disconnected, timing out, or a
> > myriad of other equally vague problems.
>
> Having worked in an ISP environment for many years I can only say that this
> problem is rampant in the industry. I've seen it with qmail, I've seen it with
> qpopper, I've seen it with sendmail, I've seen it with large http documents,
> I've seen it with large ftps...
I agree.
What's curious is that this problem has been so especially prevalent with
qmail.
Obviously, i'm much more suspicious of the MUA. I'm not doubting qmail's
integrity- heck thats why i use it in the first place :), but this has
always left me somewhat perplexed.
It's difficult explaining to people that sometimes things simply dont work,
and it's more than likely their fault for being victimized by industry
propaganda, buying useless equipment, and then expecting to integrate it
seemlessly with my sacrosanct network of the future. An exaggeration,
obviously, but you know what I mean, I'm sure. :)
> Note that the code in qmail is typically *much* simpler than most of the code
> that handles socket traffic (has anyone looked at qpopper 3?) which literally
> boils down to nothing much more than:
>
> while (data = read_from_mail_file()) {
> write_data_to_socket();
> }
>
> I've spent a lot of time looking at these problems and this code and I
> find it very hard to understand what the code could do that would alleviate
> the problem. It totally relies on the OS to manage the TCP/IP session,
> as it should.
That's true.
> > > The only person with the possibility of having such a clue is the person who
> > > admins the system.
> >
> > Thanks for that outstanding vote of confidence :-)
>
> Well, I had to assign intelligence to you or the s/w. I chose you.
Thanks.. er.. i think ;)
> > Well, obviously there are too many factors involved to pinpoint the problem
> > specifically, but that in itself tends to problematic.
>
> Right. There is the line of code in qmail that goes write(), then there
> is the OS TCP/IP stack, then typically there is an ethernet card on your machine,
> then no doubt a hub - perhaps switched - then a router, then maybe an access
> server, then maybe a modem, a phone line, another modem, a serial port,
> a ppp layer on a PC, a TCP/IP layer on a PC, a winsock layer, then a PC
> application that is often very sensitive to the contents of the email.
>
> I'm obviously being sarcastic here, but how would you like to change the
> write() call in qmail exactly?
well, yeah..
I guess super_terrific_write() is out of the question? *duck*
The bottom line i suppose is that there is an arguably infinite number of
variables which could contribute to this, more than likely the majority of
which wouldn't be worth discussing anyhow :)
Off topic, does qmail posess any intrinsic throttling capabilities? I'm
going to guess not, but it'd be interesting to think about.
Jonathan
