Menu
▾
▴
fetchmail-devel
|
From: Matthias A. <mat...@gm...> - 2010-02-24 02:35:45
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, I am asking interested fetchmail users to test a BETA release of fetchmail. This beta1 has the long-desired feature to ignore bad headers in messages and pass them on. Note that this features is OFF BY DEFAULT and YOU need to turn it on explicitly by command line or rcfile. The beta software is available from: <http://home.pages.de/~mandree/fetchmail/> These are the relevant changes since the previous release. Unless otherwise noted, changes to this release were made by Matthias Andree: # FEATURE * Fetchmail now supports a bad-header command line or rcfile option that takes exactly one argument, pass or reject (default). If set to pass, fetchmail will pass messages with bad headers on. This has been rejected for a long time, and the right behaviour was disputed for too long. # CHANGES * The repository has been converted and moved from the Subversion (SVN) format kindly hosted by Graham Wilson over the past years to Git format hosted on Gitorious.org. My deepest thanks to Graham Wilson for this service that kept us going when BerliOS's Subversion service was faulty in its early days. * This opportunity was used to convert BRANCH_6-2 and BRANCH_1-9-9 to GnuPG-signed tags, as a sign that these are now closed. * The outdated SVN trunk is now called "oldtrunk" in Git just to save the work for future reference. All development in the past few years was on BRANCH_6-3. * master was branched from BRANCH_6-3 for user convenience. # DOCUMENTATION * Web site and documentation were adjusted to reflect the SVN->Git move. * The fetchmail manual page is now much clearer on the user id switching (seteuid) when using --mda while running as the super user. - -- Matthias Andree -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkuEgMoACgkQvmGDOQUufZV3mQCgtp8ccaUDTU7zhmL4CNilZzQZ uqAAnRraStvFdKswS8s1KFMyEi2w4wNy =neOa -----END PGP SIGNATURE----- |
|
From: Frédéric M. <fre...@wo...> - 2010-02-24 13:09:14
|
On Wednesday 24 February 2010, Matthias Andree wrote: > Greetings, > > I am asking interested fetchmail users to test a BETA release of > fetchmail. This beta1 has the long-desired feature to ignore bad > headers in messages and pass them on. Note that this features is OFF BY > DEFAULT and YOU need to turn it on explicitly by command line or rcfile. > > The beta software is available from: > <http://home.pages.de/~mandree/fetchmail/> Two really minor observations so far. The localdomains option cannot be shortened as local as specified in the man page (that may not be new, I'm coming from 6.3.9). If bad-headers pass is set after a user option, fetchmail complains with "server option after user options at pass". That's a little bit confusing if password is shortened as pass too. Frederic |
|
From: Matthias A. <mat...@gm...> - 2010-02-24 23:36:20
|
Am 24.02.2010 13:08, schrieb Frédéric Marchal: > On Wednesday 24 February 2010, Matthias Andree wrote: >> Greetings, >> >> I am asking interested fetchmail users to test a BETA release of >> fetchmail. This beta1 has the long-desired feature to ignore bad >> headers in messages and pass them on. Note that this features is OFF BY >> DEFAULT and YOU need to turn it on explicitly by command line or rcfile. >> >> The beta software is available from: >> <http://home.pages.de/~mandree/fetchmail/> > > Two really minor observations so far. > > The localdomains option cannot be shortened as local as specified in the man > page (that may not be new, I'm coming from 6.3.9). That's a good catch. The abbreviated form has never worked - according to "git annotate", it was already broken when it was added by ESR on 1997-01-09, however the fix is simple: change "local(domains)" in rcfile_l.l to "local(domains)?" and recompile. You need flex installed. > If bad-headers pass is set after a user option, fetchmail complains > with "server option after user options at pass". That's a little bit > confusing if password is shortened as pass too. Also a good catch. I'll change this to accept. The current lexer/parser wouldn't have treated this properly in all circumstances anyways because "pass" can't be mapped to two tokens internally. I think there will be another beta release or release candidate before 6.3.15... Thanks for your tests and updating the French translation! The changes have been committed and pushed to Git. (I have received, but not yet committed, the Czech and Italian translation updates.) Happy fetching, -- Matthias Andree |
|
From: grarpamp <gra...@gm...> - 2010-02-25 07:02:26
|
>>> fetchmail. This beta1 has the long-desired feature to ignore bad >>> headers in messages and pass them on. Hi group. What are 'bad headers'? Certainly would not all inbound headers be passed through fetchmail to disk or pipe, etc? Thx. |
|
From: Frédéric M. <fre...@wo...> - 2010-02-25 08:35:36
|
On Thursday 25 February 2010, grarpamp wrote: > >>> fetchmail. This beta1 has the long-desired feature to ignore bad > >>> headers in messages and pass them on. > > Hi group. > What are 'bad headers'? > Certainly would not all inbound headers be passed through fetchmail > to disk or pipe, etc? The purpose of this option is to ignore the invalid header lines if the server on which we are fetching the mail accepted (or even produced) that mail in the first place. If the mail can be delivered properly, everybody will be happy. If it can't, let's the blame fall on the software that can't handle it properly :-). For instance, a mail header containing a very long line, was wrapped improperly by a previous version of my mail server. That is, the continuation line didn't start with a space. That invalid continuation line was then seen as an invalid mail header and fetchmail used to reject the whole mail as invalid. The mail was therefore undeliverable even though any other link in the mail delivery chain would have ignored that header just fine and passed the mail along. Returning it to the sender was dangerous (as the source address might have been forged) so the mail was stuck on the server. With the new option, you can choose to reject any such mail as it used to be and avoid any trouble with the MDA/MTA to which fetchmail is passing the mail. On the other hand, if you know the mail will be delivered without any problem, you can let it go and avoid to loose any mail. Frederic |
|
From: Matthias A. <mat...@gm...> - 2010-02-25 09:18:40
|
Am 25.02.2010 07:02, schrieb grarpamp: >>>> fetchmail. This beta1 has the long-desired feature to ignore bad >>>> headers in messages and pass them on. > > Hi group. > What are 'bad headers'? Those which (1) are not continuations of the previous line, i. e. do not start with linear white space, and (2) which do not follow the usual header name plus colon (:) syntax. Fetchmail traditionally refused to deliver such messages, now you get the option to attempt delivery. Some distributors have already been patching fetchmail to do that. Such patches will be obsolete then (although I expect those distributors will patch the default to accept such messages). > Certainly would not all inbound headers be passed through fetchmail > to disk or pipe, etc? Yes of course they would, with additional Received: headers to trace that fetchmail was in the path (unless you set it to invisible mode, which I discourage). HTH -- Matthias Andree |
|
From: grarpamp <gra...@gm...> - 2010-02-25 17:41:15
|
Ok. Thank you two for the definition and explanation. As my current use is only to fetch to disk [Maildir of course with procmail, perhaps maildrop? in the future] for use with mutt, and even though I may mutt-reply from time to time from the Maildir, I think receipt of such bad messages is what I want, rather than miss one. I can always edit the bad messages in the Maildir. I did not know fetchmail would not receive messages/headers the server thought were valid. Thanks for this new feature :) PS: I use of invisible mode for years, sometimes I forward things and in general prefer headers to be pristine as if they never passed through some middle parts of my systems. |
|
From: Matthias A. <mat...@gm...> - 2010-02-25 20:37:08
|
Am 25.02.2010 17:41, schrieb grarpamp: > Ok. Thank you two for the definition and explanation. > As my current use is only to fetch to disk [Maildir of course with procmail, > perhaps maildrop? in the future] Maildrop is definitely recommended. Procmail has been unmaintained since 2001 and is very hard to configure in a way such that it behaves predictably. > for use with mutt, and even though I > may mutt-reply from time to time from the Maildir, I think receipt of such > bad messages is what I want, rather than miss one. I can always edit the > bad messages in the Maildir. I did not know fetchmail would not > receive messages/headers the server thought were valid. Thanks for > this new feature :) > > PS: I use of invisible mode for years, sometimes I forward things > and in general prefer headers to be pristine as if they never passed > through some middle parts of my systems. Forwarding anything beyond the usually displayed From/To/Cc/Date/Subject headers is somewhat dangerous to privacy, and "invisible" mode doesn't change those. :) -- Matthias Andree |
|
From: Frédéric M. <fre...@wo...> - 2010-02-25 08:15:42
|
On Wednesday 24 February 2010, Matthias Andree wrote: > Am 24.02.2010 13:08, schrieb Frédéric Marchal: > > The localdomains option cannot be shortened as local as specified in the > > man page (that may not be new, I'm coming from 6.3.9). > > That's a good catch. The abbreviated form has never worked - according to > "git annotate", it was already broken when it was added by ESR on > 1997-01-09, however the fix is simple: change "local(domains)" in > rcfile_l.l to "local(domains)?" and recompile. You need flex installed. I was using the short form with fetchmail 6.3.9. So, it was either not complaining about the invalid option or it was working. I tend to believe it is the latter as our mails were processed as expected and we had problems before that option was added. On the other hand, I don' t see any change in the source code between versions 6.3.8 and 6.3.15 that could explain why the option ceased to work or why it would start complaining... Frederic |
|
From: Matthias A. <mat...@gm...> - 2010-02-25 09:33:18
|
Am 25.02.2010 08:14, schrieb Frédéric Marchal: > On Wednesday 24 February 2010, Matthias Andree wrote: >> Am 24.02.2010 13:08, schrieb Frédéric Marchal: >> > The localdomains option cannot be shortened as local as specified in the >> > man page (that may not be new, I'm coming from 6.3.9). >> >> That's a good catch. The abbreviated form has never worked - according to >> "git annotate", it was already broken when it was added by ESR on >> 1997-01-09, however the fix is simple: change "local(domains)" in >> rcfile_l.l to "local(domains)?" and recompile. You need flex installed. > > I was using the short form with fetchmail 6.3.9. So, it was either not > complaining about the invalid option or it was working. I tend to believe it > is the latter as our mails were processed as expected and we had problems > before that option was added. I think the parser misunderstood your rcfile, so it wouldn't complain. If there was another list (such as aka) prior to the local option, that list would have had two more tokens, namely the word "local" and the domain -- and that may have been sufficient to set delivery apparently straight (while fetchmail would have mapped multidrop users, which localdomains is actually supposed to suppress). > On the other hand, I don' t see any change in the source code between versions > 6.3.8 and 6.3.15 that could explain why the option ceased to work or why it > would start complaining... And I don't see how it could have worked as advertised. The lexer used to emits a LOCALDOMAINS token only on "localdomains", but not on "local". I guess it would have returned local as a STRING, and then the domain also as a STRING. HTH -- Matthias Andree |
|
From: Frédéric M. <fre...@wo...> - 2010-02-25 09:53:10
|
On Thursday 25 February 2010, Matthias Andree wrote: > Am 25.02.2010 08:14, schrieb Frédéric Marchal: > > On Wednesday 24 February 2010, Matthias Andree wrote: > >> Am 24.02.2010 13:08, schrieb Frédéric Marchal: > >> > The localdomains option cannot be shortened as local as specified in > >> > the man page (that may not be new, I'm coming from 6.3.9). > >> > >> That's a good catch. The abbreviated form has never worked - according > >> to "git annotate", it was already broken when it was added by ESR on > >> 1997-01-09, however the fix is simple: change "local(domains)" in > >> rcfile_l.l to "local(domains)?" and recompile. You need flex installed. > > > > I was using the short form with fetchmail 6.3.9. So, it was either not > > complaining about the invalid option or it was working. I tend to believe > > it is the latter as our mails were processed as expected and we had > > problems before that option was added. > > I think the parser misunderstood your rcfile, so it wouldn't complain. It's my fault. Sorry. Now, I'm sure the short form never worked before. I looked at the backup of the config file and found that it was actually using localdomains. Not the short form. I must have truncated it while modifying the poll entry to split it over multiple lines and forgot about it. Frederic |
|
From: Matthias A. <mat...@gm...> - 2010-02-25 20:44:50
|
Am 25.02.2010 09:52, schrieb Frédéric Marchal: >> I think the parser misunderstood your rcfile, so it wouldn't complain. > > It's my fault. Sorry. Now, I'm sure the short form never worked before. Nevermind. At least you found one of the longest-standing bugs I'd say. :) (Fetchmail should really have insisted on quotes around strings, then it would have been obvious.) -- Matthias Andree |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X