Re: large attachments, tcpserver & timeouts

1999-06-18 Thread Anonymous

On Fri, Jun 18, 1999 at 09:34:05AM -0700, Aaron L. Meehan wrote:
> On the assumption it's a client-side issue, we're upgrading our CD to
> install Netscape 4.5, instead of the current 4.04 version.  Could be
> 4.04 is buggy in that respect, but I've seen the problem with many
> other mail clients as well.

There is a big problem with a lot of POP clients, with the "lookup
for new mail interval".
If the client doesn't get the eMail within that timeout it gets an
interupt, hangs up the current transfer, does a "LIST" and starts over
and over and over ...

Other things are e.g. firewalls that put limits on the amount of data
that is allowed to be transferred during one POP session (*sigh*)

I've also seen cases where the POP client doesn't handle "disk full"
situations (on the client disk) correctly.

What we do if everything else fails is call the customer and do a
transfer under control of e.g. tcpdump.
We had cases where the client simply "hard" closed the TCP connection
during transfers without any CLOSE/FIN whatever packets and refused to
talk any more (Windows environments). Reinstalling the client mostly
fixed the problems.

Hope that helps.

\Maex



Re: large attachments, tcpserver & timeouts

1999-06-18 Thread Anonymous

Quoting Sam ([EMAIL PROTECTED]):
> Aaron Nabil writes:
> > Several people on the list have reported timeout problems 
> > with clients like Outlook when using tcpserver and qmail's pop3.
[...]
> > Something is wrong with tcpserver.
> 
> Before you start making conclusions, try to actually look at tcpserver's
> source code.
> 
> After the connection is received, tcpserver forks and execs the server, at
> which point the forked tcpserver ceases to exist.
> 
> It would be rather impressive for tcpserver to affect an existing
> connection when it is no longer running.

I am in agreement that it's likely not tcpserver.  I sure do wish I
knew exactly what it was, however, since large attachments are among
our top tech support problems.  I hear all the time "my friends can
get large attachments but I can't" so customers assume it's our fault.

On the assumption it's a client-side issue, we're upgrading our CD to
install Netscape 4.5, instead of the current 4.04 version.  Could be
4.04 is buggy in that respect, but I've seen the problem with many
other mail clients as well.

Aaron



Re: large attachments, tcpserver & timeouts

1999-06-18 Thread Anonymous

Aaron Nabil writes:

> Sam writes...
> >Aaron Nabil writes:
> >
> >> 
> >> Several people on the list have reported timeout problems 
> >> with clients like Outlook when using tcpserver and qmail's pop3.
> >> 
> >> . . .
> >> 
> >> Something is wrong with tcpserver.
> >
> >Before you start making conclusions, try to actually look at tcpserver's
> >source code.
> >
> >After the connection is received, tcpserver forks and execs the server, at
> >which point the forked tcpserver ceases to exist.
> >
> >It would be rather impressive for tcpserver to affect an existing
> >connection when it is no longer running.
> 
> Tcpserver sets up the environment, signal handling and masks, and 
> creates the descriptors (and sets options on them) for the child.  It
> _would_ be impressive for tcpserver to affect a forked and execed pop
> connection, but that's hardly germaine.  To bugger up a pop session,
> all the tcpserver has to do is pollute the signal environment, fail to 
> set or clear some critical process limit, or mess up one of the 
> descriptors it passed to the child in any one of countless ways.  It

And if that was so, it would be plainly visible in the source code.


-- 
Sam



Re: large attachments, tcpserver & timeouts

1999-06-18 Thread Anonymous

+ Aaron Nabil <[EMAIL PROTECTED]>:

| And that tcpserver, unlike inetd, doesn't attach stderr to the
| network connection.  In fact all of the children inherit tcpserver's
| stderr!  I don't see any obvious side-effect of this yet.

This is undoubtedly intentional, and quite useful.  You can just pipe
the stderr of tcpserver into your favourite logging tool, and have the
spawned children log stuff that way.  If you ever *need* to have the
child's stderr connected to the network socket, it is of course
trivial to arrange this.

- Harald



Re: large attachments, tcpserver & timeouts

1999-06-18 Thread Anonymous

Sam writes...
>Aaron Nabil writes:
>
>> 
>> Several people on the list have reported timeout problems 
>> with clients like Outlook when using tcpserver and qmail's pop3.
>> 
>> . . .
>> 
>> Something is wrong with tcpserver.
>
>Before you start making conclusions, try to actually look at tcpserver's
>source code.
>
>After the connection is received, tcpserver forks and execs the server, at
>which point the forked tcpserver ceases to exist.
>
>It would be rather impressive for tcpserver to affect an existing
>connection when it is no longer running.

Tcpserver sets up the environment, signal handling and masks, and 
creates the descriptors (and sets options on them) for the child.  It
_would_ be impressive for tcpserver to affect a forked and execed pop
connection, but that's hardly germaine.  To bugger up a pop session,
all the tcpserver has to do is pollute the signal environment, fail to 
set or clear some critical process limit, or mess up one of the 
descriptors it passed to the child in any one of countless ways.  It
would be a trivial patch to tcpserver to cause your popserver
sessions to magically self-destruct after being connected for 30
seconds (not withstanding that it would be "impressive for tcpserver 
to affect an existing connection when it is no longer running"), long
after tcpserver has forked and exec'd itself in oblivion.

The only two things I've noticed about tcpserver so far are that
this setsockopt call seems kinda risky (from having seen a few 
setsockopt implementations, I wouldn't be surprised if the call fails).

if (flagkillopts) {
  setsockopt(t,IPPROTO_IP,1,(char *) 0,0); /* 1 == IP_OPTIONS */
  /* if it fails, bummer */
}

I would have used the safer and undoubtably correct...

if (flagkillopts) {
  int opt = 0;
  setsockopt(t,IPPROTO_IP,1,&opt,sizeof(opt)); /* 1 == IP_OPTIONS */
  /* if it fails, bummer */
}

And that tcpserver, unlike inetd, doesn't attach stderr to the
network connection.  In fact all of the children inherit tcpserver's
stderr!  I don't see any obvious side-effect of this yet.

-- 
Aaron Nabil



Re: large attachments, tcpserver & timeouts

1999-06-17 Thread Anonymous

Aaron Nabil writes:

> 
> Several people on the list have reported timeout problems 
> with clients like Outlook when using tcpserver and qmail's pop3.
> 
> Unlike many replies suggest, it isn't a problem with client
> software.  It's unlikely to be a problem with qmail's pop3
> server either.
> 
> I just got a note from our tech support department that people
> were intermittantly having problems downloading large 
> attachemnts, starting a couple days ago.  They wanted to know
> if it was the "new mail server".
> 
> I dismissed this off hand since I hadn't installed qmail yet,
> but then I realized I had installed a tiny little bit 'o qmail
> a couple days ago.  I replaced our cucipop in daemon mode 
> with cucipop running under tcpserver.
> 
> Something is wrong with tcpserver.

Before you start making conclusions, try to actually look at tcpserver's
source code.

After the connection is received, tcpserver forks and execs the server, at
which point the forked tcpserver ceases to exist.

It would be rather impressive for tcpserver to affect an existing
connection when it is no longer running.


-- 
Sam



large attachments, tcpserver & timeouts

1999-06-17 Thread Anonymous


Several people on the list have reported timeout problems 
with clients like Outlook when using tcpserver and qmail's pop3.

Unlike many replies suggest, it isn't a problem with client
software.  It's unlikely to be a problem with qmail's pop3
server either.

I just got a note from our tech support department that people
were intermittantly having problems downloading large 
attachemnts, starting a couple days ago.  They wanted to know
if it was the "new mail server".

I dismissed this off hand since I hadn't installed qmail yet,
but then I realized I had installed a tiny little bit 'o qmail
a couple days ago.  I replaced our cucipop in daemon mode 
with cucipop running under tcpserver.

Something is wrong with tcpserver.

-- 
Aaron Nabil