[H-GEN] POP3, v42.bis, and the Facts of Life

[W. Sierke]

[ Humbug *General* list - semi-serious discussions about Humbug and
Unix-related topics. ]

Mark,

thanks for your informative reply.

> I really don't know if it matters.  I think that it shouldn't matter
> that one hop, from your PC to the boxen at your ISP, is a compressed
> dialup link.

Agreed. Yet, the person who suggested this to me claimed he had been
suffering similar symptoms and did this (disabled modem compression) at the
suggestion of his ISP and says his problems disappeared. It makes me very
curious since I'm not aware as to why or how this could be. Everything I've
been able to find so far merely talks about the futility of compressing
already compressed data. I've seen nothing that says "using modem
compression over PPP may lead to anger, depression and a sense of
hopelessness"! :)

> I've generally found it to be so.  What POP3 client are using?
> If the answer isn't fetchmail, then I suggest you upgrade :-)

Hehe, soon I will be setting up fetchmail, I suspect. So, you think a POP3
connection will succeed if left indefinitely? Maybe fetchmail simply times
out and restarts the mail collection "process" and you don't see this
because it's hidden activity? (Is this something you could see in the logs
if it was happening?)

> If an error occurs at the POP3 protocol layer, then it should be
> obvious.  It appears that you aren't actually having POP3 problems
> per say, but network issues...

Obvious in what way? Does the configuration of fetchmail include a setting
for timeout waiting for a POP3 server to respond?

> For more info on POP3, read RFC 1939, aka STD 53, as follows.
>
>     http://mirror.aarnet.edu.au/rfc/rfc1939.txt

Thanks for the reference, I shall certainly delve in to this when I get a
moment.

> It doesn't sound as though your problem is the ISP you are dialing
> into.  Maybe you should consider .forward'ing the email to a better
> location?

Except that I've experienced the problem to two servers, one of which
belongs to this ISP. As I mentioned originally, only the first three nodes
appear to be common to the routes to two servers, (and on at least the last
occasion I had problems, it was happening with both of them). I've had some
pretty poor answers to (not-too) technical questions from this ISP, so I
certainly don't consider their technical expertise to be beyond suspicion.
(Of course, narrowing it down like this also places my own connection under
more light of suspicion - but I'm not buying that until I see some technical
explanation for it [the compression business]).

> As for tools, try "mtr" or some of the following traceroute pages.
> Have a look at the BSD ports network tools for other options.
>
>     http://www.questnet.net.au/cgi-bin/nph-tr1
>     http://www.telstra.net/cgi-bin/trace
>     http://www.debug.net/connectivity/

So, traceroute is as good as we have? Pity there's not a standardised and
public measurement of, well, all the technical things that happen on the
internet (dropped packets, failed routes, etc) so we can see who's not
pulling their weight.

Well, thanks again, Mark. Time to go and do a little light reading, I guess.

Regards,


Wayne



--
This is list (humbug) general handled by majordomo at lists.humbug.org.au .
Postings only from subscribed addresses of lists general or general-post.