You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(73) |
Jul
(22) |
Aug
(42) |
Sep
(11) |
Oct
(23) |
Nov
(40) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
|
Mar
(17) |
Apr
(26) |
May
(6) |
Jun
(21) |
Jul
(133) |
Aug
(25) |
Sep
(40) |
Oct
(12) |
Nov
(71) |
Dec
(57) |
2006 |
Jan
(23) |
Feb
(22) |
Mar
(43) |
Apr
(27) |
May
(13) |
Jun
(7) |
Jul
(3) |
Aug
(20) |
Sep
(16) |
Oct
(17) |
Nov
(31) |
Dec
(10) |
2007 |
Jan
(12) |
Feb
(17) |
Mar
(26) |
Apr
(13) |
May
(4) |
Jun
(1) |
Jul
(1) |
Aug
(21) |
Sep
(3) |
Oct
(8) |
Nov
(8) |
Dec
(5) |
2008 |
Jan
(5) |
Feb
(1) |
Mar
(3) |
Apr
(10) |
May
(3) |
Jun
(11) |
Jul
(5) |
Aug
(1) |
Sep
(6) |
Oct
|
Nov
(10) |
Dec
(2) |
2009 |
Jan
(17) |
Feb
(2) |
Mar
(1) |
Apr
(9) |
May
(23) |
Jun
(22) |
Jul
(32) |
Aug
(30) |
Sep
(11) |
Oct
(24) |
Nov
(4) |
Dec
|
2010 |
Jan
(12) |
Feb
(56) |
Mar
(32) |
Apr
(41) |
May
(36) |
Jun
(14) |
Jul
(7) |
Aug
(10) |
Sep
(13) |
Oct
(16) |
Nov
|
Dec
(14) |
2011 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
(16) |
May
(36) |
Jun
(2) |
Jul
|
Aug
(9) |
Sep
(2) |
Oct
(1) |
Nov
(8) |
Dec
(3) |
2012 |
Jan
(1) |
Feb
(5) |
Mar
(1) |
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
(7) |
Sep
(9) |
Oct
(2) |
Nov
(8) |
Dec
(9) |
2013 |
Jan
(11) |
Feb
(6) |
Mar
(14) |
Apr
(10) |
May
|
Jun
(12) |
Jul
(2) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(7) |
Dec
(4) |
2014 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
(7) |
Jul
|
Aug
(8) |
Sep
(8) |
Oct
|
Nov
|
Dec
(2) |
2017 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(6) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
(2) |
Feb
(3) |
Mar
(5) |
Apr
(2) |
May
(3) |
Jun
(3) |
Jul
(3) |
Aug
(2) |
Sep
(3) |
Oct
(4) |
Nov
(3) |
Dec
|
2021 |
Jan
(5) |
Feb
(2) |
Mar
(3) |
Apr
(3) |
May
|
Jun
|
Jul
(2) |
Aug
(14) |
Sep
(3) |
Oct
(4) |
Nov
(4) |
Dec
(3) |
2022 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
(3) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
2023 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
From: Matthias A. <ma...@dt...> - 2004-09-13 12:24:18
|
Rob Funk <rf...@fu...> writes: > I just tried to update my local copy of the fetchmail repository, and got > this error: > > svn: PROPFIND request failed on '/svn/fetchmail/trunk' > svn: PROPFIND of '/svn/fetchmail/trunk': SSL negotiation failed: SSL error: > sslv3 alert bad certificate (https://decoy.wox.org) > > Did I miss a change? Yes, I believe so. I have no problem accessing the repo. Graham had asked for a new key and CSR to be generated and should have sent you a new signed certificate in response (in private mail), which needs to be installed. The old key and certificate have expired and are invalid. -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred) |
From: Brian C. <B.C...@po...> - 2004-09-13 11:20:25
|
On Sun, Sep 12, 2004 at 12:27:10PM -0400, Rob Funk wrote: > I just tried to update my local copy of the fetchmail repository, and got > this error: > > svn: PROPFIND request failed on '/svn/fetchmail/trunk' > svn: PROPFIND of '/svn/fetchmail/trunk': SSL negotiation failed: SSL error: > sslv3 alert bad certificate (https://decoy.wox.org) > > Did I miss a change? $ openssl s_client -connect decoy.wox.org:443 CONNECTED(00000003) depth=1 /C=US/ST=Texas/L=Dallas/O=decoy.wox.org/CN=Certificate authority/emailAddress=ca...@de... verify error:num=19:self signed certificate in certificate chain verify return:0 15428:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_pkt.c:1052:SSL alert number 40 15428:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_lib.c:226: $ So this server, whatever it is, is badly broken. (openssl s_client is normally quite happy to connect to sites with self-signed certificates) Regards, Brian. |
From: Rob F. <rf...@fu...> - 2004-09-12 18:27:18
|
I just tried to update my local copy of the fetchmail repository, and got this error: svn: PROPFIND request failed on '/svn/fetchmail/trunk' svn: PROPFIND of '/svn/fetchmail/trunk': SSL negotiation failed: SSL error: sslv3 alert bad certificate (https://decoy.wox.org) Did I miss a change? -- ==============================| "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: Matthias A. <ma...@dt...> - 2004-09-10 13:35:56
|
Fabrice Bellet <fa...@be...> writes: > I proposed in June on fetchmail-friends a patch that solves a bug when > using fetchmail with a dovecot imap server, that doesn't update the > EXISTS and RECENT counters after an EXPUNGE command. Thanks for re-sending this. To fill in, the original audit trail is at http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113492 which led to a fix in Dovecot, but there is a fix still pending for fetchmail, which is what Fabrice is asking about. I've rediffed his patch, see below. > http://lists.ccil.org/pipermail/fetchmail-friends/2004-June/008840.html > > Would it be possible to review this patch, and integrate it in the next > release ? I've reproduced the problem with FreeBSD 4.10's dovecot package, can confirm that the patch fixes the problem and am committing it. The fix will be in 6.2.6. -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred) |
From: Fabrice B. <fa...@be...> - 2004-09-09 23:10:15
|
Hello, I proposed in June on fetchmail-friends a patch that solves a bug when using fetchmail with a dovecot imap server, that doesn't update the EXISTS and RECENT counters after an EXPUNGE command. http://lists.ccil.org/pipermail/fetchmail-friends/2004-June/008840.html Would it be possible to review this patch, and integrate it in the next release ? Best wishes, -- fabrice |
From: Rob F. <rf...@fu...> - 2004-09-02 02:22:55
|
Matthias Andree wrote: > <ext> means that ESR is getting the cs and pt_BR translations directly > from the maintainers, not via the translation project, so we should > probably Cc: these maintainers when sending the .pot file and making > them aware of the new location of the site and maintainer and > everything. Sounds like we should start compiling a list of everyone to email when we do the changeover announcement. > Do we want to have this mailing list listed as the "mailto" and > the place where the .po files be sent? Probably should, unless anyone can think of a better place. > We'll need to allow the bot's > address to the list, apparently it's either gnutra@ or translation@ > iro.umontreal.ca. Worst case we add it when Mailman holds it back. Thanks for handling the translation issues! -- ==============================| "A slice of life isn't the whole cake Rob Funk <rf...@fu...> | One tooth will never make a full grin" http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind" |
From: Matthias A. <ma...@dt...> - 2004-09-01 01:37:01
|
Hi, I have recently joined the de...@li... translation team and negotiated a cold but welcome takeover of the de.po file. While we're getting 6.2.6 ready for shipping, we need to tell the translation project some bits of information: - who the maintainer is and where we want updated .po files sent by the translation project (the .po files contain the translations) and where distribution tarballs can be downloaded. The current record that they have is: | <domain>fetchmail | <mailto>es...@th... | <keep>6.0.0<keep>6.1.3<keep>6.2.0<keep>6.2.3<keep>6.2.4 | <autosend> | <url>http://www.catb.org/~esr/fetchmail/fetchmail-6.2.5.tar.gz | <ext>cs<ext>pt_BR <ext> means that ESR is getting the cs and pt_BR translations directly from the maintainers, not via the translation project, so we should probably Cc: these maintainers when sending the .pot file and making them aware of the new location of the site and maintainer and everything. See also: http://www.iro.umontreal.ca/translation/HTML/maintainers.html Do we want to have this mailing list listed as the "mailto" and the place where the .po files be sent? We'll need to allow the bot's address to the list, apparently it's either gnutra@ or translation@ iro.umontreal.ca. - the current 6.2.6 .pot file (which contains the untranslated original messages) NOTICE #1: this is actually the URL for a .pot file that we're telling them. NOTICE #2: we cannot send multiple .pot files with one and the same version number, we'll need distinct version numbers if we plan to revise the code. We can use 6.2.5.99.1 for a release candidate and then perhaps bump to 6.2.6 if we haven't made message changes later. I'll handle this when we're sure about how 6.2.6 will finally look like. -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred) |
From: Matthias A. <ma...@dt...> - 2004-09-01 00:03:55
|
Graham Wilson <bo...@de...> writes: > On Fri, Jun 25, 2004 at 01:44:21PM -0500, Graham Wilson wrote: >> What is the purpose of the m4 directory? I can only see that is has one >> file in it (Makefile.am)? >> >> Also, would it be alright to move the macros from m4-local into one file >> (acinclude.m4)? I don't see any need to add a new directory for just one >> or a handful of new macros. > > Revisiting this, it seems like we've decided to keep the autotool macros > as individual files. Since we are going to do that, I think we all agree > that they should be put in a subdirectory. Matthias, would it be alright > to put the macros (and their license) into the m4 directory, or should > the be put back into m4-local? Adding them to the m4 directory might be confusing, because the "autopoint" utility that will be run will update/copy files in(to) the m4/ directory (also po/, intl/). Finding out which files the license applies to will be a bit harder than usual, but there is no /technical/ reason to avoid putting the files into m4 AFAIK. As long as it's only one self-contained macro set, there is no reason not to name it acinclude.m4 either, but things are getting inconcise as the count of macros grows. -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred) |
From: Graham W. <bo...@de...> - 2004-08-30 03:43:41
|
On Fri, Jun 25, 2004 at 01:44:21PM -0500, Graham Wilson wrote: > What is the purpose of the m4 directory? I can only see that is has one > file in it (Makefile.am)? > > Also, would it be alright to move the macros from m4-local into one file > (acinclude.m4)? I don't see any need to add a new directory for just one > or a handful of new macros. Revisiting this, it seems like we've decided to keep the autotool macros as individual files. Since we are going to do that, I think we all agree that they should be put in a subdirectory. Matthias, would it be alright to put the macros (and their license) into the m4 directory, or should the be put back into m4-local? -- gram |
From: Graham W. <bo...@de...> - 2004-08-26 05:56:39
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 When I created the certificate and key for the certificate authority for my server (decoy.wox.org), I mistakenly set the expiry date thirty days from when I create the certificate, which means the certificate should expire very early tommorow morning (UTC). Unfortunately this means to re-enable access you will need to create a new key and certificate request again. I apologize for the inconvenience. Rob and Matthias, can you please send the csr.pem file produced by the following command (preferably PGP signed)? $ openssl req -new -out csr.pem -keyout key.pem - -- gram -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: http://decoy.wox.org/~bob/public.asc iQEVAwUBQS1fcC6fnYH5E4SWAQLvYgf/REG0EnET5SzRHz3UdRPOA2PHQLSO30sT Y3Jr9s6k3C8f8uk/8kjxaVAyS/pwg2u+jCXuiwslajEu5GFln5gzEdPadV3EVfTA aTSfxg8hRxuvI/U/9NZIOYipNKFfFecQyyAbtnDWeGFPTCtOPJ16i/6++mO+RWcS k5ufZ2fUDe/EL7IFeIZ8CTTCv/8dOiRFshTK8t5mFva5N/KuZCXX0IiBB5U6xK8v wzmW5UrPlQUdIC4K/n4njAC9e0ixh0d0aoSVcdu6HfG4dCdqeDautOUhHNbUuVl0 jwBcoTT8rQlE6qv5VLVNgAt5GrndJxM5cpiNMHZV7+vCzaCroWcAvQ== =GFiy -----END PGP SIGNATURE----- |
From: Rob F. <rf...@fu...> - 2004-08-24 20:07:36
|
James Stone wrote: > I see that my mold remover script has been added to fetchmail CVS. I am > very pleased about this. I have got a newer version that has some > improved features and minor bugfixes at: > > http://www.sourceforge.net/moldremover > > I would be grateful if you could distribute this version rather than > version 0.1 OK, version 0.3 is now in the fetchmail code repository. http://decoy.wox.org/svn/fetchmail/trunk/contrib/ -- ==============================| "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: Matthias A. <ma...@dt...> - 2004-08-23 12:10:50
|
Rob Funk <rf...@fu...> writes: > My vote is to properly encode the headers if we have all the necessary > info. If we don't I'd fall back to the Graham's #4; putting non-ASCII > characters in headers is Bad. > > Do sendmail and its ilk translate bounce messages? Not that I know of. There are RFC-1893 and -1894 for machine-readable bounces that allow a decent mail user agent to translate the bounce reasons into the local language (I know no such mailer though). -- Matthias Andree NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF! Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred) |
From: Rob F. <rf...@fu...> - 2004-08-22 21:31:29
|
I haven't had a chance to look into this yet.... ---------- Forwarded Message ---------- Subject: mold remover (fetchmail) Date: Monday 16 August 2004 6:47 am From: James Stone <sp...@io...> To: rf...@fu... I see that my mold remover script has been added to fetchmail CVS. I am very pleased about this. I have got a newer version that has some improved features and minor bugfixes at: http://www.sourceforge.net/moldremover I would be grateful if you could distribute this version rather than version 0.1 Regards, James Stone ------------------------------------------------------- |
From: Rob F. <rf...@fu...> - 2004-08-22 21:29:53
|
This seems appropriate for fetchmail-devel..... ---------- Forwarded Message ---------- Subject: [fetchmail][BUG] fetchmail hangs during pop3 pull after a mail with a null char Date: Tuesday 17 August 2004 4:03 pm From: David Greaves <da...@dg...> To: fet...@li... -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 First : fetchmail is great - thanks :) It's been working for years with these occasional hangs that have been fixed by popping the bad messages and manually filing them. I finally had a bad message arrive when I was in a position to debug! Summary : fetchmail hangs during pop3 pull after a mail with a null char. The mail with a null char is pulled OK but then rejected by local Cyrus lmtp and bounced to postmaster via exim4.20 The next pop3 pull then fails. I've made an effort to trace and I think the hang occurs due to a double call to SMTP_ok which is empty the second time. I am pretty sure the second call originates at sink.c line 1433. in the config expunge 1 fixes the problem (which makes sense) general config is pop3->lmtp->local Cyrus IMAP FAQ G3: 1. OS: Linux RedHat 7.3 kernel 2.6.6 2. gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110) 3. below 4. forwarding to lmtp listener on cyrus 2.2.3 (bounce goes to SMTP exim 4.2) 5. -v -v -f /etc/fetchmailrc 6. at the end nb: SMTP_ok loop start comments are my trace. Aug 17 17:33:01 willow fetchmail[13648]: 6.2.5 querying pop3.ukfsn.org (protocol POP3) at Tue 17 Aug 2004 05:33:01 PM BST: poll started Aug 17 17:33:01 willow fetchmail[13648]: POP3< +OK <aa5...@po...> Aug 17 17:33:01 willow fetchmail[13648]: POP3> CAPA^M Aug 17 17:33:01 willow fetchmail[13648]: POP3< +OK Capability list follows Aug 17 17:33:01 willow fetchmail[13648]: POP3< PIPELINING Aug 17 17:33:01 willow fetchmail[13648]: POP3< TOP Aug 17 17:33:01 willow fetchmail[13648]: POP3< USER Aug 17 17:33:01 willow fetchmail[13648]: POP3< UIDL Aug 17 17:33:01 willow fetchmail[13648]: POP3< STLS Aug 17 17:33:01 willow fetchmail[13648]: POP3< . Aug 17 17:33:01 willow fetchmail[13648]: POP3> USER dgreaves^M Aug 17 17:33:01 willow fetchmail[13648]: POP3< +OK Tell me your password. Aug 17 17:33:01 willow fetchmail[13648]: POP3> PASS *^M Aug 17 17:33:02 willow fetchmail[13648]: POP3< +OK Welcome aboard! You have 55 messages. Aug 17 17:33:05 willow fetchmail[13648]: POP3> STAT Aug 17 17:33:05 willow fetchmail[13648]: POP3< +OK 55 429607 Aug 17 17:33:05 willow fetchmail[13648]: 55 messages for dgreaves at pop3.ukfsn.org (429607 octets). fetchmailrc: set syslog set postmaster "da...@dg..." set nobouncemail set properties "" #set daemon 180 set idfile /var/run/fetchmail.ids # The ukfsn accounts poll pop3.ukfsn.org with proto POP3 tracepolls ~ user 'dgreaves' there with password 'xxxxxxx' is da...@dg... here options fetchall lmtp smtp /var/imap/socket/lmtp expunge 5 ~ antispam 571 550 501 554 <more user accounts removed> here is output from ~ ./fetchmail -v -v -f /etc/fetchmailrc Aug 17 17:43:33 willow fetchmail[13675]: 6.2.5 querying pop3.ukfsn.org (protocol POP3) at Tue 17 Aug 2004 05:43:33 PM BST: poll started Aug 17 17:43:33 willow fetchmail[13675]: POP3< +OK <40b...@po...> Aug 17 17:43:33 willow fetchmail[13675]: POP3> CAPA^M Aug 17 17:43:33 willow fetchmail[13675]: POP3< +OK Capability list follows Aug 17 17:43:34 willow fetchmail[13675]: POP3< PIPELINING Aug 17 17:43:34 willow fetchmail[13675]: POP3< TOP Aug 17 17:43:34 willow fetchmail[13675]: POP3< USER Aug 17 17:43:34 willow fetchmail[13675]: POP3< UIDL Aug 17 17:43:34 willow fetchmail[13675]: POP3< STLS Aug 17 17:43:34 willow fetchmail[13675]: POP3< . Aug 17 17:43:34 willow fetchmail[13675]: POP3> USER dgreaves^M Aug 17 17:43:34 willow fetchmail[13675]: POP3< +OK Tell me your password. Aug 17 17:43:34 willow fetchmail[13675]: POP3> PASS *^M Aug 17 17:43:34 willow fetchmail[13675]: POP3< +OK Welcome aboard! You have 33 messages. Aug 17 17:43:37 willow fetchmail[13675]: selecting or re-polling default folder Aug 17 17:43:37 willow fetchmail[13675]: POP3> STAT Aug 17 17:43:37 willow fetchmail[13675]: POP3< +OK 33 186252 Aug 17 17:43:37 willow fetchmail[13675]: 33 messages for dgreaves at pop3.ukfsn.org (186252 octets). Aug 17 17:43:37 willow fetchmail[13675]: POP3> LIST 1 #**********************************************Aug 17 17:43:37 willow fetchmail[13675]: POP3< +OK 1 9060 Aug 17 17:43:37 willow fetchmail[13675]: POP3> RETR 1 Aug 17 17:43:37 willow fetchmail[13675]: POP3< +OK Message follows Aug 17 17:43:37 willow fetchmail[13675]: reading message dgr...@po...:1 of 33 (9060 octets) Aug 17 17:43:37 willow fetchmail[13675]: About to rewrite Return-Path: <linux-kernel-owner+lkml=40d...@vg...>^M Rewritten version is Return-Path: <linux-kernel-owner+lkml=40d...@vg...>^M Aug 17 17:43:38 willow fetchmail[13675]: About to rewrite From: "O.Sezer" <se...@tt...>^M Rewritten version is From: "O.Sezer" <se...@tt...>^M Aug 17 17:43:38 willow fetchmail[13675]: About to rewrite To: lin...@vg...^M Rewritten version is To: lin...@vg...^M Aug 17 17:43:38 willow fetchmail[13675]: About to rewrite Cc: mar...@cy...^M Rewritten version is Cc: mar...@cy...^M Aug 17 17:43:38 willow fetchmail[13675]: About to rewrite Sender: lin...@vg...^M Rewritten version is Sender: lin...@vg...^M Aug 17 17:43:38 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:38 willow fetchmail[13675]: LMTP< 220 willow LMTP Cyrus v2.2.3 ready Aug 17 17:43:38 willow fetchmail[13675]: LMTP> LHLO localhost Aug 17 17:43:38 willow fetchmail[13675]: SMTP< 250-willow Aug 17 17:43:38 willow fetchmail[13675]: SMTP< 250-8BITMIME Aug 17 17:43:38 willow fetchmail[13675]: SMTP< 250-ENHANCEDSTATUSCODES Aug 17 17:43:38 willow fetchmail[13675]: SMTP< 250-PIPELINING Aug 17 17:43:38 willow fetchmail[13675]: SMTP< 250-SIZE Aug 17 17:43:38 willow fetchmail[13675]: SMTP< 250-AUTH EXTERNAL Aug 17 17:43:38 willow fetchmail[13675]: SMTP< 250 IGNOREQUOTA Aug 17 17:43:38 willow fetchmail[13675]: forwarding to /var/imap/socket/lmtp Aug 17 17:43:38 willow fetchmail[13675]: LMTP> MAIL FROM:<linux-kernel-owner+lkml=40d...@vg...rnel.o rg> SIZE=9060 Aug 17 17:43:38 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:38 willow fetchmail[13675]: LMTP< 250 2.1.0 ok Aug 17 17:43:38 willow fetchmail[13675]: LMTP> RCPT TO:<da...@dg...> Aug 17 17:43:38 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:38 willow fetchmail[13675]: LMTP< 250 2.1.5 ok Aug 17 17:43:38 willow fetchmail[13675]: LMTP> DATA Aug 17 17:43:38 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:38 willow fetchmail[13675]: LMTP< 354 go ahead ************************************************************************** ************************************************************************** ****************Aug 17 17:43:38 willow fetchmail[13675]: message dgr...@po...:1 was not the expected length (9317 actual != 9060 expected) Aug 17 17:43:38 willow fetchmail[13675]: LMTP>. (EOM) Aug 17 17:43:38 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:38 willow fetchmail[13675]: LMTP< 250 2.1.5 Ok Aug 17 17:43:38 willow fetchmail[13675]: flushed Aug 17 17:43:38 willow fetchmail[13675]: POP3> DELE 1^M Aug 17 17:43:38 willow fetchmail[13675]: POP3< +OK Done. Aug 17 17:43:38 willow fetchmail[13675]: POP3> LIST 2 Aug 17 17:43:38 willow fetchmail[13675]: POP3< +OK 2 5098 Aug 17 17:43:38 willow fetchmail[13675]: POP3> RETR 2 Aug 17 17:43:39 willow fetchmail[13675]: POP3< +OK Message follows Aug 17 17:43:39 willow fetchmail[13675]: reading message dgr...@po...:2 of 33 (5098 octets) Aug 17 17:43:39 willow fetchmail[13675]: About to rewrite Return-Path: <linux-kernel-owner+lkml=40d...@vg...>^M Rewritten version is Return-Path: <linux-kernel-owner+lkml=40d...@vg...>^M #****************************************************************Aug 17 17:43:39 willow fetchmail[13675]: About to rewrite From: Christoph Hellwig <hc...@in...>^M Rewritten version is From: Christoph Hellwig <hc...@in...>^M Aug 17 17:43:39 willow fetchmail[13675]: About to rewrite To: Markus Lidel <Mar...@sh...>^M Rewritten version is To: Markus Lidel <Mar...@sh...>^M Aug 17 17:43:39 willow fetchmail[13675]: About to rewrite Cc: Christoph Hellwig <hc...@in...>,^M ^IWarren Togami <wt...@re...>, lin...@vg...^M Rewritten version is Cc: Christoph Hellwig <hc...@in...>,^M ^IWarren Togami <wt...@re...>, lin...@vg...^M Aug 17 17:43:39 willow fetchmail[13675]: About to rewrite Sender: lin...@vg...^M Rewritten version is Sender: lin...@vg...^M Aug 17 17:43:39 willow fetchmail[13675]: forwarding to /var/imap/socket/lmtp Aug 17 17:43:39 willow fetchmail[13675]: LMTP> MAIL FROM:<linux-kernel-owner+lkml=40d...@vg...rnel.o rg> SIZE=5098 Aug 17 17:43:39 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:39 willow fetchmail[13675]: LMTP< 250 2.1.0 ok Aug 17 17:43:39 willow fetchmail[13675]: LMTP> RCPT TO:<da...@dg...> Aug 17 17:43:39 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:39 willow fetchmail[13675]: LMTP< 250 2.1.5 ok Aug 17 17:43:39 willow fetchmail[13675]: LMTP> DATA Aug 17 17:43:39 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:39 willow fetchmail[13675]: LMTP< 354 go ahead Aug 17 17:43:39 willow fetchmail[13675]: message dgr...@po...:2 was not the expected length (5209 actual != 5098 expected) Aug 17 17:43:39 willow fetchmail[13675]: LMTP>. (EOM) Aug 17 17:43:39 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:39 willow fetchmail[13675]: LMTP< 250 2.1.5 Ok Aug 17 17:43:39 willow fetchmail[13675]: flushed Aug 17 17:43:39 willow fetchmail[13675]: POP3> DELE 2^M Aug 17 17:43:39 willow fetchmail[13675]: POP3< +OK Done. Aug 17 17:43:39 willow fetchmail[13675]: POP3> LIST 3 Aug 17 17:43:39 willow fetchmail[13675]: POP3< +OK 3 2147 Aug 17 17:43:39 willow fetchmail[13675]: POP3> RETR 3 Aug 17 17:43:40 willow fetchmail[13675]: POP3< +OK Message follows Aug 17 17:43:40 willow fetchmail[13675]: reading message dgr...@po...:3 of 33 (2147 octets) Aug 17 17:43:40 willow fetchmail[13675]: About to rewrite Return-Path: <reiserfs-list-return-20355-david=dgr...@na...>^M Rewritten version is Return-Path: <reiserfs-list-return-20355-david=dgr...@na...>^M #********#****************************Aug 17 17:43:40 willow fetchmail[13675]: About to rewrite From: elliott <aur...@se...>^M Rewritten version is From: elliott <aur...@se...>^M Aug 17 17:43:40 willow fetchmail[13675]: About to rewrite To: rei...@na...^M Rewritten version is To: rei...@na...^M Aug 17 17:43:40 willow fetchmail[13675]: forwarding to /var/imap/socket/lmtp Aug 17 17:43:40 willow fetchmail[13675]: LMTP> MAIL FROM:<reiserfs-list-return-20355-david=dgr...@na...> BODY=8BITMIME SIZE=2147 Aug 17 17:43:40 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:40 willow fetchmail[13675]: LMTP< 250 2.1.0 ok Aug 17 17:43:40 willow fetchmail[13675]: LMTP> RCPT TO:<da...@dg...> Aug 17 17:43:40 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:40 willow fetchmail[13675]: LMTP< 250 2.1.5 ok Aug 17 17:43:40 willow fetchmail[13675]: LMTP> DATA Aug 17 17:43:40 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:40 willow fetchmail[13675]: LMTP< 354 go ahead Aug 17 17:43:40 willow fetchmail[13675]: message dgr...@po...:3 was not the expected length (2194 actual != 2147 expected) Aug 17 17:43:40 willow fetchmail[13675]: LMTP>. (EOM) Aug 17 17:43:40 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:40 willow fetchmail[13675]: LMTP< 554 5.6.0 Message contains NUL characters Aug 17 17:43:40 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:40 willow fetchmail[13675]: SMTP< 220 willow ESMTP Exim 4.20 Tue, 17 Aug 2004 17:43:40 +0100 Aug 17 17:43:40 willow fetchmail[13675]: SMTP> HELO localhost Aug 17 17:43:40 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:40 willow fetchmail[13675]: SMTP< 250 willow Hello [AdFSF0x5m0a0vDWoZf1oPXMI8ichzbi7] at localhost.localdomain [127.0.0.1] Aug 17 17:43:40 willow fetchmail[13675]: SMTP> MAIL FROM:<FET...@wi...> Aug 17 17:43:40 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:40 willow fetchmail[13675]: SMTP< 250 OK Aug 17 17:43:40 willow fetchmail[13675]: SMTP> RCPT TO:<da...@dg...> Aug 17 17:43:40 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:40 willow fetchmail[13675]: SMTP< 250 Accepted Aug 17 17:43:40 willow fetchmail[13675]: SMTP> DATA Aug 17 17:43:40 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:40 willow fetchmail[13675]: SMTP< 354 Enter message, ending with "." on a line by itself Aug 17 17:43:40 willow fetchmail[13675]: SMTP: (bounce-message body) Aug 17 17:43:40 willow fetchmail[13675]: SMTP>. (EOM) Aug 17 17:43:40 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:40 willow fetchmail[13675]: SMTP< 250 OK id=1Bx73k-0003Ya-FK Aug 17 17:43:40 willow fetchmail[13675]: SMTP> QUIT Aug 17 17:43:40 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:40 willow fetchmail[13675]: SMTP< 221 willow closing connection Aug 17 17:43:40 willow fetchmail[13675]: flushed Aug 17 17:43:40 willow fetchmail[13675]: POP3> DELE 3^M Aug 17 17:43:40 willow fetchmail[13675]: POP3< +OK Done. Aug 17 17:43:40 willow fetchmail[13675]: POP3> LIST 4 Aug 17 17:43:40 willow fetchmail[13675]: POP3< +OK 4 4406 Aug 17 17:43:40 willow fetchmail[13675]: POP3> RETR 4 Aug 17 17:43:40 willow fetchmail[13675]: POP3< +OK Message follows Aug 17 17:43:40 willow fetchmail[13675]: reading message dgr...@po...:4 of 33 (4406 octets) Aug 17 17:43:41 willow fetchmail[13675]: About to rewrite Return-Path: <net...@os...>^M Rewritten version is Return-Path: <net...@os...>^M Aug 17 17:43:41 willow fetchmail[13675]: About to rewrite From: Wensong Zhang <we...@li...>^M Rewritten version is From: Wensong Zhang <we...@li...>^M Aug 17 17:43:41 willow fetchmail[13675]: About to rewrite To: ne...@os...^M Rewritten version is To: ne...@os...^M Aug 17 17:43:41 willow fetchmail[13675]: About to rewrite Cc: Julian Anastasov <ja...@ss...>^M Rewritten version is Cc: Julian Anastasov <ja...@ss...>^M Aug 17 17:43:41 willow fetchmail[13675]: About to rewrite Sender: net...@os...^M Rewritten version is Sender: net...@os...^M Aug 17 17:43:41 willow fetchmail[13675]: forwarding to /var/imap/socket/lmtp Aug 17 17:43:41 willow fetchmail[13675]: SMTP> MAIL FROM:<net...@os...> SIZE=4406 Aug 17 17:43:41 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:41 willow fetchmail[13675]: SMTP< 250 2.1.0 ok Aug 17 17:43:41 willow fetchmail[13675]: SMTP> RCPT TO:<da...@dg...> Aug 17 17:43:41 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:41 willow fetchmail[13675]: SMTP< 250 2.1.5 ok Aug 17 17:43:41 willow fetchmail[13675]: SMTP> DATA Aug 17 17:43:41 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:41 willow fetchmail[13675]: SMTP< 354 go ahead *******************************************************Aug 17 17:43:41 willow fetchmail[13675]: message dgr...@po...:4 was not the expected length (4533 actual != 4406 expected) Aug 17 17:43:41 willow fetchmail[13675]: SMTP>. (EOM) Aug 17 17:43:41 willow fetchmail[13675]: SMTP_ok loop start Aug 17 17:43:41 willow fetchmail[13675]: SMTP< 250 2.1.5 Ok ## 5 minute hang Aug 17 17:48:41 willow fetchmail[13675]: smtp listener protocol error 2 Aug 17 17:48:41 willow fetchmail[13675]: not flushed Aug 17 17:48:41 willow fetchmail[13675]: POP3> LIST 5 Aug 17 17:48:41 willow fetchmail[13675]: POP3< -ERR Client has been idle for too long. Aug 17 17:48:41 willow fetchmail[13675]: Client has been idle for too long. Aug 17 17:48:41 willow fetchmail[13675]: POP3> QUIT^M Aug 17 17:48:41 willow fetchmail[13675]: client/server protocol error while fetching from pop3.ukfsn.org Aug 17 17:48:41 willow fetchmail[13675]: 6.2.5 querying pop3.ukfsn.org (protocol POP3) at Tue 17 Aug 2004 05:48:41 PM BST: poll completed Aug 17 17:48:41 willow fetchmail[13675]: Query status=4 (PROTOCOL) # ./fetchmail -V -v -v -f /etc/fetchmailrc This is fetchmail release 6.2.5+NLS Fallback MDA: (none) Linux willow 2.6.6 #1 Wed Jun 2 12:15:21 BST 2004 i586 unknown Taking options from command line and /etc/fetchmailrc Idfile is /var/run/fetchmail.ids Progress messages will be logged via syslog Fetchmail will show progress dots even in logfiles. Fetchmail will forward misaddressed multidrop messages to da...@dg.... Fetchmail will direct error mail to the postmaster. Options for retrieving from dgr...@po...: ~ True name of server is pop3.ukfsn.org. ~ This host will be queried when no host is specified. ~ Password = "xxxxxx". ~ Protocol is POP3 (using default port). ~ All available authentication methods will be tried. ~ 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). ~ Rewrite of server-local addresses is enabled (--norewrite off). ~ Carriage-return stripping is disabled (stripcr off). ~ Carriage-return forcing is disabled (forcecr off). ~ 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) ~ No received-message limit (--fetchlimit 0). ~ Fetch message size limit is 100 (--fetchsizelimit 100). ~ Do binary search of UIDs during 9 out of 10 polls (--fastuidl 10). ~ No SMTP message batch limit (--batchlimit 0). ~ Deletion interval between expunges forced to 5 (--expunge 5). ~ Messages will be LMTP-forwarded to: /var/imap/socket/lmtp ~ Recognized listener spam block responses are: 571 550 501 554 ~ No pre-connection command. ~ No post-connection command. ~ Single-drop mode: 1 local name(s) recognized. ~ da...@dg... ~ No interface requirement specified. ~ No monitor interface specified. ~ No plugin command specified. ~ No plugout command specified. ~ 1 UIDs saved. ~ 0bcc1e7633bb91ec04fbf4e1505b377d ~ Poll trace information will be added to the Received header. other account info removed David Greaves -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBImRz8LvjTle4P1gRAvSnAJ9IwApVKGz2R9rFX30S7VX6PPGzHgCggRDV 5Ya+ZOAplqk+vrBfwOua+r0= =7Ndc -----END PGP SIGNATURE----- _______________________________________________ Fetchmail-friends mailing list Fet...@li... http://lists.ccil.org/cgi-bin/mailman/listinfo/fetchmail-friends ------------------------------------------------------- |
From: Rob F. <rf...@fu...> - 2004-08-22 21:28:25
|
[I just returned from vacation...] Matthias Andree wrote: > Graham Wilson <bo...@de...> writes: > > #4 Is it possible to only send messages in English using US-ASCII. I > > know that is probably unfair to a lot of our users, but it really > > seems like the cleanest solution to me. > > Hm. That would be a deliberate regression that doesn't qualify for > 6.2.6 at least :) Rob's call IMO. My vote is to properly encode the headers if we have all the necessary info. If we don't I'd fall back to the Graham's #4; putting non-ASCII characters in headers is Bad. Do sendmail and its ilk translate bounce messages? -- ==============================| "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: Matthias A. <ma...@dt...> - 2004-08-20 12:49:32
|
Brian Candler <B.C...@po...> writes: > On Thu, Aug 19, 2004 at 01:10:11PM +0200, Matthias Andree wrote: >> Brian Candler <B.C...@po...> writes: >> >> > #5 if (ch<32 || ch>126) ch = '?'; >> >> Not an option. Greek or Cyrillic text might come out as all question >> marks. > > But better than saying "all text generated by auxilliary programs must be in > English" ?? ?? ??????? <- what have I written there? It isn't better, both aren't the Right Thing. I'll check if we can query the character set from the catalog files and if so, adding proper declarations and perhaps RFC-2047 encoding be shouldn't pose too large an effort. -- Matthias Andree NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF! Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred) |
From: Brian C. <B.C...@po...> - 2004-08-19 16:07:29
|
On Thu, Aug 19, 2004 at 01:10:11PM +0200, Matthias Andree wrote: > Brian Candler <B.C...@po...> writes: > > > #5 if (ch<32 || ch>126) ch = '?'; > > Not an option. Greek or Cyrillic text might come out as all question > marks. But better than saying "all text generated by auxilliary programs must be in English" |
From: Matthias A. <ma...@dt...> - 2004-08-19 13:10:14
|
Brian Candler <B.C...@po...> writes: > #5 if (ch<32 || ch>126) ch = '?'; Not an option. Greek or Cyrillic text might come out as all question marks. -- Matthias Andree NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF! Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred) |
From: Matthias A. <ma...@dt...> - 2004-08-19 12:08:48
|
Graham Wilson <bo...@de...> writes: > #4 Is it possible to only send messages in English using US-ASCII. I > know that is probably unfair to a lot of our users, but it really > seems like the cleanest solution to me. Hm. That would be a deliberate regression that doesn't qualify for 6.2.6 at least :) Rob's call IMO. -- Matthias Andree NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF! Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred) |
From: Brian C. <B.C...@po...> - 2004-08-19 10:38:47
|
On Wed, Aug 18, 2004 at 04:14:52PM -0500, Graham Wilson wrote: > On Wed, Aug 18, 2004 at 07:19:28PM +0200, Matthias Andree wrote: > > #1 request transliteration from translators. This won't work for > > languages that don't use a Latin character set but, for instance, > > Cyrillic, Greek or Thai to name just three. It works for some > > characters, those I know: > > > > ??=ae, ??=oe, ??=ue, ??=ss (sz in special cases when the preceding vowel > > is long and ss would be ambiguous), ??=ae, ??=aa, ??=oe, ??=oe, ??=c > > > > #2 request that national characters be pre-encoded as RFC-2047 (for the > > Subject) or as quoted-printable for the body. Major hassle for the > > translators. > > > > #3 let fetchmail do proper MIME encoding of Subject and body. > > #4 Is it possible to only send messages in English using US-ASCII. I > know that is probably unfair to a lot of our users, but it really > seems like the cleanest solution to me. #5 if (ch<32 || ch>126) ch = '?'; |
From: Graham W. <bo...@de...> - 2004-08-18 23:15:06
|
On Wed, Aug 18, 2004 at 07:19:28PM +0200, Matthias Andree wrote: > #1 request transliteration from translators. This won't work for > languages that don't use a Latin character set but, for instance, > Cyrillic, Greek or Thai to name just three. It works for some > characters, those I know: > > ä=ae, ö=oe, ü=ue, ß=ss (sz in special cases when the preceding vowel > is long and ss would be ambiguous), æ=ae, å=aa, ø=oe, œ=oe, ç=c > > #2 request that national characters be pre-encoded as RFC-2047 (for the > Subject) or as quoted-printable for the body. Major hassle for the > translators. > > #3 let fetchmail do proper MIME encoding of Subject and body. #4 Is it possible to only send messages in English using US-ASCII. I know that is probably unfair to a lot of our users, but it really seems like the cleanest solution to me. -- gram |
From: Matthias A. <ma...@dt...> - 2004-08-18 19:19:31
|
Hi, in certain circumstances, fetchmail will send a mail to the user. This might be, for instance, the warning that an oversized message has been left on the server, or that fetchmail had been unable to log in (at least in daemon mode). The problem is that some translations, for instance the German translation, contains national characters, which are emitted to the mail (Subject and other) verbatim, and it is real fun because the character set used depends on the locale, IOW, it may depend on whether I start fetchmail from mlterm or from xterm... This gets really interesting if SpamAssassin is in use. Now watch this, particularly the X-Amavis-Alert and X-Spam-Status headers: (in case you wonder, it is de_DE.UTF-8, default on German installations of SuSE Linux 9.1, I've changed org to ork to avoid spam): | Return-Path: <fetchmail-daemon@m2a2.dyndns.ork> | Date: Wed, 18 Aug 2004 12:58:03 +0200 (CEST) | Subject: Fetchmail-Warnung: übergroße Nachrichten | Message-Id: <200...@me...> | From: fetchmail-daemon@m2a2.dyndns.ork | To: undisclosed-recipients: ; | X-Virus-Scanned: by amavisd-new at m2a2.dyndns.ork | X-Amavis-Alert: BAD HEADER Non-encoded 8-bit data (char C3 hex) in message header 'Subject' | Subject: Fetchmail-Warnung: \303\274bergro\303\237e Nach... | ^ | X-Spam-Status: Yes, hits=7.6 tagged_above=0.0 required=6.0 | tests=MSGID_FROM_MTA_SHORT, NO_REAL_NAME, SUBJ_ILLEGAL_CHARS | X-Spam-Level: ******* | X-Spam-Flag: YES | | Die folgenden übergroßen Nachrichten verbleiben auf dem Mail-Server pop3.web.de: | 1 msg 87025 Oktetts lang von fetchmail ausgelassen. | | -- | Der Fetchmail-Dämon Evidently, a default SpamAssassin 2.6X installation considers this oversize warning spam. Oops! There are several solutions to attack this: #1 request transliteration from translators. This won't work for languages that don't use a Latin character set but, for instance, Cyrillic, Greek or Thai to name just three. It works for some characters, those I know: ä=ae, ö=oe, ü=ue, ß=ss (sz in special cases when the preceding vowel is long and ss would be ambiguous), æ=ae, å=aa, ø=oe, œ=oe, ç=c #2 request that national characters be pre-encoded as RFC-2047 (for the Subject) or as quoted-printable for the body. Major hassle for the translators. #3 let fetchmail do proper MIME encoding of Subject and body. I'd think #3 is the best but most complex option. What do you think? -- Matthias Andree NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF! Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred) |
From: Rob F. <rf...@fu...> - 2004-08-09 09:29:04
|
I set up an actual web page at http://fetchmail.berlios.de/, based on ESR's fetchmail pages but without some stuff that seemed extraneous. I also went through and tried edited the pages to change the voice (e.g. s/I/we/g), but I gave up about a third of the way through the FAQ. And I didn't check any of it into SVN, just edited the HTML on the site. I also added the 6.2.5 release (source only) to the project's released files, so that we don't have to send people to ESR's page for the latest release before we get 6.2.6 out. -- ==============================| "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: Rob F. <rf...@fu...> - 2004-08-09 06:39:33
|
Graham Wilson wrote: > I think this was committed by esr before we started Community Fetchmail. Heh... yep, looks like that went in there rather early. It's revision 3863, and the 6.2.5 release is revision 3861. To see ESR's change messages from 6.2.5 to the handoff, do: svn log -v -r 3861:3880 at the top of a checked-out tree. Anyone know an easy way to use tags directly in the above instead of trying to figure out what revision number matches what tag? -- ==============================| "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: Graham W. <bo...@de...> - 2004-08-09 06:11:23
|
On Mon, Aug 09, 2004 at 04:42:25AM +0200, Matthias Andree wrote: > Graham Wilson <bo...@de...> writes: > > I have applied this patch to the Debian version of fetchmail. It > > sets fetchsizelimit to 1 for all POP variants, not just POP3. Without > > the patch, POP variants aside from POP3 won't work correctly. > > > > I recommend that we commit it to the repository. > > Seconded. I think this was committed by esr before we started Community Fetchmail. -- gram |