Re: [fetchmail-devel] Re: [fetchmail-users] Incorrect header line and lost mails

[Frederic M. <fre...@wo...>]

Matthias Andree wrote:
> Frederic Marchal <fre...@wo...> writes:
>
>   
>> Well, I'm a C programmer and I may be able to help but I'm mainly a
>> windows programmer (yes, I know, shame on me :-) ) and I'm not yet all
>> too familiar with the Linux programming and especially with the patch
>> mechanism and none at all with the diff tool.
>>     
>
> The workflow is:
>
> 1. create a copy of all files you need to edit, for instance, 
>    copy foo.c to foo.c.orig
>
>    alternatively, copy the whole directory tree recursively
>
> 2. edit until you're happy with the code
>
> 3. test the edits (compile, install, run)
>
> 4. generate a unified (preferred) or context patch.  Not all diff
>    utilities support unified output, but all are to support context
>    format, as mandated by the relevant standard, IEEE Std 1003.1-2001.
>
>    Plain ed-style patches (unfortunately still the default in the diff
>    utility) are impractical so they are not usually accepted.
>
> The diff tool is quite simple actually, if you created file copies:
>
> diff -u OLDFILE NEWFILE >PATCHFILE (unified diff, preferred)
>
> diff -c OLDFILE NEWFILE >PATCHFILE (context diff, alternative)
>
> If you copied the whole directory before the edits:
>
> diff -u -r BACKUP_DIR EDITED_DIR >PATCHFILE    (or -c instead of -u)
>
> If you added new files to EDITED_DIR, you'd use -N but I don't think
> we'll need this here.
>
> diff, used either way, will produce a file (PATCHFILE) that you'd attach
> to a message and mail to me (or Rob, or preferably the -devel@ list) or
> upload to the BerliOS patch tracker.
>
> If I have the choice, I prefer the -devel@ list. That's public, archived
> and easiest for me since I don't need to fetch anything, but get it
> pushed into my inbox.
>
>
> The patch utility does the reverse and will usually just be used like
> this, it derives the file names from the PATCHFILE.
>
> patch <PATCHFILE
>
> perhaps with -d (to change directory) or -p (to strip leading path
> components from the paths shown in the patch file; used if patch cannot
> find the files).
>   
Thank you. It looks easy indeed but you saved me from a lot of 
man/info/howto readings... :-)


>> I'll also need some direction about the proper way of doing it for a
>> good integration in the current source.
>>     
>
> The bigger concern is that fetchmail shouldn't be emitting headers it
> knows are broken, so that the next hop (the MTA or MDA) does not get
> confused. I wonder if fetchmail should prefix the broken lines with
> X-Fetchmail-Escaped-Broken-Header: or something similar.
>   
At first glance it seemed reasonable, but after one day of thinking 
about it, I'm not so sure I understand why fetchmail should even alter 
the original header in any way.

Why is it fetchmail's concern if the next hop gets confused by an 
invalid header that was there in the first place ? Isn't it more useful 
to keep intact all the information from the original e-mail ? After all, 
an invalid header is also a signature for a spam or a virus and it could 
be used by some tool along the delivery chain to filter out the mail. In 
my case, a mail client could also detect the wrapping and restore the 
original header provided fetchmail doesn't mess it up.

Frederic