On Thu, 3 May 2007 07:49:00 +0200, Paolo wrote:
> On Thu, Apr 19, 2007 at 05:46:55PM +0200, wrote:
> > > but it's not what it really does, nor it is what RFC 2822 calls
> > > "unfolding". Quote:
> >
> > right, both procmail and formail do the wrong thing here - thanks for
> ...
> > > Converting a newline into a white space does not really concatenate
> > > fields, as it adds an extra space.
>
> well, seems it's a known bug: man procmail:
>
> ...
> The embedded newlines in a continued header should be skipped when
> matching instead of being treated as a single space as they are now.
> ...
>
> so upstream is aware of it; I guess s/\n/ / was just easier than RFC ;)
Yuck. This breaks the deduplication of formail -D (I'm guessing it's
code shared between both formail and procmail):
#avoid duplicated messages
# (if testing, don't do duplicate test)
:0 Whc: msgid.lock
* $ ${TESTMAIL+!}
| formail -D 16384 .msgid.cache
When I get a message via two different systems, which break a long message
id differently:
Message-ID:
<f6b9883a73ac594592041e20c59a484601c3b5ebb...@bom-vmbx-ho.bom.gov.au>
Message-ID:
<f6b9883a73ac594592041e20c59a484601c3b5ebb...@bom-vmbx-ho.bom.gov.au>
I end up with these two entries in formail, and they aren't deduplicated:
<f6b9883a73ac594592041e20c59a484601c3b5ebb...@bom-vmbx-ho.bom.gov.au>
<f6b9883a73ac594592041e20c59a484601c3b5ebb...@bom-vmbx-ho.bom.gov.au>
Maintainer:
Could you kindly forward this bug upstream? I know procmail is ... very
mature (this bug was first mentioned on the mailing list in 2000, applying
to a 1994 version of the code):
http://www.mhonarc.org/archive/html/procmail/2000-05/msg00185.html
--
Tim Connors
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
