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

[Matthias A. <mat...@gm...>]

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).

> Nevertheless, I have identified the core of the problem (its the call
> to readheaders in drive.c and the response to PS_REFUSED). I still
> have to check what happens if an invalid FROM or TO header is passed
> after readheaders but I think I can fix the program.

That would be great.

Basically they should not matter that much. fetchmail has some
deprecated code to guess from To:/Cc: or similar, but that is an
unreliable concept and doesn't deserve attention, From: shouldn't matter
as long as Return-Path: is given (and even then, From: shouldn't
matter). Missing or corrupted Return-Path: headers should be treated as
though the message had contained "Return-Path: <>".

> 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.

-- 
Matthias Andree