fetchmail-users — User questions and discussion

[fetchmail-users] Documentation for configuring Fetchmail with RT

[Sridhar A. <ram...@ya...>]

Hi All,

I'm new to this tool. I want information on how to configure Fetchmail with RT. Unable to get details for configuring Fetchmail for Windows 2000 Server. I'm trying to implement on my local system so that if it running fine then I can implement on live server.

I configured rt-mailgate.conf as follows:
 
poll mail.ekspertech.com proto pop3:
username giri password xxxx mda "c:/Progra~1/OurInternet/Common/perl/bin/perl.exe c:/Progra~1/Ourinternet/Reques~1/rt/bin/rt-mailgate.in --url http://192.168.1.113:8284/ --queue GENERAL --action correspond"


When I'm trying to start it giving me a Bad Pool caller error message and restarting Windows 2000 server.

Please help me, if anyone can provide me documentation for Windows that's much appreciated.

Regards,
Sridhar

       
---------------------------------
Ahhh...imagining that irresistible "new car" smell?
 Check outnew cars at Yahoo! Autos.
       
---------------------------------
Ahhh...imagining that irresistible "new car" smell?
 Check outnew cars at Yahoo! Autos.

Re: [fetchmail-users] Fetchmail Bouncing messages back from odd address

[Rob M. <rob...@gm...>]

On 4/24/07, Michael da Silva Pereira <mi...@tr...> wrote:
> Hi,
>
> I wonder if anybody has got this before, I have a multi drop address and all
> works fine, except when fetchmail bounces an address which is not accepted
> by my exim server.
>
> The message originates from "MAILER-DAEMON@localhost", I would like to
> change that to a legitimate address. I haven't found this anywhere on how to
> do so, any ideas?

I suspect your messages are from exim as fetchmail does not use (as
far as I can tell) MAILER-DAEMON but FETCHMAIL-DAEMON.

-- 
                 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

Re: [fetchmail-users] forcing a fetch cycle.

[Matthias A. <mat...@gm...>]

Joe Acquisto schrieb:

> When I did a "fetchmail" at a console screen, it told me it was awakened.  Will that force a cycle?

Yes, it will -- that is unless the account you're fetching from has a
nondefault interval configured.

[fetchmail-users] forcing a fetch cycle.

[Joe A. <jo...@j4...>]

Lets say one is waiting for a critical email and is impatient to wait for the assigned cycle time.

Is there a polite way to "do it now"?  

When I did a "fetchmail" at a console screen, it told me it was awakened.  Will that force a cycle?

Sorry if this is a really too simple.

joe a.

Re: [fetchmail-users] Dangerous bug: losing messages into nowhere

[Matthias A. <mat...@gm...>]

(sorry Volker, this message was meant for the list, of course)

On Sun, 15 Apr 2007, Volker Kuhlmann wrote:

> On Sun 15 Apr 2007 22:04:25 NZST +1200, Antonio Capanna wrote:
> 
> > Yes, the server sends invalid data, but IMHO fetchmail should NEVER
> > lose a message (except where stated in the documentation), i.e.:
> > - fetchmail understands the message -> it handles it and deletes it
> > - fetchmail does not understand the message -> it forgets about it but
> > does not delete it from the server. This means, it's true, that the
> > message will be downloaded and discarded again all the subsequent
> > times,
> 
> In this case it would also be necessary to send a warning somehow,
> because you're DoS'ing yourself: ignoring the wasted traffic, eventually
> your mailbox at your mail provider will be full and no more mail is
> accepted for you.

Indeed.

Well, a way in between would be to take junk at the beginning and
prepend X-Fetchmail-Garbage-Before-Header: and consider the next invalid
header the begin of the body and terminate the header there, put a
message there and then continue - which might however corrupt MIME
multiparts.

Whatever fetchmail is doing at that time, someone will be upset...

-- 
Matthias Andree

Re: [fetchmail-users] Dangerous bug: losing messages into nowhere

[Volker K. <lis...@pa...>]

On Sun 15 Apr 2007 22:04:25 NZST +1200, Antonio Capanna wrote:

> Yes, the server sends invalid data, but IMHO fetchmail should NEVER
> lose a message (except where stated in the documentation), i.e.:
> - fetchmail understands the message -> it handles it and deletes it
> - fetchmail does not understand the message -> it forgets about it but
> does not delete it from the server. This means, it's true, that the
> message will be downloaded and discarded again all the subsequent
> times,

In this case it would also be necessary to send a warning somehow,
because you're DoS'ing yourself: ignoring the wasted traffic, eventually
your mailbox at your mail provider will be full and no more mail is
accepted for you.

Volker

-- 
Volker Kuhlmann			is list0570 with the domain in header
http://volker.dnsalias.net/	Please do not CC list postings to me.

Re: [fetchmail-users] Dangerous bug: losing messages into nowhere

[Antonio C. <pir...@ya...>]

> Rob MacGregor <rob...@gm...> writes:

> Note though that your local SMTP server would likely have refused
> these messages, probably with a permanent failure due to their being
> malformed.  This would then have resulted in fetchmail deleting them,
> so effectively fetchmail just cut the SMTP server out of the decision
> loop :>  (Neither is an ideal situation though, I agree)

:-)

Actually, I just made this test. I patchd transact.c and removed the
line that discards the messages in this case, and then I tried again.
It happens that my postfix+maildrop configuration accepts the message,
and rewrites a new (partial) set of headers for it. But this is just
postfix: probably, other SMTP servers would react differently.

>                  Please keep list traffic on the list.

Sorry, I clicked "reply to all" without paying attention.

> Rob MacGregor

Thanks,
good bye,
Guido


      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html

Re: [fetchmail-users] Dangerous bug: losing messages into nowhere

[Rob M. <rob...@gm...>]

On 4/15/07, Antonio Capanna <pir...@ya...> wrote:
<---SNIP--->
> Another possibility is to delete it from the server but save it
> somewhere else.
>
> What do you think?

Some time back (last year probably) this topic came up and one
suggestion was that malformed messages should be stuck inside a
text/plain message part and forwarded to the postmaster.

The main reason being that fetchmail can't guarantee to identify
what's wrong (the last thread was related to there being no blank line
separating the headers from the body).  By forwarding the entire
broken message to the postmaster then the postmaster can at least
decide what to do.

Note though that your local SMTP server would likely have refused
these messages, probably with a permanent failure due to their being
malformed.  This would then have resulted in fetchmail deleting them,
so effectively fetchmail just cut the SMTP server out of the decision
loop :>  (Neither is an ideal situation though, I agree)

-- 
                 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

Re: [fetchmail-users] Dangerous bug: losing messages into nowhere

[Antonio C. <pir...@ya...>]

Matthias Andree <mat...@gm...> writes:

> First of all, thanks for the very detailed report - it's very nice to
> see complete reports with all information.

:) You're welcome

> This is a known issue (I'm loathe to call it a fetchmail bug though,
> because basically, the server sends invalid data and it's the server
> that needs fixing), but I think Gentoo are actually patching that - I
> fear fixing it in 6.3 though as people might then see garbage and
> complain about it.

Yes, the server sends invalid data, but IMHO fetchmail should NEVER
lose a message (except where stated in the documentation), i.e.:
- fetchmail understands the message -> it handles it and deletes it
- fetchmail does not understand the message -> it forgets about it but
does not delete it from the server. This means, it's true, that the
message will be downloaded and discarded again all the subsequent
times, but I think this is better than completely losing a message. If
I wasn't checking the fetchmail logs when I started it, I would have
lost hundreds of messages from my mail server (it seens that all the
messages on that server have this strange header line).

Another possibility is to delete it from the server but save it
somewhere else.

What do you think?

> I will fix this for the next major release though.
> 
> > +OK
> > 000000000000000036333551
> > Received: from server.doma.in ([23.45.67.89])
> >         by mailserver.doma.in (Merak 8.2.4) with ESMTP id DWH39514
> >         for <gu...@ma...>; Fri, 19 Jan 2007 06:42:34
> > +0100
> 
> HTH.
> 
> Best regards,
> 
> -- 
> Matthias Andree

Thank you very much for your prompt answer, I will have a look at the
Gentoo patch.

Kind Regards,
Guido



      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html

Re: [fetchmail-users] [fetchmail-devel] Fetchmail Socket error on asatellite connection

[Matthias A. <mat...@gm...>]

"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

Re: [fetchmail-users] Dangerous bug: losing messages into nowhere

[Matthias A. <mat...@gm...>]

Antonio Capanna <pir...@ya...> writes:

> I think fetchmail loses messages when a malformed header is present and
> POP3 is used.
> Put it shortly, if a message begins with (i.e., the first line of the
> headers is) a line with only a number (e.g.
> "000000000000000036333551"), the message is retrieved from the server,
> deleted, but not forwarded to the local mail server (nor bounced back).
> I don't know how did this line got there (the mail server which I am
> downloading the mail from is not administered by me), but fetchmail
> shouldn't lose the message anyway.

First of all, thanks for the very detailed report - it's very nice to
see complete reports with all information.

This is a known issue (I'm loathe to call it a fetchmail bug though,
because basically, the server sends invalid data and it's the server
that needs fixing), but I think Gentoo are actually patching that - I
fear fixing it in 6.3 though as people might then see garbage and
complain about it.

I will fix this for the next major release though.

> +OK
> 000000000000000036333551
> Received: from server.doma.in ([23.45.67.89])
>         by mailserver.doma.in (Merak 8.2.4) with ESMTP id DWH39514
>         for <gu...@ma...>; Fri, 19 Jan 2007 06:42:34
> +0100

HTH.

Best regards,

-- 
Matthias Andree

[fetchmail-users] Dangerous bug: losing messages into nowhere

[Antonio C. <pir...@ya...>]

Hello,

I think fetchmail loses messages when a malformed header is present and
POP3 is used.
Put it shortly, if a message begins with (i.e., the first line of the
headers is) a line with only a number (e.g.
"000000000000000036333551"), the message is retrieved from the server,
deleted, but not forwarded to the local mail server (nor bounced back).
I don't know how did this line got there (the mail server which I am
downloading the mail from is not administered by me), but fetchmail
shouldn't lose the message anyway.

Here is a more detailed description of the problem, and some additional
information.

I run a Linux Fedora Core 6, with kernel 2.6.20.4.

I have the latest version of fetchmail (6.3.8). I built it from the
sources downloaded on Berlios, using the spec file from the fetchmail
6.3.7 package of Fedora Core.
The same problem happened with all the other versions I tried:
- fetchmail 6.3.6-2 (the rpm from the Fedora Core 6 updates)
- fetchmail 6.3.7-1 (the rpm from Fedora Core 6.92).

The message which gets deleted is a normal message, but, before the
first line there is a line with only a number (=> malformed header
line).
Here is a log from a telnet to port 110 of the POP3 server, followed by
a log of the subsequent fetchmail call in which I try to download the
same message.
Note: in this and the following example, I only masked:
- password
- server names and IP addresses
- email addresses of other people
- subject of the e-mail
- unique mail IDs and key fingerprint
- company name


[guido@localhost ~]$ telnet mailserver.doma.in 110
Trying 12.34.56.78...
Connected to mailserver.doma.in.
Escape character is '^]'.
+OK mailserver.doma.in Merak 8.9.1 POP3 Sun, 15 Apr 2007 03:05:09 +0200
<200...@ma...>
USER guido
+OK guido
PASS mypassword
+OK 330 messages (4548411) octets
TOP 1 1
+OK
000000000000000036333551
Received: from server.doma.in ([23.45.67.89])
        by mailserver.doma.in (Merak 8.2.4) with ESMTP id DWH39514
        for <gu...@ma...>; Fri, 19 Jan 2007 06:42:34 +0100
Received: from localhost (localhost [127.0.0.1])
        by server.doma.in (Postfix) with ESMTP id 7E431219155;
        Fri, 19 Jan 2007 06:42:51 +0100 (CET)
Received: from server.doma.in ([127.0.0.1])
 by localhost (server.doma.in [127.0.0.1]) (amavisd-new, port 10025)
 with LMTP id 25102-01-42; Fri, 19 Jan 2007 06:42:48 +0100 (CET)
Received: from whatever.site (whatever.domain.name [34.56.78.90])
        by server.doma.in (Postfix) with SMTP id 6731B41793E;
        Fri, 19 Jan 2007 06:42:39 +0100 (CET)
Received: from whatelse ([12.45.78.01])
        by another.site (8.12.0/8.12.0) with SMTP id 4115586132701
        for <gu...@do...>; Fri, 19 Jan 2007 06:42:56 +0100
Message-ID: <001801b73b95$1d34a0d3$006a1e14@whatelse>
From: Somebody <an...@in...dr>
To: gu...@do...
Subject: subject
Date: Fri, 19 Jan 2007 06:42:56 +0100
MIME-Version: 1.0
Content-Type: multipart/related;
        type="multipart/alternative";
        boundary="----=_NextPart_000_0013_01C73B95.0D34F9D0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.1081
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3000
X-Virus-Scanned: amavisd-new at doma.in
X-Spam-Status: No, score=2.227 tagged_above=-10 required=4
tests=[BAYES_60=1,
 EXTRA_MPART_TYPE=1.091, FORGED_RCVD_HELO=0.135, HTML_MESSAGE=0.001]
X-Spam-Score: 2.227
X-Spam-Level: **

This is a multi-part message in MIME format.
.
QUIT
+OK mailserver.doma.in closing connection
Connection closed by foreign host.



Here is the corresponding line from .fetchmailrc:

poll mailserver.doma.in proto POP3 auth password user guido with pass
mypassword is guido here fetchall forcecr fetchlimit 1


Note: if I change protocol (from POP3 to IMAP) I get a similar result.
Obviously the fetchmail log is different, but the message is deleted
from server and neither forwarded nor bounced.


Here is what I get when I run fetchmail:

[guido@localhost ~]$ fetchmail -v -v -v mailserver.doma.in
fetchmail: 6.3.8 querying mailserver.doma.in (protocol POP3) at Sun Apr
15 03:23:29 2007: poll started
Trying to connect to 12.34.56.78/110...connected.
fetchmail: POP3< +OK mailserver.doma.in Merak 8.9.1 POP3 Sun, 15 Apr
2007 03:22:48 +0200 <200...@ma...>
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< TOP
fetchmail: POP3< USER
fetchmail: POP3< APOP
fetchmail: POP3< EXPIRE NEVER
fetchmail: POP3< UIDL
fetchmail: POP3< SASL CRAM-MD5 PLAIN LOGIN DIGEST-MD5
fetchmail: POP3< STLS
fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< +OK Ready to start TLS
fetchmail: Issuer Organization: Foo
fetchmail: Issuer CommonName: mailserver.doma.in
fetchmail: Server CommonName: mailserver.doma.in
fetchmail: mailserver.doma.in key fingerprint:
AA:83:C0:04:2D:0B:FC:1E:65:1E:09:00:A0:2C:7D:77
fetchmail: Server certificate verification error: self signed
certificate
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< TOP
fetchmail: POP3< USER
fetchmail: POP3< APOP
fetchmail: POP3< EXPIRE NEVER
fetchmail: POP3< UIDL
fetchmail: POP3< SASL CRAM-MD5 PLAIN LOGIN DIGEST-MD5
fetchmail: POP3< .
fetchmail: mailserver.doma.in: upgrade to TLS succeeded.
fetchmail: POP3> USER guido
fetchmail: POP3< +OK guido
fetchmail: POP3> PASS *
fetchmail: POP3< +OK 330 messages (4548411) octets
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 330 4548411
330 messages for guido at mailserver.doma.in (4548411 octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 14009
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK 14009 octets
reading message gu...@ma...:1 of 330 (14009 octets)
fetchmail: incorrect header line found while scanning headers
fetchmail: line: 000000000000000036333551
............ flushed
fetchmail: POP3> DELE 1
fetchmail: POP3< +OK Message deleted
fetchmail: fetchlimit 1 reached; 329 messages left on server
mailserver.doma.in account guido
fetchmail: POP3> QUIT
fetchmail: POP3< +OK mailserver.doma.in closing connection
fetchmail: 6.3.8 querying mailserver.doma.in (protocol POP3) at Sun Apr
15 03:23:31 2007: poll completed
fetchmail: not swapping UID lists, no UIDs seen this query
fetchmail: Query status=13 (MAXFETCH)
fetchmail: Deleting fetchids file.
fetchmail: normal termination, status 13
fetchmail: Deleting fetchids file.


Last, this is the output from fetchmail -V:

[guido@localhost ~]$ fetchmail -V -v -v -v mailserver.doma.in
This is fetchmail release
6.3.8+GSS+RPA+NTLM+SDPS+SSL+HESIOD+NLS+KRB4+KRB5.

Copyright (C) 2002, 2003 Eric S. Raymond
Copyright (C) 2004 Matthias Andree, Eric S. Raymond, Robert M. Funk,
Graham Wilson
Copyright (C) 2005-2006 Sunil Shetye
Copyright (C) 2005-2007 Matthias Andree
Fetchmail comes with ABSOLUTELY NO WARRANTY. This is free software, and
you
are welcome to redistribute it under certain conditions. For details,
please see the file COPYING in the source or documentation directory.

Fallback MDA: (none)
Linux localhost 2.6.20.4 #1 Mon Mar 26 03:39:10 CEST 2007 i686 i686
i386 GNU/Linux
Taking options from command line and /home/guido/.fetchmailrc
Idfile is /home/guido/.fetchids
Fetchmail will show progress dots even in logfiles.
Fetchmail will forward misaddressed multidrop messages to guido.
Fetchmail will direct error mail to the sender.
Options for retrieving from gu...@ma...:
  True name of server is mailserver.doma.in.
  This host will be queried when no host is specified.
  Password = "mypassword".
  Protocol is POP3 (using default port).
  Password authentication will be forced.
  Server nonresponse timeout is 300 seconds (default).
  Default mailbox selected.
  All messages will be retrieved (--all on).
  Fetched messages will not be kept on the server (--keep off).
  Old messages will not be flushed before message retrieval (--flush
off).
  Oversized messages will not be flushed before message retrieval
(--limitflush off).
  Rewrite of server-local addresses is enabled (--norewrite off).
  Carriage-return stripping is disabled (stripcr off).
  Carriage-return forcing is enabled (forcecr on).
  Interpretation of Content-Transfer-Encoding is enabled (pass8bits
off).
  MIME decoding is disabled (mimedecode off).
  Idle after poll is disabled (idle off).
  Nonempty Status lines will be kept (dropstatus off)
  Delivered-To lines will be kept (dropdelivered off)
  Received-message limit is 1 (--fetchlimit 1).
  Fetch message size limit is 100 (--fetchsizelimit 100).
  Do binary search of UIDs during 3 out of 4 polls (--fastuidl 4).
  No SMTP message batch limit (--batchlimit 0).
  No forced expunges (--expunge 0).
  Messages will be SMTP-forwarded to: localhost (default)
  Spam-blocking disabled
  No pre-connection command.
  No post-connection command.
  Single-drop mode: 1 local name recognized.
        guido
  No interface requirement specified.
  No monitor interface specified.
  No plugin command specified.
  No plugout command specified.
  No UIDs saved from this host.
  No poll trace information will be added to the Received header.
.



On localhost I have a mail server (postfix), and nothing is sent to it.
If I stop the mail server (so that on localhost:25 there is no
response), the fetchmail log remains the same, this means that
fetchmail does not even try to contact the local mail server.
If I try to download a different message without the numeric line at
the beginning, postfix is correctly called and the message is forwarded
to the "guido" local mailbox.

I hope I gave you enough information to correct the error, if you need
more please do not esitate asking.

Good bye,
Guido Villa





      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html

Re: [fetchmail-users] fetchmail: message .....:1 was not the expected length (30792 actual != 30347 expected), not flushed

[Otto R. (AP-SGP) <ot...@ap...>]

Matthias Andree wrote:
> Otto Rodusek (AP-SGP) schrieb:
>
>   
>> Sorry for the top reply - diff user groups use diff protocols - I will
>> bottom post to this mailgroup.
>>
>> I will re-verify my logs just to make sure. I have read the follow up
>> email from Matthais and will disable dns lookup on fetchmail retrieval
>> and see if that solves the problem.
>>     
>
> The log you quoted was for your SMTP server - fetchmail's DNS option has
> no influence in this particular area.
>
> You'll look at fetchmail's dns option when it doesn't recognize
> *destination* domains, but that's not "your" culprit.
>
>
>   
Hi Matthais,

Yep - I know not to use the fetchmail dns option - what I meant was to 
disable dns lookup on my smtp whilst doing fetchmail.

I did that and tried it and its now ok working as expected.

Again thanks.

Rgds. otto.

Re: [fetchmail-users] fetchmail: message .....:1 was not the expected length (30792 actual != 30347 expected), not flushed

[Otto R. (AP-SGP) <ot...@ap...>]

>
> Peter Pentchev wrote:
>   
>> On Fri, Apr 13, 2007 at 09:30:34PM +0800, Otto Rodusek (AP-SGP) wrote:
>>   
>>     
>>> Matthias Andree wrote:
>>>     
>>>       
>>>> Otto Rodusek (AP-SGP) schrieb:
>>>>       
>>>>         
>>>>> I'm having some minor problems issues with fetchmail v6.3.5.
>>>>>         
>>>>>           
>>>>   
>>>>       
>>>>         
>>>>> This only happens on junk mails and never on "real" mail.
>>>>>         
>>>>>           
>>>>   
>>>>       
>>>>         
>>>>> Is there any possible solution to this?? (Currently I have to regularly 
>>>>> login to the webmail access on the ISP and manually clean those emails).
>>>>>         
>>>>>           
>>>> Not inside fetchmail.
>>>>   
>>>>       
>>>>         
>>>>> fetchmail: SMTP> MAIL FROM:<all...@cl...> SIZE=30347
>>>>> fetchmail: SMTP< 451 DNS temporary failure (#4.5.1 - chkuser)
>>>>> fetchmail: SMTP error: 451 DNS temporary failure (#4.5.1 - chkuser)
>>>>>         
>>>>>           
>>>> As you see here, your local MTA doesn't accept the sender domain,
>>>> click4solutions..., and temporarily refuses the message, so fetchmail
>>>> tries again at the next poll cycle.
>>>>
>>>> Messages about size mismatches are warnings (most of the time at least)
>>>> and don't make fetchmail abort the delivery voluntarily.
>>>>
>>>> You might try to blacklist that click4sol... domain in your MTA so it
>>>> responds with some code between 500 and 599 inclusively, then fetchmail
>>>> will know it's pointless to retry.
>>>>       
>>>>         
>>> Hi Matthias,
>>>
>>> Thanks for the quick reply. I'm confused as to which failure part is 
>>> causing fetchmail to "not flush" messages on the ISP server. You say its 
>>> because of the "dns" error on my server - however this same "dns" error 
>>> happens on many other messages and these messages still gets flushed 
>>> from the ISP side.(I have analyzed the successful logs - where 
>>> successful means the message is download from ISP and flushed on ISP 
>>> side )( I only give you the log of the failed message ie the message 
>>> that does not get flushed).
>>>     
>>>       
>> (I've rearranged the messages a bit to provide some context; once again,
>> top-posting seems to be a less-than-brilliant idea :)
>>
>> Errr...
>>
>> Are you really saying that in your logs you have seen a case when your
>> mail server gives a 4xx response - a 451 DNS temporary failure or apny
>> other 4xx response - AND fetchmail flushes the message on the ISP side?
>>
>> If you are saying that, please provide logs - that would be a very, very
>> serious bug in fetchmail :)  A 4xx response means that your local mail
>> server DID NOT receive the message, so fetchmail must not remove it from
>> the ISP's mailbox, and it should retry downloading it later.
>>
>> I'm really not sure that is the case.  If you can really find such
>> a situation in your logs - your mailserver giving a 4xx response and
>> fetchmail DELE'ting the message from the ISP side - then you would have
>> found a bug indeed.  Until then, Matthias's explanation seems correct,
>> at least to me.
>>
>> Note that there is a big difference between a 4xx and a 5xx response;
>> a 5xx code means a permanent failure, your mailserver will never accept
>> this message, no matter how many times fetchmail tries again in the
>> future, and in this case fetchmail may indeed flush the message on the
>> ISP side - no sense keeping messages that it will never be able to
>> deliver.
>>
>> G'luck,
>> Peter
>>
>>   
>>     
> Hi,
>
> Sorry for the top reply - diff user groups use diff protocols - I will 
> bottom post to this mailgroup.
>
> I will re-verify my logs just to make sure. I have read the follow up 
> email from Matthais and will disable dns lookup on fetchmail retrieval 
> and see if that solves the problem.
>
> Thanks for all the replies.
>
> Rgds. Otto.
>
> _______________________________________________
> fetchmail-users mailing list
> fet...@li...
> https://lists.berlios.de/mailman/listinfo/fetchmail-users
>
>
>   

Hi Peter,

You were correct - it was not a 4xx error. Soory for this - think I've 
been looking at too many logs!!! I think I've solved my problem by 
disabling dns lookup whilst doing fetchmail.

Thanks for all the replies and help.

Rgds. Otto.

Re: [fetchmail-users] fetchmail: message .....:1 was not the expected length (30792 actual != 30347 expected), not flushed

[Matthias A. <mat...@gm...>]

Otto Rodusek (AP-SGP) schrieb:

> Sorry for the top reply - diff user groups use diff protocols - I will
> bottom post to this mailgroup.
> 
> I will re-verify my logs just to make sure. I have read the follow up
> email from Matthais and will disable dns lookup on fetchmail retrieval
> and see if that solves the problem.

The log you quoted was for your SMTP server - fetchmail's DNS option has
no influence in this particular area.

You'll look at fetchmail's dns option when it doesn't recognize
*destination* domains, but that's not "your" culprit.

Re: [fetchmail-users] fetchmail: message .....:1 was not the expected length (30792 actual != 30347 expected), not flushed

[Otto R. (AP-SGP) <ot...@ap...>]

Peter Pentchev wrote:
> On Fri, Apr 13, 2007 at 09:30:34PM +0800, Otto Rodusek (AP-SGP) wrote:
>   
>> Matthias Andree wrote:
>>     
>>> Otto Rodusek (AP-SGP) schrieb:
>>>       
>>>> I'm having some minor problems issues with fetchmail v6.3.5.
>>>>         
>>>   
>>>       
>>>> This only happens on junk mails and never on "real" mail.
>>>>         
>>>   
>>>       
>>>> Is there any possible solution to this?? (Currently I have to regularly 
>>>> login to the webmail access on the ISP and manually clean those emails).
>>>>         
>>> Not inside fetchmail.
>>>   
>>>       
>>>> fetchmail: SMTP> MAIL FROM:<all...@cl...> SIZE=30347
>>>> fetchmail: SMTP< 451 DNS temporary failure (#4.5.1 - chkuser)
>>>> fetchmail: SMTP error: 451 DNS temporary failure (#4.5.1 - chkuser)
>>>>         
>>> As you see here, your local MTA doesn't accept the sender domain,
>>> click4solutions..., and temporarily refuses the message, so fetchmail
>>> tries again at the next poll cycle.
>>>
>>> Messages about size mismatches are warnings (most of the time at least)
>>> and don't make fetchmail abort the delivery voluntarily.
>>>
>>> You might try to blacklist that click4sol... domain in your MTA so it
>>> responds with some code between 500 and 599 inclusively, then fetchmail
>>> will know it's pointless to retry.
>>>       
>> Hi Matthias,
>>
>> Thanks for the quick reply. I'm confused as to which failure part is 
>> causing fetchmail to "not flush" messages on the ISP server. You say its 
>> because of the "dns" error on my server - however this same "dns" error 
>> happens on many other messages and these messages still gets flushed 
>> from the ISP side.(I have analyzed the successful logs - where 
>> successful means the message is download from ISP and flushed on ISP 
>> side )( I only give you the log of the failed message ie the message 
>> that does not get flushed).
>>     
>
> (I've rearranged the messages a bit to provide some context; once again,
> top-posting seems to be a less-than-brilliant idea :)
>
> Errr...
>
> Are you really saying that in your logs you have seen a case when your
> mail server gives a 4xx response - a 451 DNS temporary failure or apny
> other 4xx response - AND fetchmail flushes the message on the ISP side?
>
> If you are saying that, please provide logs - that would be a very, very
> serious bug in fetchmail :)  A 4xx response means that your local mail
> server DID NOT receive the message, so fetchmail must not remove it from
> the ISP's mailbox, and it should retry downloading it later.
>
> I'm really not sure that is the case.  If you can really find such
> a situation in your logs - your mailserver giving a 4xx response and
> fetchmail DELE'ting the message from the ISP side - then you would have
> found a bug indeed.  Until then, Matthias's explanation seems correct,
> at least to me.
>
> Note that there is a big difference between a 4xx and a 5xx response;
> a 5xx code means a permanent failure, your mailserver will never accept
> this message, no matter how many times fetchmail tries again in the
> future, and in this case fetchmail may indeed flush the message on the
> ISP side - no sense keeping messages that it will never be able to
> deliver.
>
> G'luck,
> Peter
>
>   
Hi,

Sorry for the top reply - diff user groups use diff protocols - I will 
bottom post to this mailgroup.

I will re-verify my logs just to make sure. I have read the follow up 
email from Matthais and will disable dns lookup on fetchmail retrieval 
and see if that solves the problem.

Thanks for all the replies.

Rgds. Otto.

Re: [fetchmail-users] fetchmail: message .....:1 was not the expected length (30792 actual != 30347 expected), not flushed

[Peter P. <ro...@ri...>]

On Fri, Apr 13, 2007 at 09:30:34PM +0800, Otto Rodusek (AP-SGP) wrote:
> Matthias Andree wrote:
> > Otto Rodusek (AP-SGP) schrieb:
> >> I'm having some minor problems issues with fetchmail v6.3.5.
> >   
> >> This only happens on junk mails and never on "real" mail.
> >   
> >> Is there any possible solution to this?? (Currently I have to regularly 
> >> login to the webmail access on the ISP and manually clean those emails).
> >
> > Not inside fetchmail.
> >   
> >> fetchmail: SMTP> MAIL FROM:<all...@cl...> SIZE=30347
> >> fetchmail: SMTP< 451 DNS temporary failure (#4.5.1 - chkuser)
> >> fetchmail: SMTP error: 451 DNS temporary failure (#4.5.1 - chkuser)
> >
> > As you see here, your local MTA doesn't accept the sender domain,
> > click4solutions..., and temporarily refuses the message, so fetchmail
> > tries again at the next poll cycle.
> >
> > Messages about size mismatches are warnings (most of the time at least)
> > and don't make fetchmail abort the delivery voluntarily.
> >
> > You might try to blacklist that click4sol... domain in your MTA so it
> > responds with some code between 500 and 599 inclusively, then fetchmail
> > will know it's pointless to retry.
> 
> Hi Matthias,
> 
> Thanks for the quick reply. I'm confused as to which failure part is 
> causing fetchmail to "not flush" messages on the ISP server. You say its 
> because of the "dns" error on my server - however this same "dns" error 
> happens on many other messages and these messages still gets flushed 
> from the ISP side.(I have analyzed the successful logs - where 
> successful means the message is download from ISP and flushed on ISP 
> side )( I only give you the log of the failed message ie the message 
> that does not get flushed).

(I've rearranged the messages a bit to provide some context; once again,
top-posting seems to be a less-than-brilliant idea :)

Errr...

Are you really saying that in your logs you have seen a case when your
mail server gives a 4xx response - a 451 DNS temporary failure or apny
other 4xx response - AND fetchmail flushes the message on the ISP side?

If you are saying that, please provide logs - that would be a very, very
serious bug in fetchmail :)  A 4xx response means that your local mail
server DID NOT receive the message, so fetchmail must not remove it from
the ISP's mailbox, and it should retry downloading it later.

I'm really not sure that is the case.  If you can really find such
a situation in your logs - your mailserver giving a 4xx response and
fetchmail DELE'ting the message from the ISP side - then you would have
found a bug indeed.  Until then, Matthias's explanation seems correct,
at least to me.

Note that there is a big difference between a 4xx and a 5xx response;
a 5xx code means a permanent failure, your mailserver will never accept
this message, no matter how many times fetchmail tries again in the
future, and in this case fetchmail may indeed flush the message on the
ISP side - no sense keeping messages that it will never be able to
deliver.

G'luck,
Peter

-- 
Peter Pentchev	ro...@ri...    ro...@cn...    ro...@Fr...
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
I am the thought you are now thinking.

Re: [fetchmail-users] fetchmail: message .....:1 was not the expected length (30792 actual != 30347 expected), not flushed

[Matthias A. <mat...@gm...>]

Otto Rodusek (AP-SGP) schrieb:

> Thanks for the quick reply. I'm confused as to which failure part is
> causing fetchmail to "not flush" messages on the ISP server. You say its
> because of the "dns" error on my server - however this same "dns" error
> happens on many other messages and these messages still gets flushed
> from the ISP side.(I have analyzed the successful logs - where
> successful means the message is download from ISP and flushed on ISP
> side )( I only give you the log of the failed message ie the message
> that does not get flushed). It only doesn't get flushed when I have this
> messge:
> 
> ........fetchmail: message ro...@am...@mail.sg.gs:1 was not the
> expected length (30792 actual != 30347 expected) not flushed.

I understand that this line is very misleading (and updating to 6.3.8
won't fix that part).

However it is really the 451 reply that fetchmail got back from the SMTP
server after the MAIL FROM:<...> command that causes the "not flushed".

If it's a 551 reply, then fetchmail has received a definite "this domain
doesn't exist" and can decide to drop the message.

400 series codes in mail protocols such as SMTP and LMTP mean "temporary
error, retrying later may succeed", 500 series code mean "retrying is
pointless, don't bother".

HTH
MA

Re: [fetchmail-users] Fetchmail Socket error on asatellite connection

[Rob M. <rob...@gm...>]

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

Re: [fetchmail-users] fetchmail: message .....:1 was not the expected length (30792 actual != 30347 expected), not flushed

[Otto R. (AP-SGP) <ot...@ap...>]

Hi Matthias,

Thanks for the quick reply. I'm confused as to which failure part is 
causing fetchmail to "not flush" messages on the ISP server. You say its 
because of the "dns" error on my server - however this same "dns" error 
happens on many other messages and these messages still gets flushed 
from the ISP side.(I have analyzed the successful logs - where 
successful means the message is download from ISP and flushed on ISP 
side )( I only give you the log of the failed message ie the message 
that does not get flushed). It only doesn't get flushed when I have this 
messge:

........fetchmail: message ro...@am...@mail.sg.gs:1 was not the 
expected length (30792 actual != 30347 expected) not flushed.

What I'm saying is there are many other "spam/junk" mails where the 
address does not dns resolve (same as per my log) , yet it still gets 
downloaded (fetchmail'ed) to my server from my isp and gets flushed from 
the ISP server. It is only occasionally where the message has the 
"length" error and does not get flushed from the ISP server.

I'm not sure if I have explained it properly - and hopefully this sort 
of thing has been seen before and resolved.

Again thanks.

Rgds. Otto.

 
Matthias Andree wrote:
> Otto Rodusek (AP-SGP) schrieb:
>
>   
>> I'm having some minor problems issues with fetchmail v6.3.5.
>>     
>
>   
>> This only happens on junk mails and never on "real" mail.
>>     
>
>   
>> Is there any possible solution to this?? (Currently I have to regularly 
>> login to the webmail access on the ISP and manually clean those emails).
>>     
>
> Not inside fetchmail.
>
>   
>> fetchmail: SMTP> MAIL FROM:<all...@cl...> SIZE=30347
>> fetchmail: SMTP< 451 DNS temporary failure (#4.5.1 - chkuser)
>> fetchmail: SMTP error: 451 DNS temporary failure (#4.5.1 - chkuser)
>>     
>
> As you see here, your local MTA doesn't accept the sender domain,
> click4solutions..., and temporarily refuses the message, so fetchmail
> tries again at the next poll cycle.
>
> Messages about size mismatches are warnings (most of the time at least)
> and don't make fetchmail abort the delivery voluntarily.
>
> You might try to blacklist that click4sol... domain in your MTA so it
> responds with some code between 500 and 599 inclusively, then fetchmail
> will know it's pointless to retry.
>
> HTH
> MA
>
>
>   

Re: [fetchmail-users] fetchmail: message .....:1 was not the expected length (30792 actual != 30347 expected), not flushed

[Matthias A. <mat...@gm...>]

Otto Rodusek (AP-SGP) schrieb:

> I'm having some minor problems issues with fetchmail v6.3.5.

> This only happens on junk mails and never on "real" mail.

> Is there any possible solution to this?? (Currently I have to regularly 
> login to the webmail access on the ISP and manually clean those emails).

Not inside fetchmail.

> fetchmail: SMTP> MAIL FROM:<all...@cl...> SIZE=30347
> fetchmail: SMTP< 451 DNS temporary failure (#4.5.1 - chkuser)
> fetchmail: SMTP error: 451 DNS temporary failure (#4.5.1 - chkuser)

As you see here, your local MTA doesn't accept the sender domain,
click4solutions..., and temporarily refuses the message, so fetchmail
tries again at the next poll cycle.

Messages about size mismatches are warnings (most of the time at least)
and don't make fetchmail abort the delivery voluntarily.

You might try to blacklist that click4sol... domain in your MTA so it
responds with some code between 500 and 599 inclusively, then fetchmail
will know it's pointless to retry.

HTH
MA

[fetchmail-users] fetchmail: message .....:1 was not the expected length (30792 actual != 30347 expected), not flushed

[Otto R. (AP-SGP) <ot...@ap...>]

HI,

I'm having some minor problems issues with fetchmail v6.3.5.

(My system is a SUSE 10.2 server, I connect to my ISP every 10 minutes 
and use fetchmail to download all mail from the ISP server. The ISP 
server is FREEBSD using QMAIL/SPAMASSASSIN/CLAMAV. I use a single 
"catchall" account on the ISP side, use fetchmail to retrieve to my 
server and then distribute to correct users.

This only happens on junk mails and never on "real" mail. Is there any 
parameter in fetchmail (that I'm not aware of or undocumented) that will 
ignore the size error, download the mail to my server and delete the 
message from the ISP after download?? I have read the FAQ regarding this 
error and QMAIL - but unfortunately changing ISP is not an option and 
the ISP is not about to make major changes just for me.

Is there any possible solution to this?? (Currently I have to regularly 
login to the webmail access on the ISP and manually clean those emails).

Any useful suggestions would be appreciated.

Much Thanks.

Regards. Otto Rodusek.

Contents of fetchmailrc:
================
poll mail.sg.gs     protocol pop3 username ro...@am... password 
mypassword to ro...@am...

Log of fetchmail -vvv
===============
# fetchmail -vvv -K -F -f /menu/fetchmailrc.amb.com.sg

fetchmail: 6.3.5 querying mail.sg.gs (protocol POP3) at Fri Apr 13 
20:12:52 2007: poll started
Trying to connect to 203.175.172.6/110...connected.
fetchmail: POP3< +OK <470...@sg...>
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR authorization first
fetchmail: authorization first
fetchmail: Repoll immediately on ro...@am...@mail.sg.gs
Trying to connect to 203.175.172.6/110...connected.
fetchmail: POP3< +OK <470...@sg...>
fetchmail: POP3> USER ro...@am...
fetchmail: POP3< +OK
fetchmail: POP3> PASS *
fetchmail: POP3< +OK
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 1 30347
fetchmail: POP3> LAST
fetchmail: POP3< +OK 0
1 message for ro...@am... at mail.sg.gs (30347 octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 30347
fetchmail: POP3> TOP 1 99999999
fetchmail: POP3< +OK
reading message ro...@am...@mail.sg.gs:1 of 1 (30347 octets)
About to rewrite Return-Path: <all...@cl...>
Rewritten version is Return-Path: <all...@cl...>

About to rewrite From: "Joya Webb" <all...@cl...>
Rewritten version is From: "Joya Webb" <all...@cl...>

About to rewrite To: "Linda Freeman" <qc...@am...>
Rewritten version is To: "Linda Freeman" <qc...@am...>

Trying to connect to 127.0.0.1/25...connected.
fetchmail: SMTP< 220 amb.com.sg ESMTP
fetchmail: SMTP> EHLO amb.com.sg
fetchmail: SMTP< 250-amb.com.sg
fetchmail: SMTP< 250-STARTTLS
fetchmail: SMTP< 250-PIPELINING
fetchmail: SMTP< 250-8BITMIME
fetchmail: SMTP< 250-SIZE 0
fetchmail: SMTP< 250 AUTH LOGIN PLAIN CRAM-MD5
fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL FROM:<all...@cl...> SIZE=30347
fetchmail: SMTP< 451 DNS temporary failure (#4.5.1 - chkuser)
fetchmail: SMTP error: 451 DNS temporary failure (#4.5.1 - chkuser)
fetchmail: SMTP> RSET
fetchmail: SMTP< 250 flushed
............................fetchmail: message 
ro...@am...@mail.sg.gs:1 was not the expected length (30792 
actual != 30347 expected)
 not flushed
fetchmail: POP3> QUIT
fetchmail: POP3< +OK
fetchmail: SMTP> QUIT
fetchmail: SMTP< 221 amb.com.sg
fetchmail: 6.3.5 querying mail.sg.gs (protocol POP3) at Fri Apr 13 
20:12:55 2007: poll completed
fetchmail: not swapping UID lists, no UIDs seen this query
fetchmail: Deleting fetchids file.
fetchmail: normal termination, status 0
fetchmail: Deleting fetchids file.
===============================================================================================

Re: [fetchmail-users] Fetchmail Socket error on asatellite connection

[Matthias A. <mat...@gm...>]

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

Re: [fetchmail-users] Fetchmail Socket error on asatellite connection

[Rob M. <rob...@gm...>]

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

Re: [fetchmail-users] Fetchmail Socket error on asatellite connection

[Steve S. <ker...@si...>]

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