Hi, Thanks Charles for including the error message patch of paul+osamu.
On Sat, Jul 16, 2011 at 11:39:38AM -0600, Charles Cazabon wrote: > Osamu Aoki <[email protected]> wrote: > > > > Is this still a valid bug for latest version? > > > > Since I will be off-line for a while, I am forwarding this as is. I just came back from my vacation. > > See http://bugs.debian.org/633735 for example mbox and follow-up > > messages. > > Okay. So the actual problem here is that the original message contains the > invalid content, and getmail's straight-paper-path tried very hard to preserve > the original content as-is (i.e. don't rewrite messages Just Because). I'm > ambivalent about fixing this - I don't particularly like trying to fix other > software's bugs by changing getmail, but the user doesn't have much choice. Lauri Alanko acknowledges that he had an IMAP problem for his environment in another bug report. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633780 If this is a typical problem which user may face, offering an option to fix other software's bugs may be an reasonable idea just in case he has no control to IMAP server but it should be default-off feature. > I'll release a new version with a change to fix this. I'd appreciate it if > people could report if this causes other problems, as it means getmail will be > reformatting/rewriting message bodies in a way that previous versions have > tried to avoid. It may become a messy path. I am a bit nervous... I also see another bug report of him to Debian which he claims to fix issues related to the Mboxrd format. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633799 This comes with content modifying patch, too. Lauri, If you want your patch reported in bug#633799 to be applied to getmail, please contact the upstream on the mailing list at [email protected] and convince people what you are proposing is the right thing. I being just one of the maintainer of Debian package will not change software in the way upstream does not support. My change will be mostly Debian specific features and minor cosmetic issues which I can take some responsibility in the future. Quite frankly, I am not so much fan of making software too complicated to address other softwares' problems. Usually, for the special case handling, it is best to provide a generic interface with user pluggable filter modules or so. So the core software stays simple and optional features are available only to who need them. Please read http://pyropus.ca/software/getmail/ especially under http://pyropus.ca/software/getmail/documentation.html#mailing-list-users to understand recent discussion. Osamu -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
