You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(16) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(2) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
(8) |
Aug
(21) |
Sep
(17) |
Oct
(35) |
Nov
(39) |
Dec
(55) |
2006 |
Jan
(70) |
Feb
(11) |
Mar
(55) |
Apr
(27) |
May
(73) |
Jun
(47) |
Jul
(63) |
Aug
(27) |
Sep
(52) |
Oct
(39) |
Nov
(87) |
Dec
(15) |
2007 |
Jan
(23) |
Feb
(46) |
Mar
(108) |
Apr
(63) |
May
(54) |
Jun
(34) |
Jul
(29) |
Aug
(103) |
Sep
(46) |
Oct
(69) |
Nov
(29) |
Dec
(17) |
2008 |
Jan
(45) |
Feb
(32) |
Mar
(25) |
Apr
(17) |
May
(39) |
Jun
(20) |
Jul
(64) |
Aug
(31) |
Sep
(38) |
Oct
(20) |
Nov
(42) |
Dec
(50) |
2009 |
Jan
(10) |
Feb
(38) |
Mar
(3) |
Apr
(29) |
May
(41) |
Jun
(31) |
Jul
(21) |
Aug
(53) |
Sep
(49) |
Oct
(26) |
Nov
(28) |
Dec
(15) |
2010 |
Jan
(83) |
Feb
(38) |
Mar
(33) |
Apr
(44) |
May
(9) |
Jun
(16) |
Jul
(35) |
Aug
(38) |
Sep
(11) |
Oct
(35) |
Nov
(68) |
Dec
(19) |
2011 |
Jan
(16) |
Feb
(69) |
Mar
(42) |
Apr
(54) |
May
(56) |
Jun
(29) |
Jul
|
Aug
(65) |
Sep
(3) |
Oct
(39) |
Nov
(33) |
Dec
(4) |
2012 |
Jan
(31) |
Feb
(21) |
Mar
(26) |
Apr
(13) |
May
(38) |
Jun
(39) |
Jul
(14) |
Aug
(31) |
Sep
(8) |
Oct
(32) |
Nov
(12) |
Dec
(16) |
2013 |
Jan
(40) |
Feb
(22) |
Mar
(21) |
Apr
(15) |
May
(13) |
Jun
(9) |
Jul
(34) |
Aug
(10) |
Sep
(10) |
Oct
|
Nov
(7) |
Dec
(1) |
2014 |
Jan
(25) |
Feb
(9) |
Mar
(8) |
Apr
(12) |
May
(7) |
Jun
|
Jul
(7) |
Aug
(4) |
Sep
(27) |
Oct
(25) |
Nov
(18) |
Dec
(3) |
2015 |
Jan
(18) |
Feb
(13) |
Mar
(4) |
Apr
(19) |
May
(11) |
Jun
|
Jul
(1) |
Aug
(7) |
Sep
(6) |
Oct
(4) |
Nov
(19) |
Dec
(6) |
2016 |
Jan
|
Feb
(8) |
Mar
(14) |
Apr
|
May
(11) |
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(10) |
Oct
|
Nov
(11) |
Dec
(17) |
2017 |
Jan
(17) |
Feb
(35) |
Mar
|
Apr
(4) |
May
(8) |
Jun
(2) |
Jul
(16) |
Aug
|
Sep
(5) |
Oct
(11) |
Nov
(15) |
Dec
(10) |
2018 |
Jan
|
Feb
(3) |
Mar
|
Apr
(3) |
May
(2) |
Jun
(8) |
Jul
|
Aug
(10) |
Sep
(17) |
Oct
(15) |
Nov
(12) |
Dec
(10) |
2019 |
Jan
(4) |
Feb
(14) |
Mar
(33) |
Apr
(17) |
May
(7) |
Jun
(6) |
Jul
(2) |
Aug
(4) |
Sep
(22) |
Oct
(13) |
Nov
|
Dec
|
2020 |
Jan
(36) |
Feb
(19) |
Mar
(31) |
Apr
(2) |
May
(22) |
Jun
(7) |
Jul
(25) |
Aug
(9) |
Sep
(17) |
Oct
(52) |
Nov
(13) |
Dec
(9) |
2021 |
Jan
(23) |
Feb
(13) |
Mar
(9) |
Apr
(15) |
May
(3) |
Jun
(7) |
Jul
(4) |
Aug
(23) |
Sep
(3) |
Oct
(8) |
Nov
(28) |
Dec
(9) |
2022 |
Jan
(38) |
Feb
(2) |
Mar
(56) |
Apr
(24) |
May
(29) |
Jun
(22) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(2) |
Dec
|
2023 |
Jan
(6) |
Feb
(1) |
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
(21) |
Aug
(5) |
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
2024 |
Jan
(15) |
Feb
(4) |
Mar
|
Apr
(4) |
May
(11) |
Jun
(9) |
Jul
(1) |
Aug
|
Sep
(9) |
Oct
(9) |
Nov
(1) |
Dec
(1) |
2025 |
Jan
(7) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
(10) |
Jul
|
Aug
(1) |
Sep
(12) |
Oct
|
Nov
|
Dec
|
From: Graham W. <bo...@de...> - 2004-07-24 08:41:44
|
On Fri, Jul 23, 2004 at 01:13:24PM +0300, Gary Sims wrote: > Hi, Hello. > Clearly the address which fetchmail is submitting to the SMTP server in the > MAIL FROM command is broken. Of course the question is what was the origial > like. The problem is that I don't know as the message has now been deleted. Without the original message, it will be kind of difficult to determine where the problem is. Is the original message at fault, or is fetchmail mangling something somehow? > Before this I removed the antispam option from my fetchmailrc file. However > the email is still being deleted even though it was not delivered or > non-delivered. Is that behaviour correct? I don't think so. It seems like the SMTP server gave a 501 response, in which case I would expect fetchmail to bounce the message. Maybe it tried? -- gram |
From: Andreas <an...@co...> - 2004-07-24 01:36:43
|
On Fri, Jul 23, 2004 at 09:20:05AM +0000, Rob MacGregor wrote: > >From: Andreas <an...@co...> > > > >I was wondering if someone is being able to use IDLE support. I remember > >seeing it working once, but it isn't anymore. > > Is IDLE configured in your .fetchmailrc? Sure: set postmaster "andreas" set bouncemail set properties "" set daemon 120 poll pop.server with proto IMAP auth password user 'andreas' there is 'andreas' here options idle ssl fetchall warnings 3600 mda '/usr/bin/procmail' Or is there some syntax error? |
From: Rob <rob...@ho...> - 2004-07-23 22:40:39
|
> -----Original Message----- > From: fet...@be... > [mailto:fet...@be...] On Behalf Of James Moe > > Wow! This must be a baffler! No, more a case that fetchmail isn't designed to handle such a badly behaved SMTP listener. Your choices are: 1) Submit a patch to fetchmail to cope with non RFC compliant SMTP listeners 2) Use something other than ASSP that's not so badly broken PLEASE - keep list traffic on the list. Email sent directly to me may be ignored utterly. -- Rob | What part of "no" was it you didn't understand? |
From: James M. <ji...@so...> - 2004-07-23 19:47:54
|
James Moe wrote: > fetchmail release 6.2.4+SSL+NLS > [...] > What is more worrisome is that just before the abort, fetchmail says > the message was flushed, implying a lost message. > > Is there some way to have fetchmail re-connect with assp rather than > abort? > > fetchmail: terminated with signal 13 > Wow! This must be a baffler! -- jimoe at sohnen-moe dot com |
From: Gary S. <ga...@ga...> - 2004-07-23 12:13:58
|
Hi, This is a problem which is on going on the fetchmail-friends list at ccil.org. I thought I would post it here as well in case people have migrated. Any help will would mich appreciated. +++++++++++++ I have a dial up connection and I am using latest fetchmail (6.2.5) to get the mail from a POP3 mailbox and I am using postfix (V1.1.11) as the local SMTP server and all this is running on RedHat 9.0. In general my email is getting through but I do get the following errors in my mail logs. Jul 18 13:25:51 exodus postfix/smtpd[25020]: warning: Illegal address syntax from unknown[127.0.0.1] in MAIL command: <column-greekthoughts-return-23-gary=gar...@li...ceived: (qmail 21055 invoked from network); 18 Jul 2004 07:09:56 -0000> It is about a message which I am expecting... I am guessing the error is occuring when fetchmail talks to postfix to submit the message for local delivery. Looking at the "illegal address" it is clear that the Received line is mixed in with the address. I have now traced one of my problem messages with fetchmail -v -v and this is what I get fetchmail: POP3> LIST 7 fetchmail: POP3< +OK 7 8568 fetchmail: POP3> TOP 7 99999999 fetchmail: POP3< +OK headers follow. reading message gar...@ma...:7 of 8 (8568 octets) About to rewrite Return-Path: <c615952fff0eb8febd27fbc7b1dd4792bdeb77a3023419e0f4063f69cReceived: (qmail 22262 invoked from network); 23 Jul 2004 04:01:03 -0000 Rewritten version is Return-Path: <c615952fff0eb8febd27fbc7b1dd4792bdeb77a3023419e0f4063f69cReceived: (qmail 22262 invoked from network); 23 Jul 2004 04:01:03 -0000 About to rewrite Reply-To: c61...@eb... Rewritten version is Reply-To: c61...@eb... About to rewrite From: "BBC daily email" <dai...@bb...> Rewritten version is From: "BBC daily email" <dai...@bb...> About to rewrite To: ga...@ga... Rewritten version is To: ga...@ga... fetchmail: forwarding to localhost fetchmail: SMTP> MAIL FROM:<c615952fff0eb8febd27fbc7b1dd4792bdeb77a3023419e0f4063f69cReceived: (qmail 22262 invoked from network); 23 Jul 2004 04:01:03 -0...@ma...> BODY=8BITMIME SIZE=8568 fetchmail: SMTP< 501 Bad address syntax fetchmail: SMTP error: 501 Bad address syntax fetchmail: SMTP< 220 exodus.aca-vulcan.ro ESMTP Postfix fetchmail: SMTP> HELO localhost fetchmail: SMTP< 250 exodus.aca-vulcan.ro fetchmail: SMTP> MAIL FROM:<FETCHMAIL-DAEMON@exodus> fetchmail: SMTP< 250 Ok fetchmail: SMTP> RCPT TO:<c615952fff0eb8febd27fbc7b1dd4792bdeb77a3023419e0f4063f69cReceived: (qmail 22262 invoked from network); 23 Jul 2004 04:01:03 -0000> fetchmail: SMTP< 501 Bad address syntax fetchmail: SMTP> QUIT fetchmail: SMTP< 221 Bye fetchmail: SMTP> RSET fetchmail: SMTP< 250 Ok ...... flushed fetchmail: POP3> DELE 7 fetchmail: POP3< +OK Deleted. Clearly the address which fetchmail is submitting to the SMTP server in the MAIL FROM command is broken. Of course the question is what was the origial like. The problem is that I don't know as the message has now been deleted. Before this I removed the antispam option from my fetchmailrc file. However the email is still being deleted even though it was not delivered or non-delivered. Is that behaviour correct? Any more clues? Thanks, Gary -- Gary Sims (ga...@ga...) Vulcan, Brasov, Romania |
From: Rob M. <rob...@ho...> - 2004-07-23 11:20:08
|
>From: Andreas <an...@co...> > >I was wondering if someone is being able to use IDLE support. I remember >seeing it working once, but it isn't anymore. Is IDLE configured in your .fetchmailrc? Certainly I've had it work, when configured, in 6.2.5. Please DO NOT send me ANY email directly unless it's a privacy issue. Reply-to mangled to assist those who don't read the above. -- Rob | What part of "no" was it you didn't understand? |
From: Andreas <an...@co...> - 2004-07-22 19:05:25
|
I was wondering if someone is being able to use IDLE support. I remember seeing it working once, but it isn't anymore. A trace: fetchmail: IMAP< * OK [CAPABILITY IMAP4 IMAP4REV1 STARTTLS LOGIN-REFERRALS AUTH=PLAIN AUTH=LOGIN] pop.domain IMAP4rev1 2000.287cl at Thu, 22 Jul 2004 14:55:53 -0300 (EST) fetchmail: IMAP> A0001 CAPABILITY fetchmail: IMAP< * CAPABILITY IMAP4 IMAP4REV1 STARTTLS NAMESPACE IDLE MAILBOX-REFERRALS SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND LOGIN-REFERRALS AUTH=PLAIN AUTH=LOGIN fetchmail: IMAP< A0001 OK CAPABILITY completed fetchmail: will idle after poll fetchmail: IMAP> A0002 LOGIN "andreas" * fetchmail: IMAP< * CAPABILITY IMAP4 IMAP4REV1 STARTTLS NAMESPACE IDLE MAILBOX-REFERRALS SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND fetchmail: IMAP< A0002 OK LOGIN completed fetchmail: IMAP> A0003 SELECT "INBOX" (...) fetchmail: IMAP< A0011 OK Expunged 1 messages fetchmail: IMAP> A0012 LOGOUT fetchmail: IMAP< * BYE imap.domain IMAP4rev1 server terminating connection fetchmail: IMAP< A0012 OK LOGOUT completed fetchmail: 6.2.5 querying pop.domain (protocol IMAP) at Qui 22 Jul 2004 14:02:46 BRT: poll completed It hastn't issued any IDLE command, even though it detected IDLE support... The server is uw-imap and fetchmail is version 6.2.5. If it makes any difference, I'm running this over imaps (the trace above is from fetchmail -N -v). |
From: James M. <ji...@so...> - 2004-07-21 19:21:24
|
List members: One or more of your computers is infected with viruses or trojans. Sterilize your infested computers. -- jimoe at sohnen-moe dot com |
From: James M. <ji...@so...> - 2004-07-21 19:14:20
|
Hello, fetchmail release 6.2.4+SSL+NLS I have fetchmail forward mail to a bayseian mail classifier, assp (anti-spam smtp proxy). One of assp's features is to block messages with executable attachments. If one is found, it rejects the message and returns an status code of 500 to the sender (fetchmail). Apparently assp closes the connection after returning the error message since signal 13 (broken pipe) is raised in fetchmail. At which time fetchmail terminates. It looks like this happens on the *next* connection attempt with assp. What is more worrisome is that just before the abort, fetchmail says the message was flushed, implying a lost message. Is there some way to have fetchmail re-connect with assp rather than abort? fetchmail: reading message moe...@lo...:2 of 2 (42695 octets) fetchmail: SMTP error: 500 Executable attachments are not allowed -- Compress before mailing. fetchmail: SMTP listener refused delivery fetchmail: flushed fetchmail: 1 message for cherie at localhost (5458 octets). fetchmail: reading message ch...@lo...:1 of 1 (5458 octets) fetchmail: flushed fetchmail: terminated with signal 13 -- jimoe at sohnen-moe dot com |
From: Rob F. <rf...@fu...> - 2004-07-21 19:13:45
|
Laurence wrote: > I transferred to berlios from the ccil list a couple of days ago to get > away from the "esr virus-removed" spam and already I've had a Nigerian > spam and one from some Chinese dude via the list. Is there any spam > checking on this list? Maybe sign ups should be approved by a > moderator? Sorry about that. I just changed it to members-only posting, which should help a lot. Since joining the list requires confirmation, I doubt spammers will bother. If they do, I'll have to consider moderating subscriptions. > Maybe I should transfer back to ccil?! Hey, maybe you can talk them into giving you admin access. :-) -- ==============================| "A microscope locked in on one point Rob Funk <rf...@fu...> |Never sees what kind of room that it's in" http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind" |
From: Laurence <lj...@hb...> - 2004-07-21 18:10:32
|
I transferred to berlios from the ccil list a couple of days ago to get away from the "esr virus-removed" spam and already I've had a Nigerian spam and one from some Chinese dude via the list. Is there any spam checking on this list? Maybe sign ups should be approved by a moderator? Looking back through the archives on berlios: 4 messages are spam 1 message is real Maybe I should transfer back to ccil?! Laurence |
From: John F. <jo...@mi...> - 2004-06-21 18:32:05
|
I use fetchmail 6.2.3 passing mail onto postfix via smtp. Occasionally, I get a malformed email in my isp mailbox with an envelope from address like this peter@61.172.247.54. That is unacceptable to postfix which gives a 501 response straight after MAIL FROM This is part of the SMTP session: In: MAIL FROM:<peter@61.172.247.54> SIZE=240722 Out: 501 Bad address syntax In: RSET Out: 250 Ok However the mail stays on the pop server and mail just piles up there until I enter and cancel it manually. Once I cancel that mail, everything proceeds ok. I'm not interested in the contents of the message (it originates from a worm) but I don't like the need for manual intervention to get things unblocked. This is what fetchmail logs Jun 21 18:18:47 turate fetchmail[1145]: 1 message for isp...@ng... at pop.ngi.it (240722 octets). Jun 21 18:18:47 turate fetchmail[1145]: reading message isp...@ng...@pop.ngi.it:1 of 1 (240722 octets) Jun 21 18:18:48 turate fetchmail[1145]: flushed Jun 21 18:18:48 turate fetchmail[1145]: client/server protocol error while fetching from pop.ngi.it Jun 21 18:18:48 turate fetchmail[1145]: Query status=4 (PROTOCOL) Jun 21 18:18:56 turate fetchmail[1145]: sleeping at Mon Jun 21 18:18:56 2004 Here's fetchmailrc set daemon 300 set postmaster fet...@mi... set no bouncemail set no spambounce set syslog poll "pop.ngi.it" protocol pop3 interval 1 no envelope username "isp...@mu..." password "xxxxxxx" is loc...@mi... here fetchall smtphost mail.michaweb.net antispam 501 Any ideas while fetchmail cannot delete the message? Thanks, John |