Menu
▾
▴
fetchmail-users
|
From: Ben J. <be...@po...> - 2007-04-12 15:34:01
|
Dear Rob, On the adsl line the same box works fine. And if they use outlook on the satellite it works fine so they say it is the fetchmail. The -vvv gives me: Remember it happens on random messages and if I go in via webmail and delete this one it can happen again in the future on another one. fetchmail: POP3> LIST 12 fetchmail: POP3< +OK 12 3073 fetchmail: POP3> TOP 12 99999999 fetchmail: POP3< +OK reading message :12 of 126 (3073 octets) About to rewrite Return-Path: <> Rewritten version is Return-Path: <> About to rewrite From: =?windows-1251?B?wujq8u7wIMLg6+Xt8ujt7uLo9w==?= <a Rewritten version is From: =?windows-1251?B?wujq8u7wIMLg6+Xt8ujt7uLo9w==?= < About to rewrite Reply-To: Rewritten version is Reply-To: About to rewrite To: Bt Rewritten version is To: Bt fetchmail: socket error while fetching from fetchmail: 6.3.8 querying (protocol POP3) at Thu Apr 12 14:28:25 2007: poll completed fetchmail: discarding new UID list fetchmail: Query status=2 (SOCKET) fetchmail: Writing fetchids file. fetchmail: normal termination, status 2 fetchmail: Writing fetchids file. > ----- Original Message ----- > From: "Rob MacGregor" <rob...@gm...> > To: fet...@li... > Subject: Re: [fetchmail-users] Fetchmail Socket error on a satellite connection > Date: Thu, 12 Apr 2007 13:26:04 +0100 > > > On 4/12/07, Ben Jsh <be...@po...> wrote: > > Dear All, > > I am having trouble downloading mail via POP3 with the latest > > 6.3.8 and all versions. > > > > I tried popping the same account from a adsl line and it worked > > but when I do it over the satellite connection it fails. > > Which says that you have a comms problem and that it isn't software > related (on the assumption that you're talking about the same system > running fetchmail). At a rough guess it is probably due to the highly > asymmetric nature of the link. There isn't going to be anything you > can do to fetchmail to fix this. > > You *may* be able to tune the network settings on your OS (whatever it > is) to compensate. > > <---SNIP---> > > fetchmail: Query status=2 (SOCKET) > > fetchmail: Deleting fetchids file. > > fetchmail: normal termination, status 2 > > fetchmail: Deleting fetchids file. > > Socket errors are almost always down to your network connection, though > sometimes due to the remote system (see the FAQ). I've never yet seen > them being caused by fetchmail. > > -- > Please keep list traffic on the list. > > Rob MacGregor > Whoever fights monsters should see to it that in the process he > doesn't become a monster. Friedrich Nietzsche > _______________________________________________ > fetchmail-users mailing list > fet...@li... > https://lists.berlios.de/mailman/listinfo/fetchmail-users > = |
|
From: Rob M. <rob...@gm...> - 2007-04-13 00:14:45
|
Once more, with feeling - keep the traffic on the list so that others
can benefit from this in the future and provide assistance. I'm not
here to personally support you...
On 4/12/07, Ben Jsh <be...@po...> wrote:
>
> OK.
> I am running a Linux what other ways or something else I can do to tune the network.
Which version, what kernel? If you're having to ask then you need the
help of somebody who really knows what they're doing, and has access
to your systems. You/they will need to look at the various reported
stats and errors from netstat. A quick indicator would be from:
netstat -s | egrep -i "retrans|error"
A high number of errors or retransmissions (particularly if they keep
growing rapidly) indicate probable network problems.
Keep in mind that there are 2 parties in all of this - it may well be
that the real problem is at the other end, over which you have no
control.
> There is a constant ping on the line between 650-1500 MS when I ping google and on the adsl it is 40 ms all the time !?!
Ping stats aren't a good measure of anything beyond, at best, latency.
The difference is because with the satellite link you're travelling a
*lot* further (about 45,000 miles from ground to satellite and back -
almost twice the circumference of the earth).
> They also told me another error they had from the windows system.
>
> Why do the fetchmail not silently reconnect like outlook if it solves problems?
Maybe it solves the problem, maybe it doesn't. General unix
philosophy is to not hide details from the end user. If it's
intermittent then the next poll will solve it. If it isn't, you
probably want to know when it really started.
> On the windows box they sometimes get
> mail box contains 85 messages with a total size of 18980048
> receiving message no 27 (6755b)
> connection error (winsock: returned by WSARecv or WSARecvFrom to indicate
> the remote party has initiated a graceful shutdown sequence)
>
> So it seems their windows also got problems?
Well, it seems your satellite link has the problem, which both myself
and Matthias have been saying from the start...
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
|
From: Matthias A. <mat...@gm...> - 2007-04-13 00:34:28
|
Rob MacGregor schrieb: > Well, it seems your satellite link has the problem, which both myself > and Matthias have been saying from the start... Thanks for your patience with him. I'm not going to invest further efforts to obtain information from any reporter beyond asking essential information once and then just ignore the remainder of the thread if that information doesn't show up. I'm afraid I don't have time (and do not want to take time either) for anything more than that. A plea for help does need some cooperation from the receiving end - and that's the very least I can expect for free-of-charge support, most of the time. Happy fetching, MA |
|
From: Steve S. <ker...@si...> - 2007-04-13 08:37:31
|
Matthias Andree wrote: > > I'm not going to invest further efforts to obtain information from any > reporter beyond asking essential information once and then just ignore > the remainder of the thread if that information doesn't show up. You and Rob are very helpful and very patient people. Perhaps you guys are a bit too subtle and offer a bit too much advice before someone provides the necessary information. I follow most of the threads here and I suspect that your subtle hints about reading the FAQ get lost among all the helpful ideas. I think a polite, to the point, statement such as "Please provide the information requested in the FAQ (http://www.fetchmail.info/fetchmail-FAQ.html#G3) and we will be happy to help you" and *nothing* else, would get the point across without making the neophyte feel unwelcome. Your desire to be kind is biting you in the arse! Steve |
|
From: Rob M. <rob...@gm...> - 2007-04-13 10:48:28
|
On 4/13/07, Steve Sheftic <ker...@si...> wrote: > > You and Rob are very helpful and very patient people. Perhaps you guys > are a bit too subtle You know, that's the first time in a long time anybody has said I'm either subtle or patient :-) > and offer a bit too much advice before someone > provides the necessary information. I follow most of the threads here > and I suspect that your subtle hints about reading the FAQ get lost > among all the helpful ideas. I think a polite, to the point, statement > such as "Please provide the information requested in the FAQ > (http://www.fetchmail.info/fetchmail-FAQ.html#G3) and we will be happy > to help you" and *nothing* else, would get the point across without > making the neophyte feel unwelcome. Your point is well made, and I am sometimes tempted to simply take that approach. The trouble is that a simple, (and often a repeated), "provide this or we won't help you" and "it's in the FAQ" leads to people not asking for help and having a negative view of the product (see the likes of the clamav-users list where that approach has resulted in long flame wars). I'd also say that the FAQ probably needs some updating to make it more friendly. Right now some of the information isn't complete (for example, with reference to socket errors it only refers to PPP settings) and some is probably out of date (refers to RedHat 6.0 as "recent", released AFAIK in 1999). The G3 section also refers to reporting a bug, which likely leads people to ignore it when reporting problems. Finally, it is a single page document and a pretty big one at that. Even I often get frustrated trying to work through it, so I may discuss with Matthias my attempting to make it more usable. There's also sometimes a language barrier where people just don't understand what's being said because English isn't their primary language (and given that that's the only one I understand, I'm limited to using it). I think however I will, like Matthias, end up having to take a somewhat harder line about helping people who don't/won't listen. It would be a shame however - I've been that clueless newbie and know how much of a difference it makes to have somebody patiently lead you towards enlightenment :) Oh, and thanks for the comments - it is useful to have that outside perspective! -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche |
|
From: Matthias A. <mat...@gm...> - 2007-04-13 13:50:23
|
Rob MacGregor schrieb:
> I'd also say that the FAQ probably needs some updating to make it more
> friendly. Right now some of the information isn't complete (for
> example, with reference to socket errors it only refers to PPP
> settings) and some is probably out of date (refers to RedHat 6.0 as
> "recent", released AFAIK in 1999). The G3 section also refers to
> reporting a bug, which likely leads people to ignore it when reporting
> problems. Finally, it is a single page document and a pretty big one
> at that. Even I often get frustrated trying to work through it, so I
> may discuss with Matthias my attempting to make it more usable.
You're most welcome on this task - I haven't kept a close eye on what
part of the information is outdated and what not, and I've so far only
removed the most obvious stale stuff.
I'd like your view on this: Should we provide a short (1 - 2 pages if
printed) document on how to get support efficiently" - perhaps along
DJB's[1] lines of 'what did you do, what did the computer do, what did
you expect' - ESR's smart questions is right, but long-winding for
someone who is on the verge of panicking.
I also think if you want to take a stab at splitting the FAQ, we can
arrange for Subversion access with Graham - let's take this part
off-list or to -devel however.
[1] don't mistake that as an appreciation of his support style, I'm just
quoting one of his frequently asked questions...
> I think however I will, like Matthias, end up having to take a
> somewhat harder line about helping people who don't/won't listen. It
> would be a shame however - I've been that clueless newbie and know how
> much of a difference it makes to have somebody patiently lead you
> towards enlightenment :)
You'll see I worded carefully to give my *personal* view, without any
hints towards what my right hand of the support should do, and I'd say
do what pleases *you* most, unless it's treating people without dignity.
Being a newbie is one thing, and I'm happy to read questions of the "how
do you mean this and that" kind if my instructions are too terse. But
just ignoring my questions without any response is below the threshold
where I stop caring - generally speaking.
Happy fetching
MA
|
|
From: Rob M. <rob...@gm...> - 2007-04-13 15:40:16
|
On 4/13/07, Matthias Andree <mat...@gm...> wrote:
> Rob MacGregor schrieb:
>
> You're most welcome on this task - I haven't kept a close eye on what
> part of the information is outdated and what not, and I've so far only
> removed the most obvious stale stuff.
Strange, nobody likes doing documentation :)
> I'd like your view on this: Should we provide a short (1 - 2 pages if
> printed) document on how to get support efficiently" - perhaps along
> DJB's[1] lines of 'what did you do, what did the computer do, what did
> you expect' - ESR's smart questions is right, but long-winding for
> someone who is on the verge of panicking.
I think that, and a simple flow (diagram?) showing how it fits
together so people can more easily understand. I suspect part of the
"problem" is that less technical people are using *nix these days,
meaning that previous assumptions are no longer valid (and that's in
general, not specific to fetchmail by any means).
Some form of diagnosis tool(s) wouldn't be a bad idea either, though
I've no idea what form that would take. Enough to confirm that the
basic networking part is functional and that fetchmail can (or cannot)
talk to the remote server.
Well, I've got a few days off work now so II'll give this some more thought.
> I also think if you want to take a stab at splitting the FAQ, we can
> arrange for Subversion access with Graham - let's take this part
> off-list or to -devel however.
Devel probably makes most sense and I am subscribed there (CCd for
this mail). That way others can throw their 0.02$CURRENCY in :)
> You'll see I worded carefully to give my *personal* view, without any
> hints towards what my right hand of the support should do, and I'd say
> do what pleases *you* most, unless it's treating people without dignity.
Well, given that bugs will only be fixed in the current stable
version, there's little point in trying to support older versions
(which, IMO, is the right approach).
Beyond that, if people won't/don't/can't do what they're asked to do
then there's not really much point in continuing to flog the
proverbial horse. In this case the OP did at least provide the
directly fetchmail related info, just nothing about his (unusual)
comms setup.
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
|
From: Matthias A. <mat...@gm...> - 2007-04-15 11:44:46
|
"Rob MacGregor" <rob...@gm...> writes: > On 4/13/07, Matthias Andree <mat...@gm...> wrote: >> Rob MacGregor schrieb: >> >> You're most welcome on this task - I haven't kept a close eye on what >> part of the information is outdated and what not, and I've so far only >> removed the most obvious stale stuff. > > Strange, nobody likes doing documentation :) At least not if it's documentation pertaining to code due to change anyways :) > Some form of diagnosis tool(s) wouldn't be a bad idea either, though > I've no idea what form that would take. Enough to confirm that the > basic networking part is functional and that fetchmail can (or cannot) > talk to the remote server. Python script perhaps, Python is widespread today. > Beyond that, if people won't/don't/can't do what they're asked to do > then there's not really much point in continuing to flog the > proverbial horse. In this case the OP did at least provide the > directly fetchmail related info, just nothing about his (unusual) > comms setup. I wouldn't even call it unusual comms setup without knowing the details, but that it gives him headaches while ADSL doesn't is reason for his concern. Anyways, the valid point is that just "socket error" isn't a very detailed report. -- Matthias Andree |
|
From: Rob M. <rob...@gm...> - 2007-04-12 15:43:19
|
[ Keep it on the list please ]
On 4/12/07, Ben Jsh <be...@po...> wrote:
> Dear Rob,
>
> On the adsl line the same box works fine.
So we've ruled out fetchmail as the cause/source, again.
> And if they use outlook on the satellite it works fine so they say it is the fetchmail.
A sign of people not willing to look into the problem :)
It could be:
1) Windows network tuning is different, so it handles the asymmetry better
2) Outlook silently reconnects and you never know there was a problem
3) Something else
> The -vvv
> gives me:
>
<---SNIP--->
> fetchmail: socket error while fetching from
Network/communication failure, nothing fetchmail can do (assuming
you've not snipped too much - it would be better if you were to
replace what you're cutting out with, say, xxxx so we know where
you've removed stuff).
Somebody probably needs to look at the network settings of your (I'm
guessing) Linux box, (you haven't said) vs those of the Windows box.
They also want to do lots of packet capture and see what happens
when/if the connection dies on Outlook.
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X