Every time I have run into the large email download problem it is because
the clients email software would reach its mail check time and abort the
current download and start over. This is buggy client code, not the
server. :) When we have a customer call, we tell them to turn of the
auto mail check, perform a manual download and restart the auto mail check
after the manual check completes. This has worked every time for us.
On Fri, 28 Jan 2000, Jonathan Herbert wrote:
> On Fri, Jan 28, 2000 at 08:50:58AM -0800, Mark Delany wrote:
> > On Fri, Jan 28, 2000 at 11:25:51AM -0500, Jonathan Herbert wrote:
> >
> > > > > On 28 Jan 00, at 11:29, Henrik �hman wrote:
> > > > > > A user just sent 2 subsequent mails to a mailing list, both including quite
> > > > > > large attachments (looking in ~user/list/archive, the files are 1,2Mb and
> > > > > > 730kb respectively) to 21 users. This is quite heavy on a 128kbit line,
>esp.
> > > > > > since concurrencyremote is 20, so I expect that each qmail-remote takes its
> > > > > > share of the bandwidth, leaving 128/20 kbit per delivery.
> > >
> > > I've implemented qmail in a number of environments, including small to
> > > medium sized ISPs, research groups, and private companies as well. One of
> > > the main complaints has always been the amorphous "problem with large
> > > attachments".
> > >
> > > 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
> > running on a 486 with 8MB or memory and a 2400bps link or a 64x CPU E10000
> > with a couple gig of memory and an OC48 connection to the Internet.
>
> 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.
>
> > 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 :-)
>
> > Based on this, my suggestion is that resource consumption by anything that runs
> > on a system is something that should be controlled by the admin. That qmail lets
> > you utilize the system resource controls to *gracefully* control just about every
> > resource type on a system means that you can tune it fairly precisely to your
>needs.
>
> [...]
>
>
> Well, obviously there are too many factors involved to pinpoint the problem
> specifically, but that in itself tends to problematic.
>
> Even ruling out user error, configuration mishaps, wind sheer, and solar
> radiation, users still tend to complain about the mailserver [qmail] not
> handling large messages well.
>
> Similarly, i've never encountered it in any capacity which could be viewed
> as debilitating.
>
> I'm simply wondering if this is a known issue- it seems that i'm not the
> only one whos run into this in some way shape or form. And it's that which
> makes me think there is more substantiality to this claim than is openly
> realized.
>
> Jonathan
>
> [PS, i'm not trolling. please dont think i'm trolling, I know how
> defensive this list can get on occasion. :)]
>
>
---------------------------------
Timothy L. Mayo mailto:[EMAIL PROTECTED]
Senior Systems Administrator
localconnect(sm)
http://www.localconnect.net/
The National Business Network Inc. http://www.nb.net/
One Monroeville Center, Suite 850
Monroeville, PA 15146
(412) 810-8888 Phone
(412) 810-8886 Fax
