[fetchmail-devel] [Patch #3116] Allow selection of LAST envelope header

[<ad...@be...>]

Patch #3116 has been updated. 

Project: fetchmail
Category: None
Status: Open
Submitted by: mskala
Assigned to : none
Summary: Allow selection of LAST envelope header

Follow-Ups:

Date: 2011-Jan-08 20:29
By: mskala

Comment:
My ISP unconditionally adds an X-Envelope-To: header at the end of the message header block.  Sometimes a message comes in which already has an X-Envelope-To: header, generally with an address my sendmail will think is non-local and reject; messages that come through the XeTeX development mailing list often fit this description, because for whatever reason they arrive containing their own X-Envelope-To: headers pointing at the list instead of at me.

If I just tell Fetchmail to use X-Envelope-To:, it reads the first one, which is the one added by my ISP in most cases but the one that came in with the message for the few messages that already have them.  When the message comes with an X-Envelope-To header and Fetchmail reads it, it can't deliver the message properly.  Fetchmail would allow me to skip a constant number of headers - so I could tell it to skip 1 and then it would always read the second X-Envelope-To: header - but in that case it would fail on the large majority of messages where my ISP's header is the only one.  What I would really like would be to read the LAST X-Envelope-To: header, regardless of how many (if any) must be skipped to do that.

This patch (against fetchmail-6.3.19) accomplishes that.  If I set the "skip" value to -1, then Fetchmail will use the LAST envelope header, which (in my case) is always the one added by my ISP.  For values of skip other than -1, it preserves the old behaviour.  Since -1 was formerly an invalid setting for skip (though not tested for), it shouldn't disturb existing correct behaviour.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://developer.berlios.de/patch/?func=detailpatch&patch_id=3116&group_id=1824