Menu
▾
▴
fetchmail-devel — Development related discussion
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
(5) |
Nov
|
Dec
|
|
From: <ad...@be...> - 2006-05-14 14:24:39
|
Bug #7485, was updated on 2006-May-14 13:20 Here is a current snapshot of the bug. Project: Community Fetchmail Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: fastian Assigned to : none Summary: server timeout Details: Using a MiniMac and the latest fetchmail, the pop3 server at the isp is timing out before fetchmail can delete a bounced email with no recipient , as follows. fetchmail: 6.3.4 querying pop3.uklinux.net (protocol POP3) at Sun, 14 May 2006 11:12:43 +0100 (BST): poll started fetchmail: POP3< +OK ready fetchmail: POP3> CAPA fetchmail: POP3< +OK Capability list follows fetchmail: POP3< TOP fetchmail: POP3< USER fetchmail: POP3< LOGIN-DELAY 0 fetchmail: POP3< EXPIRE 0 fetchmail: POP3< UIDL fetchmail: POP3< RESP-CODES fetchmail: POP3< AUTH-RESP-CODE fetchmail: POP3< X-MANGLE fetchmail: POP3< X-MACRO fetchmail: POP3< X-LOCALTIME Sun, 14 May 2006 11:13:43 +0100 fetchmail: POP3< . fetchmail: POP3> USER someone fetchmail: POP3< +OK Password required for pda#iggy. fetchmail: POP3> PASS * fetchmail: POP3< +OK someone has 2 visible messages (0 hidden) in 2161 octets. fetchmail: POP3> STAT fetchmail: POP3< +OK 2 2161 fetchmail: POP3> LAST fetchmail: POP3< +OK 0 is the last read message. 2 messages for someone at pop3.uklinux.net (2161 octets). fetchmail: POP3> LIST 1 fetchmail: POP3< +OK 1 1082 fetchmail: POP3> TOP 1 99999999 fetchmail: POP3< +OK Message follows reading message so...@po...:1 of 2 (1082 octets) fetchmail: SMTP< 220 highlandhorizon.co.uk ESMTP Postfix fetchmail: SMTP> EHLO igServer.local fetchmail: SMTP< 250-highlandhorizon.co.uk fetchmail: SMTP< 250-PIPELINING fetchmail: SMTP< 250-SIZE 10240000 fetchmail: SMTP< 250-VRFY fetchmail: SMTP< 250-ETRN fetchmail: SMTP< 250 8BITMIME fetchmail: SMTP> MAIL FROM:<ig...@fa...> BODY=7BIT SIZE=1082 fetchmail: SMTP< 250 Ok fetchmail: SMTP> RCPT TO:<te...@hi...> fetchmail: SMTP< 550 <te...@hi...>: Recipient address rejected: User unknown in local recipient table fetchmail: SMTP error: 550 <te...@hi...>: Recipient address rejected: User unknown in local recipient table fetchmail: SMTP listener doesn't like recipient address `te...@hi...' fetchmail: SMTP< 220 highlandhorizon.co.uk ESMTP Postfix fetchmail: SMTP> HELO igServer.local fetchmail: SMTP< 250 highlandhorizon.co.uk fetchmail: SMTP> MAIL FROM:<> fetchmail: SMTP< 250 Ok fetchmail: SMTP> RCPT TO:<iggy> fetchmail: SMTP< 250 Ok fetchmail: SMTP> DATA fetchmail: SMTP< 354 End data with <CR><LF>.<CR><LF> fetchmail: SMTP: (bounce-message body) fetchmail: SMTP>. (EOM) fetchmail: SMTP< 250 Ok: queued as 377F2C3B29 fetchmail: SMTP> QUIT fetchmail: SMTP< 221 Bye fetchmail: SMTP> RCPT TO:<iggy@localhost> fetchmail: SMTP< 250 Ok fetchmail: no address matches; forwarding to iggy. fetchmail: SMTP> DATA fetchmail: SMTP< 354 End data with <CR><LF>.<CR><LF> #*********fetchmail: SMTP>. (EOM) fetchmail: SMTP< 250 Ok: queued as 8375BC3B2A flushed fetchmail: POP3> DELE 1 fetchmail: POP3< -ERR POP timeout from s1.uklinux.net fetchmail: POP timeout from s1.uklinux.net fetchmail: POP3> QUIT fetchmail: POP3< +OK Pop server at s1.uklinux.net signing off. fetchmail: 6.3.4 querying pop3.uklinux.net (protocol POP3) at Sun, 14 May 2006 11:15:44 +0100 (BST): poll completed fetchmail: Query status=24 fetchmail: normal termination, status 24 For detailed info, follow this link: http://developer.berlios.de/bugs/?func=detailbug&bug_id=7485&group_id=1824 |
|
From: Translation P. R. <tra...@ir...> - 2006-05-04 06:06:54
|
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file, for programs using the textual domain `fetchmail', has been submitted by the team of translators taking care of the Russian language. This particular file, along with all other PO files pertaining to the same textual domain, is available as: > http://www.iro.umontreal.ca/translation/maint/fetchmail/ru.po The file should soon be made available in mirror sites as: > ftp://ftp.unex.es/pub/gnu-i18n/po/maint/fetchmail/ru.po > http://translation.sf.net/maint/fetchmail/ru.po This file has already been sent to you separately on 2006-05-04, as a MIME invoice unpacking the file `fetchmail-6.3.4.ru.po'. The following HTML page should also be updated by tomorrow. > http://www.iro.umontreal.ca/translation/HTML/domain-fetchmail.html Please consider including all PO files, as they stand, in the `po/' subdirectory of your next release of programs using that textual domain, whether it is official or pretest. Whenever you have a distribution ready which holds a newer PO Template, please send the URL of this distribution to the address below. The distribution could be a pretest or a snapshot, it does not even have to compile. This is to be used by translators, when they need to get some translation context from your sources. Within the Translation Project, each PO Template file should have different version numbers, but since it is not OK to have two different distributions using same version numbers, this is not a problem in practice. Contact me if any question arises. Thanks for your collaboration, The Translation Project robot, in the name of your translation coordinator. mailto:tra...@ir... |
|
From: Translation P. R. <tra...@ir...> - 2006-05-04 06:04:59
|
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file, for programs using the textual domain `fetchmail', has been submitted by the team of translators taking care of the Vietnamese language. This particular file, along with all other PO files pertaining to the same textual domain, is available as: > http://www.iro.umontreal.ca/translation/maint/fetchmail/vi.po The file should soon be made available in mirror sites as: > ftp://ftp.unex.es/pub/gnu-i18n/po/maint/fetchmail/vi.po > http://translation.sf.net/maint/fetchmail/vi.po This file has already been sent to you separately on 2006-05-04, as a MIME invoice unpacking the file `fetchmail-6.3.4.vi.po'. The following HTML page should also be updated by tomorrow. > http://www.iro.umontreal.ca/translation/HTML/domain-fetchmail.html Please consider including all PO files, as they stand, in the `po/' subdirectory of your next release of programs using that textual domain, whether it is official or pretest. Whenever you have a distribution ready which holds a newer PO Template, please send the URL of this distribution to the address below. The distribution could be a pretest or a snapshot, it does not even have to compile. This is to be used by translators, when they need to get some translation context from your sources. Within the Translation Project, each PO Template file should have different version numbers, but since it is not OK to have two different distributions using same version numbers, this is not a problem in practice. Contact me if any question arises. Thanks for your collaboration, The Translation Project robot, in the name of your translation coordinator. mailto:tra...@ir... |
|
From: <ke...@ib...> - 2006-05-02 17:39:05
|
At about 2006-05-02 15:39:27 UCT, `keeper' moved the following files from
Incoming to system/mail/pop/fetchmail (remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links):
fetchmail-6.3.4.lsm
fetchmail-6.3.4.tar.bz2 Remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links.
fetchmail-6.3.4.tar.bz2.asc
These replaced the following files:
fetchmail-6.3.2.lsm
fetchmail-6.3.2.tar.bz2 Remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links.
fetchmail-6.3.3.lsm
fetchmail-6.3.3.tar.bz2 Remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links.
Thank you for your contribution of time, effort, and creativity.
This message was a form letter generated by keeper 1.55, but replying to
it will reach the human who told keeper what to do. You got this note
because you're listed as a maintainer or author in the archive part involved.
If your package was actually uploaded by someone else, and you know who that
person is, please try to get that person to list him or herself in the LSM.
--
|
|
From: Daniel R. G. <sk...@iS...> - 2006-05-02 05:14:57
|
On Tue, 2006 May 02 00:52:29 +0200, Matthias Andree wrote: > > Well, there are string list functions inside fetchmail, and these can > help with the implementation. I wonder if that's useful though - that > would mean servers behind a load balancer use different common names. I was thinking of a single DNS name resolving to multiple such hosts, but yes, same idea. A really, really badly broken SSL setup }:) Looking at the code, however, I think I'll probably shy away from that. SSL_verify_callback() already has too many levels of indentation, and checking against multiple common names would require another one (for a nested loop). Someone really should refactor that function.... > Looks good to me (I haven't applied and tested it though yet). > > A tiny bit, the "cname" variables might better be renamed (perhaps to > "comname" or sslcommonname) to avoid someone (like myself) from assuming > it might have to do with the DNS CNAME resource record (canonical name). Excellent point. Will do that. > Thanks for your work! Glad to contribute. I'll flesh out the patch, tweak it as advised, and submit it when ready. Sincerely yours, --Daniel -- NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef? EMAIL1 = sk...@is... ## don't smell bad--- (/o|o\) / EMAIL2 = sk...@al... ## it's the people who < (^),> WWW = http://www.******.org/ ## annoy them that do! / \ -- (****** = site not yet online) |
|
From: Matthias A. <mat...@gm...> - 2006-05-02 00:52:10
|
"Daniel Richard G." <sk...@iS...> writes: > I've gone ahead and put together a preliminary patch, against the SVN code. > This implements a new keyword: "sslcommonname". (Forget my earlier > suggestion of "sslalternate"---I wasn't thinking straight when I made it :] > > The approach I took was basically to find all instances of > "sslfingerprint", and implement the new keyword similarly at each turn > (which turned out to be quite easy). On the downside, you can only specify > one CommonName, whereas I had originally envisioned allowing many. Well, there are string list functions inside fetchmail, and these can help with the implementation. I wonder if that's useful though - that would mean servers behind a load balancer use different common names. > You'll notice that the critical bits are in driver.c, imap.c and pop3.c, > before and when the call to SSLOpen() is made. Everything else is > supporting boilerplate. > > Please let me know how this patch looks, and if it looks good, I'll flesh > it out (with deltas on the man page and documentation) for submission. Looks good to me (I haven't applied and tested it though yet). A tiny bit, the "cname" variables might better be renamed (perhaps to "comname" or sslcommonname) to avoid someone (like myself) from assuming it might have to do with the DNS CNAME resource record (canonical name). Thanks for your work! -- Matthias Andree |
|
From: <ke...@ib...> - 2006-05-01 20:12:17
|
At about 2006-05-01 18:12:01 UCT, `keeper' moved the following files from
Incoming to system/mail/pop/fetchmail (remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links):
fetchmail-6.3.2.lsm
fetchmail-6.3.2.tar.bz2 Remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links.
fetchmail-6.3.3.lsm
fetchmail-6.3.3.tar.bz2 Remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links.
These replaced the following files:
fetchmail-5.9.13-1.i386.rpm remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links
fetchmail-5.9.13-1.src.rpm remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links
fetchmail-5.9.13.tar.gz remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links
fetchmail-5.9.14-1.i386.rpm remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links
fetchmail-5.9.14-1.lsm
fetchmail-5.9.14-1.src.rpm remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links
fetchmail-5.9.14.tar.gz remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links
fetchmail-6.1.0-1.i386.rpm remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links
fetchmail-6.1.0-1.src.rpm remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links
fetchmail-6.1.0.tar.gz remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links
fetchmail-6.1.1-1.i386.rpm remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links
fetchmail-6.1.1-1.src.rpm remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links
fetchmail-6.1.1.tar.gz remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links
fetchmail-6.1.2-1.i386.rpm remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links
fetchmail-6.1.2-1.src.rpm remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links
fetchmail-6.1.2.tar.gz remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links
fetchmail-6.2.2-1.i386.rpm remote mail retrieval and forwarding utility
fetchmail-6.2.2-1.src.rpm remote mail retrieval and forwarding utility
fetchmail-6.2.2.tar.gz remote mail retrieval and forwarding utility
fetchmail-6.2.5.2.lsm
fetchmail-6.2.5.2.tar.gz remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links
fetchmail-6.3.0.tar.bz2 Remote mail retrieval and forwarding utility intended for use over on-demand TCP/IP links.
fetchmail.README
fetchmail.lsm
Thank you for your contribution of time, effort, and creativity.
This message was a form letter generated by keeper 1.55, but replying to
it will reach the human who told keeper what to do. You got this note
because you're listed as a maintainer or author in the archive part involved.
If your package was actually uploaded by someone else, and you know who that
person is, please try to get that person to list him or herself in the LSM.
--
|
|
From: Daniel R. G. <sk...@iS...> - 2006-05-01 16:39:59
|
I've gone ahead and put together a preliminary patch, against the SVN code. This implements a new keyword: "sslcommonname". (Forget my earlier suggestion of "sslalternate"---I wasn't thinking straight when I made it :] The approach I took was basically to find all instances of "sslfingerprint", and implement the new keyword similarly at each turn (which turned out to be quite easy). On the downside, you can only specify one CommonName, whereas I had originally envisioned allowing many. You'll notice that the critical bits are in driver.c, imap.c and pop3.c, before and when the call to SSLOpen() is made. Everything else is supporting boilerplate. Please let me know how this patch looks, and if it looks good, I'll flesh it out (with deltas on the man page and documentation) for submission. --Daniel -- NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef? EMAIL1 = sk...@is... ## don't smell bad--- (/o|o\) / EMAIL2 = sk...@al... ## it's the people who < (^),> WWW = http://www.******.org/ ## annoy them that do! / \ -- (****** = site not yet online) |
|
From: Matthias A. <mat...@gm...> - 2006-04-28 12:00:02
|
Joshua Crawford <mor...@ya...> writes: > * Matthias Andree <mat...@gm...> [2006-04-27 15:29 +0200]: >> >> The full diff as committed is attached for your reference. I have bumped >> the version to 0.1+jc2. On further submissions, you can just increment >> the figure after "+jc" (jc3 jc4...) to make clear it's not Richard >> Harris's version any more. > > Will do. > >> + " email - Joshua Crawford <mo...@so...>\n" > > I haven't used that address for a couple of years, and rarely check it since > free POP access was disabled. Please use jgc...@gm..., which should > be good for years to come :-) Euh, my fault. I looked at the signing GnuPG ID instead, rather than the From: line, and mistook the GnuPG ID for the From: line... Sorry! -- Matthias Andree |
|
From: Joshua C. <mor...@ya...> - 2006-04-27 16:44:54
|
* Matthias Andree <mat...@gm...> [2006-04-27 15:29 +0200]: > > The full diff as committed is attached for your reference. I have bumped > the version to 0.1+jc2. On further submissions, you can just increment > the figure after "+jc" (jc3 jc4...) to make clear it's not Richard > Harris's version any more. Will do. > + " email - Joshua Crawford <mo...@so...>\n" I haven't used that address for a couple of years, and rarely check it since free POP access was disabled. Please use jgc...@gm..., which should be good for years to come :-) -- Joshua 'bruce' Crawford ... http://www.geocities.com/mortarn "Bad officials are elected by good citizens who do not vote." -- G. J. Nathan |
|
From: Matthias A. <mat...@gm...> - 2006-04-27 15:29:18
|
Joshua Crawford <mor...@ya...> writes:
> Here's a patch to PopDel.py to make it also display the From: address of
> messages on the server.
>
> I've added this because I almost deleted an email from my mother yesterday.
> She'd forwarded me an amusing video file someone had sent to her, and the
> Subject: looked rather like spam ("Fw: COMMUNICATION").
>
> Also, I don't know if it's technically possible to have an email with no
> Subject header, but previously PopDel would have ignored any that didn't,
> causing indexing errors (deleting the wrong mail if it comes after the
> Subject-less one). This patch corrects that also, as a byproduct of how I've
> implemented the other change.
Thank you. I have committed these two changes to SVN (on BRANCH_6-3),
to appear in fetchmail 6.3.5.
| ------------------------------------------------------------------------
| r4810 | m-a | 2006-04-27 13:25:07 +0000 (Thu, 27 Apr 2006) | 1 line
| Changed paths:
| M /branches/BRANCH_6-3/contrib/PopDel.py
|
| Mention the latest fix is actually a bugfix.
| ------------------------------------------------------------------------
| r4809 | m-a | 2006-04-27 13:23:23 +0000 (Thu, 27 Apr 2006) | 3 lines
| Changed paths:
| M /branches/BRANCH_6-3/NEWS
| M /branches/BRANCH_6-3/contrib/PopDel.manual
| M /branches/BRANCH_6-3/contrib/PopDel.py
| M /branches/BRANCH_6-3/contrib/README
|
| PopDel.py was revised by Joshua Crawford to display the From: address and
| list every email, even if it has no Subject: header; and not delete the wrong
| message in the presence of mail without Subject: headers.
| ------------------------------------------------------------------------
The full diff as committed is attached for your reference. I have bumped
the version to 0.1+jc2. On further submissions, you can just increment
the figure after "+jc" (jc3 jc4...) to make clear it's not Richard
Harris's version any more.
Thanks for your contribution!
Kind regards,
--
Matthias Andree
|
|
From: Joshua C. <mor...@ya...> - 2006-04-26 18:47:30
|
Here's a patch to PopDel.py to make it also display the From: address of
messages on the server.
I've added this because I almost deleted an email from my mother yesterday.
She'd forwarded me an amusing video file someone had sent to her, and the
Subject: looked rather like spam ("Fw: COMMUNICATION").
Also, I don't know if it's technically possible to have an email with no
Subject header, but previously PopDel would have ignored any that didn't,
causing indexing errors (deleting the wrong mail if it comes after the
Subject-less one). This patch corrects that also, as a byproduct of how I've
implemented the other change.
--
Joshua 'bruce' Crawford ... http://www.geocities.com/mortarn
Any fool can criticize, condemn, and complain. And most do.
|
|
From: Daniel R. G. <sk...@iS...> - 2006-04-25 06:50:14
|
On Mon, 2006 Apr 24 14:49:19 +0200, Matthias Andree wrote: > > I'll ponder this a bit, and see if "aka" or "via" should be overloaded > or a new option be introduced. I usually prefer separate options because > sooner or later someone will find a use case where overloading a token > restricts flexibility again and the initial enthusiasum for saving yet > another token turns into frustration because existing documentation, > practice and configuration locks the software in to its former way of > overloading the token for quite a while. That sounds suspiciously like wisdom :-) Maybe something like "sslalternate" (or "sslalt"), given that this would essentially simulate an alternate-name on the server certificate. This could more reasonably become a new field in X509_STORE_CTX, which makes the integration cleaner. (I can try my hand at a patch, if you like... any pointers/caveats I should know?) > Currently the expected name is the "via" name if given, otherwise the > poll name. And the proposed new feature/keyword would basically be the reverse of that. Hmm. > > That's what I'm doing for now, but I still get the "CommonName mismatch" > > warnings. (Twice for every connection, in fact.) I want to get rid of > > Which indicates that you are running a version before 6.3.4. This > version fixed this particular issue (well, as long as "sslcertck" isn't > enabled, which would deliberately turn the CN mismatch into a fatal > socket errors anyways). Yes indeed... 6.2.5, as shipped with Debian sarge :> *download* *download* *build* *build* Okay, I have 6.3.4 now. Strike that second warning.... --Daniel -- NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef? EMAIL1 = sk...@is... ## don't smell bad--- (/o|o\) / EMAIL2 = sk...@al... ## it's the people who < (^),> WWW = http://www.******.org/ ## annoy them that do! / \ -- (****** = site not yet online) |
|
From: Matthias A. <mat...@gm...> - 2006-04-24 18:34:41
|
Christian Michallek <chr...@da...> writes: > hi fetchmail team, > > i have a little wish for fetchmail, perhaps theres someday time to > implement this: > it would be very nice to have the fetchids inside a database like mysql > instead a text file. Yes indeed, but it will not be mysql -- too much complexity for too little database. Probably SQLite or QDBM or something like that. > perhaps the configuration too, but having the fetchids inside mysql > would help me alot, because im syncing some big popboxes with > fetchmail, and searching through the textfile is kinda slow sometimes. As is downloading huge UIDL lists every $daemon seconds. > and one time i had the problem that my disk was full, so fetchmail > exited with an empty fetchids file, > resulting in redownloading a huge amount of mail ;) Certainly not a pleasure to experience. Well, you can update to 6.3.X, which will at least keep the old idfile in place, so it'll download just the new messages over and over but not all your messages, to limit damage somewhat. -- Matthias Andree |
|
From: Matthias A. <mat...@gm...> - 2006-04-24 14:49:01
|
"Daniel Richard G." <sk...@iS...> writes: > On Sun, 2006 Apr 23 22:16:07 +0200, Matthias Andree wrote: >> >> Well, fetchmail is in fact talking to mail.mydomain.com, so allowing >> certificates for other domains on the server wouldn't be the right thing >> to do. > > There is no way for mail.mydomain.com to have an SSL certificate with > CN=mail.mydomain.com. Not unless I shell out for a dedicated IP address. > Alternate names are not a solution either, unless one wants to download a > certificate with 100000+ alternates :] Well... > I agree that webhost.com did a lousy job of setting up their SSL mail > services, but given that that's the current, unlikely-to-change-in-the- > near-future reality, the issue becomes fetchmail's flexibility in handling > a less-than-ideal server situation. I'll ponder this a bit, and see if "aka" or "via" should be overloaded or a new option be introduced. I usually prefer separate options because sooner or later someone will find a use case where overloading a token restricts flexibility again and the initial enthusiasum for saving yet another token turns into frustration because existing documentation, practice and configuration locks the software in to its former way of overloading the token for quite a while. Currently the expected name is the "via" name if given, otherwise the poll name. >> You can however obtain the server's certificate fingerprint (run >> fetchmail with -v (in verbose mode)) and then use the sslfingerprint >> option to suppress the warning. Fetchmail will then abort the connection >> if the fingerprint does not match. > > That's what I'm doing for now, but I still get the "CommonName mismatch" > warnings. (Twice for every connection, in fact.) I want to get rid of > those, and I'd still like to be able to do full certificate checking > (modulo the specifically-configured exception for the CN). Which indicates that you are running a version before 6.3.4. This version fixed this particular issue (well, as long as "sslcertck" isn't enabled, which would deliberately turn the CN mismatch into a fatal socket errors anyways). -- Matthias Andree |
|
From: Christian M. <chr...@da...> - 2006-04-24 14:02:47
|
hi fetchmail team, i have a little wish for fetchmail, perhaps theres someday time to implement this: it would be very nice to have the fetchids inside a database like mysql instead a text file. perhaps the configuration too, but having the fetchids inside mysql would help me alot, because im syncing some big popboxes with fetchmail, and searching through the textfile is kinda slow sometimes. and one time i had the problem that my disk was full, so fetchmail exited with an empty fetchids file, resulting in redownloading a huge amount of mail ;) -- Mit freundlichen Grüßen / Best regards Christian Michallek IT Management und Integration DATA CONSULT SYSTEMHAUS GMBH Bahnhofstraße 26 36037 Fulda Tel.: 0661- 9339-481 Fax: 0661- 9337-567 eMail: chr...@da... http://www.data-consult.com |
|
From: Daniel R. G. <sk...@iS...> - 2006-04-23 23:11:26
|
On Sun, 2006 Apr 23 22:16:07 +0200, Matthias Andree wrote: > > Well, fetchmail is in fact talking to mail.mydomain.com, so allowing > certificates for other domains on the server wouldn't be the right thing > to do. There is no way for mail.mydomain.com to have an SSL certificate with CN=mail.mydomain.com. Not unless I shell out for a dedicated IP address. Alternate names are not a solution either, unless one wants to download a certificate with 100000+ alternates :] I agree that webhost.com did a lousy job of setting up their SSL mail services, but given that that's the current, unlikely-to-change-in-the- near-future reality, the issue becomes fetchmail's flexibility in handling a less-than-ideal server situation. > You can however obtain the server's certificate fingerprint (run > fetchmail with -v (in verbose mode)) and then use the sslfingerprint > option to suppress the warning. Fetchmail will then abort the connection > if the fingerprint does not match. That's what I'm doing for now, but I still get the "CommonName mismatch" warnings. (Twice for every connection, in fact.) I want to get rid of those, and I'd still like to be able to do full certificate checking (modulo the specifically-configured exception for the CN). --Daniel -- NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef? EMAIL1 = sk...@is... ## don't smell bad--- (/o|o\) / EMAIL2 = sk...@al... ## it's the people who < (^),> WWW = http://www.******.org/ ## annoy them that do! / \ -- (****** = site not yet online) |
|
From: Matthias A. <mat...@gm...> - 2006-04-23 22:15:45
|
"Daniel Richard G." <sk...@iS...> writes: > I think that there wouldn't even be a need to introduce a new keyword; > this semantic could reasonably be stuffed into "aka". So that, for the > above-described scenario, I could say > > poll mail.mydomain.com aka mail.webhost.com protocol pop3 > username ... password ... ssl fetchall > > and have everything work dandily. Well, fetchmail is in fact talking to mail.mydomain.com, so allowing certificates for other domains on the server wouldn't be the right thing to do. You can however obtain the server's certificate fingerprint (run fetchmail with -v (in verbose mode)) and then use the sslfingerprint option to suppress the warning. Fetchmail will then abort the connection if the fingerprint does not match. -- Matthias Andree |
|
From: Daniel R. G. <sk...@iS...> - 2006-04-23 09:30:24
|
I'm using fetchmail to download mail via SSL-secured POP3 from mail.mydomain.com, a server maintained by webhost.com. This server is not dedicated to my domain; it is an alias for one of a handful of mega-mail servers run by webhost.com. The SSL certificate on mail.mydomain.com (and all the other mail servers) is actually for mail.webhost.com. I can't connect to mail.webhost.com, however, because it is not the same mega-server as the one for my domain; it doesn't recognize my username/password. (I fully concede that webhost.com, to put it mildly, could manage their SSL services better. They've been following this practice for a long time, unfortunately, and it's quite unlikely that they'll go to the trouble of changing it.) It would be very helpful to be able to say, "connect to server A, but for the purposes of SSL, pretend it's called B." Right now, there is no way to specify this. I think that there wouldn't even be a need to introduce a new keyword; this semantic could reasonably be stuffed into "aka". So that, for the above-described scenario, I could say poll mail.mydomain.com aka mail.webhost.com protocol pop3 username ... password ... ssl fetchall and have everything work dandily. I'm not sure about how the implementation would go, however. The CommonName matching takes place in SSL_verify_callback(), which takes an X509_STORE_CTX and two ints as parameters. The arguments for "aka", however, go into a (struct query)->(struct hostdata)->akalist field, and there doesn't seem to be a way to get to that from the callback. Would appreciate any thoughts/insight on this.... --Daniel -- NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef? EMAIL1 = sk...@is... ## don't smell bad--- (/o|o\) / EMAIL2 = sk...@al... ## it's the people who < (^),> WWW = http://www.******.org/ ## annoy them that do! / \ -- (****** = site not yet online) |
|
From: Translation P. R. <tra...@ir...> - 2006-04-22 21:15:27
|
Hello, gentle maintainer. This is a message from the Translation Project robot. A new PO Template file, for programs using the textual domain `fetchmail', has just been made available to language teams for translation, and a copy is available as: > http://www.iro.umontreal.ca/translation/domains/POT/fetchmail-6.3.4.pot The file should soon be made available in mirror sites as: > ftp://ftp.unex.es/pub/gnu-i18n/po/domains/POT/fetchmail-6.3.4.pot > http://translation.sf.net/domains/POT/fetchmail-6.3.4.pot In your releases, this file is usually found as `po/fetchmail.pot'. It is created or updated automatically at `make dist' time, or whenever you run `make update-po' in the `po/' subdirectory. Whenever you have a distribution ready which holds a newer PO Template, please send the URL of this distribution to the address below. The distribution could be a pretest or a snapshot, it does not even have to compile. This is to be used by translators, when they need to get some translation context from your sources. Within the Translation Project, each PO Template file should have different version numbers, but since it is not OK to have two different distributions having same version numbers, this is not a problem in practice. Here is the URL information which has just been provided to translators for your package. Please inform the translation coordinator, at the address given below, if the information does not appear to be adequate or current: > http://home.pages.de/~mandree/fetchmail/fetchmail-6.3.4.tar.bz2 Translated PO files will later be automatically e-mailed to you. Thanks for your collaboration, The Translation Project robot, in the name of your translation coordinator. mailto:tra...@ir... |
|
From: <ad...@be...> - 2006-04-22 01:17:48
|
Bug #7223, was updated on 2006-Apr-21 18:12 Here is a current snapshot of the bug. Project: Community Fetchmail Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: andyt Assigned to : none Summary: Name resolution does not work in 6.3.4 Details: I have just compiled fetchmail-6.3.4, to replace an existing 6.2.5. New fetchmail fails to resolve IP address of the IMAP server I am polling. Replacing server name with IP address in ~/.fetchmailrc restores functionality. So does defining the name in /etc/hosts. Full log from `fetchmail -v -v' is: ----------------------- fetchmail: 6.3.4 querying mail.ual.com. (protocol IMAP) at Fri Apr 21 17:53:59 2006: poll completed fetchmail: Query status=2 (SOCKET) fetchmail: Deleting fetchids file. fetchmail: normal termination, status 2 fetchmail: Deleting fetchids file. ----------------------- I also have the output of strace command (strace -o debug.out ./fetchmail -v) which I can send. Just to prove the point, I tried to compile fetchmail-2.5.5, and it does not have this problem. I could not find any versions in between. System description: Slackware-10.0 # uname -a Linux andyt 2.6.14.2 #1 PREEMPT Mon Nov 21 12:24:46 CST 2005 i686 unknown unknown GNU/Linux # gcc -v Reading specs from /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/specs Configured with: ../gcc-3.3.4/configure --prefix=/usr --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld --verbose --target=i486-slackware-linux --host=i486-slackware-linux Thread model: posix gcc version 3.3.4 # ./fetchmail -V This is fetchmail release 6.3.4+SSL+NLS. Copyright (C) 2002, 2003 Eric S. Raymond Copyright (C) 2004 Matthias Andree, Eric S. Raymond, Rob F. Funk, Graham Wilson Copyright (C) 2005-2006 Matthias Andree, Sunil Shetye 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 andyt 2.6.14.2 #1 PREEMPT Mon Nov 21 12:24:46 CST 2005 i686 unknown unknown GNU/Linux Taking options from command line and /home/andyt/.fetchmailrc Logfile is /home/andyt/.fetchmail.log Idfile is /home/andyt/.fetchids Fetchmail will show progress dots even in logfiles. Fetchmail will forward misaddressed multidrop messages to andyt. Options for retrieving from and...@un...@mail.ual.com.: True name of server is mail.ual.com.. Protocol is IMAP. All available authentication methods will be tried. Server nonresponse timeout is 30 seconds. 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 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) Fetch message size limit is 100 (--fetchsizelimit 100). Do binary search of UIDs during 3 out of 4 polls (--fastuidl 4). Messages will be SMTP-forwarded to: localhost (default) Single-drop mode: 1 local name recognized. No UIDs saved from this host. Thanks, Andy For detailed info, follow this link: http://developer.berlios.de/bugs/?func=detailbug&bug_id=7223&group_id=1824 |
|
From: Translation P. R. <tra...@ir...> - 2006-04-15 07:33:08
|
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file, for programs using the textual domain `fetchmail', has been submitted by the team of translators taking care of the Japanese language. This particular file, along with all other PO files pertaining to the same textual domain, is available as: > http://www.iro.umontreal.ca/translation/maint/fetchmail/ja.po The file should soon be made available in mirror sites as: > ftp://ftp.unex.es/pub/gnu-i18n/po/maint/fetchmail/ja.po > http://translation.sf.net/maint/fetchmail/ja.po This file has already been sent to you separately on 2006-04-15, as a MIME invoice unpacking the file `fetchmail-6.3.4-rc1.ja.po'. The following HTML page should also be updated by tomorrow. > http://www.iro.umontreal.ca/translation/HTML/domain-fetchmail.html Please consider including all PO files, as they stand, in the `po/' subdirectory of your next release of programs using that textual domain, whether it is official or pretest. Whenever you have a distribution ready which holds a newer PO Template, please send the URL of this distribution to the address below. The distribution could be a pretest or a snapshot, it does not even have to compile. This is to be used by translators, when they need to get some translation context from your sources. Within the Translation Project, each PO Template file should have different version numbers, but since it is not OK to have two different distributions using same version numbers, this is not a problem in practice. Contact me if any question arises. Thanks for your collaboration, The Translation Project robot, in the name of your translation coordinator. mailto:tra...@ir... |
|
From: Matthias A. <mat...@gm...> - 2006-04-14 18:52:23
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, I am announcing the release of fetchmail 6.3.4. This new stable version of fetchmail fixes several minor bugs, adds a --pidfile option, a Vietnamese translation and updates other translations. For details, please see below. The software is available from: <http://developer.berlios.de/project/showfiles.php?group_id=1824&release_id=9751> The fetchmail home pages is: <http://www.fetchmail.info/> or <http://fetchmail.berlios.de/> These are the relevant changes in 6.3.4 since 6.3.3; unless otherwise noted, changes to this release were made by Matthias Andree: # DEPRECATED FEATURES AND MAJOR INCOMPATIBLE CHANGE ADVANCE WARNINGS * The MX and host alias DNS lookups that fetchmail performs in multidrop mode are obsolete, deprecated and may be removed from a future fetchmail version. They have never supported IPv6 (including IPv6-mapped IPv4) anyhow. * The monitor and interface options may be removed from a future fetchmail version as they are not sufficiently portable. * POP2 is obsolete. Support for POP2 may be removed from a future fetchmail version. * RPOP is obsolete, support may be removed from a future fetchmail release. * --sslcertck may become a default setting in a future fetchmail version. * The multidrop To/Cc guessing code along with the fragile duplicate suppressor is deprecated and may be removed from a future release. * The --enable-fallback (fall back to MDA if MTA unavailable) may be removed from a future fetchmail release. * The "protocol auto" default inside fetchmail may be removed from a future fetchmail release. Explicit configuration of the protocol is recommended. # KNOWN BUGS AND WORKAROUNDS: (this section floats upwards through the NEWS to be on top of the list) * fetchmail does not handle messages without Message-ID header well (See sourceforge.net bug #780933) * Sun Workshop 6 (SPARC) is known to miscompile the lexer in 64-bit mode. Either compile 32-bit code or use GCC to compile 64-bit fetchmail. Note that fetchmail doesn't take advantage of 64-bit code anyways, so compiling 32-bit SPARC code should be fine. * The code still isn't 100% ISO-C compliant, some configurations attempt to compile files that are empty after preprocessing, which can cause compiler diagnostics and perhaps jam the compilation on strict compilers. # BUG FIXES: * configure: detect res_* functions properly with newer glibc ABIs. Patch by Miloslav Trmac. * tracepolls: add folder information if available. Reported by Terry Brown. * lexer: add %option noyywrap to avoid link errors about missing yywrap(). * a few more type fixes for report/snprintf, patch by Miloslav Trmac. * bouncing: fetchmail would still send "General SMTP/ESMTP error." bounces in spite of "no bouncemail" configuration. * SSL/TLS: if, for a certain server, an sslfingerprint is specified and sslcertck is NOT set, suppress printing SSL certificate mismatch errors. (Reported by Hannes Erven.) * SSL/TLS: always print if the sslfingerprint mismatches, even in silent mode. (This is for consistency with certificate verification errors.) # TRANSLATION UPDATES: * German/de (Matthias Andree), French/fr (Matthias Andree), Spanish/es (Héctor García), Polish/pl (Jakub Bogusz), Japanese/ja (Takeshi Hamasaki) * New Vietnamese/vi translation (Clytie Siddall). * Updated French descriptions for the .spec file (Stéphane Schildknecht, Luc Pionchon, Matthias Andree). # CHANGES: * pidfile: there is a new command-line (--pidfile PATH) and global option for the rcfile (set pidfile [=] "/path/to/pidfile") option to allow overriding the default location of the PID file. Requested by Héctor García, Debian maintainer. * specgen.sh: Converted to UTF-8 to support translated texts better. Regards, - -- Matthias Andree -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFEP9NcvmGDOQUufZURArqIAKC6oo1DQLVwV9Luct07Q1AiCY7SvACg0VPL fErfpBSuF828FlAI8payL+A= =uWqI -----END PGP SIGNATURE----- |
|
From: Translation P. R. <tra...@ir...> - 2006-04-13 15:33:14
|
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file, for programs using the textual domain `fetchmail', has been submitted by the team of translators taking care of the Japanese language. This particular file, along with all other PO files pertaining to the same textual domain, is available as: > http://www.iro.umontreal.ca/translation/maint/fetchmail/ja.po The file should soon be made available in mirror sites as: > ftp://ftp.unex.es/pub/gnu-i18n/po/maint/fetchmail/ja.po > http://translation.sf.net/maint/fetchmail/ja.po This file has already been sent to you separately on 2006-04-13, as a MIME invoice unpacking the file `fetchmail-6.3.4-rc1.ja.po'. The following HTML page should also be updated by tomorrow. > http://www.iro.umontreal.ca/translation/HTML/domain-fetchmail.html Please consider including all PO files, as they stand, in the `po/' subdirectory of your next release of programs using that textual domain, whether it is official or pretest. Whenever you have a distribution ready which holds a newer PO Template, please send the URL of this distribution to the address below. The distribution could be a pretest or a snapshot, it does not even have to compile. This is to be used by translators, when they need to get some translation context from your sources. Within the Translation Project, each PO Template file should have different version numbers, but since it is not OK to have two different distributions using same version numbers, this is not a problem in practice. Contact me if any question arises. Thanks for your collaboration, The Translation Project robot, in the name of your translation coordinator. mailto:tra...@ir... |
|
From: Matthias A. <mat...@gm...> - 2006-04-10 23:37:18
|
Translation Project Robot <tra...@ir...> writes: > Hello, gentle maintainer. This is a message from the Translation > Project robot. > > A revised PO file, for programs using the textual domain `fetchmail', > has been submitted by the team of translators taking care of the > Vietnamese language. [...] Great! I'd held back the 6.3.4 release to wait for translation updates, to give translators time to catch up (Danish, Greek, Turkish anyone?) after the previous version didn't get any updates, and now a Vietnamese translation arrived. Gorgeous! THANK YOU! (The Vietnamese translation is in SVN and will ship with 6.3.4.) -- Matthias Andree |
147 messages has been excluded from this view by a project administrator.
