Menu
▾
▴
fetchmail-users
|
From: Ben J. <be...@po...> - 2007-04-12 14:13:00
|
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. When I connect to the pop3 server some mails are downloaded but with some it is stopping. Not sure what is causing it. Trying to connect to 127.0.0.1/25...connected. fetchmail: SMTP< 220 xxx fetchmail: SMTP> EHLO xxx fetchmail: SMTP< 250-p pleased to meet you fetchmail: SMTP< 250-ENHANCEDSTATUSCODES fetchmail: SMTP< 250-PIPELINING fetchmail: SMTP< 250-8BITMIME fetchmail: SMTP< 250-SIZE fetchmail: SMTP< 250-DSN fetchmail: SMTP< 250-DELIVERBY fetchmail: SMTP< 250 HELP fetchmail: forwarding to localhost fetchmail: SMTP> MAIL FROM: BODY=8BITMIME SIZE=100083 fetchmail: SMTP< 250 2.1.0 ... Sender ok fetchmail: SMTP> RCPT TO:< fetchmail: SMTP< 250 2.1.5 <>... Recipient ok fetchmail: SMTP> DATA fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself #****************************.*fetchmail: socket error while fetching from fetchmail: 6.3.8 querying (protocol POP3) at Mon Apr 9 07:57:48 2007: poll completed fetchmail: Query status=2 (SOCKET) fetchmail: Deleting fetchids file. fetchmail: normal termination, status 2 fetchmail: Deleting fetchids file. I tried everything also setting timeouts and other stuff but it keeps crashing. Please help! I also tried other pop3 servers and accounts and I just keep getting on random messages reading message 12 of 60 (3073 octets).fetchmail: socket error while fetching from fetchmail: Query status=2 (SOCKET) = |
|
From: Matthias A. <mat...@gm...> - 2007-04-12 14:24:10
|
Ben Jsh schrieb: > 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. So the satellite link is the first suspect, no? :-) > When I connect to the pop3 server some mails are downloaded but with some it is stopping. > Not sure what is causing it. How does the satellite connection differ from the ADSL? ... > I tried everything also setting timeouts and other stuff but it keeps crashing. > Please help! > I also tried other pop3 servers and accounts and I just keep getting on random messages You quoted the SMTP dialog, but your problem is apparently POP3. It shows the error, but not the preceding events. Perhaps there's something obvious in the POP3 logging, but if not, sorry - check http://www.fetchmail.info/fetchmail-FAQ.html#G3 for information lacking from your report (beyond the differences sat/dsl above) and run fetchmail -vvv to see if you get POP3 logging. I can't promise there's anything fetchmail could do about the issue though. HTH MA |
|
From: Rob M. <rob...@gm...> - 2007-04-12 14:28:00
|
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
|
|
From: Otto R. (AP-SGP) <ot...@ap...> - 2007-04-13 14:44:39
|
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. =============================================================================================== |
|
From: Otto R. (AP-SGP) <ot...@ap...> - 2007-04-13 15:53:56
|
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. |
|
From: Otto R. (AP-SGP) <ot...@ap...> - 2007-04-13 15:59:52
|
> > 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. |
|
From: Matthias A. <mat...@gm...> - 2007-04-13 15:09:36
|
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 |
|
From: Otto R. (AP-SGP) <ot...@ap...> - 2007-04-13 15:32:36
|
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 > > > |
|
From: Matthias A. <mat...@gm...> - 2007-04-13 15:41:13
|
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 |
|
From: Peter P. <ro...@ri...> - 2007-04-13 15:42:56
|
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. |
|
From: Matthias A. <mat...@gm...> - 2007-04-13 15:58:48
|
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. |
|
From: Otto R. (AP-SGP) <ot...@ap...> - 2007-04-13 16:02:50
|
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. |
×
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