[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Content-Length header (Was: Some myths regarding apt pinning)



>>>>> "Bob" == Bob Proulx <bob@proulx.com> writes:

    Bob> And added by any delivery agent delivering mail to an old style
    Bob> mail file.  It is not just procmail.  It is required.

I know.  But then, there is no "standard" anyway, so that can't be said to
be "required".  For me as long as my tools happily read them it's okay.

    Bob> IIRC in the www.mutt.org docs there are references to that.  Also
    Bob> more references as to why you should not do that.

Thanks, although I can't find it.

    Bob> Here is one classic treatise on the subject.  Read this before
    Bob> trying what you suggest.

    Bob> http://www.jwz.org/doc/content-length.html

I know the problem it describes, even when I first read the man page of
procmail.  I know perfectly that content-length will have problem of jamming
up the mail box.  But that's not my problem.  I use it only as a temporary
mail storage.  Emacs which we read my inbox and split it up to many groups.
Each mail is stored in its own file (I use nnml), so all the critics don't
make sense to me.  It just feels stupid that at the end each mail is stored
in a single file, but still the "From " headers are escaped because it
"transits" in a V7 format mail box.  And the damage is permanent: you never
know whether a ">From " line is due to a "From " line or due to a real
">From " line.  (Why they didn't use a less brain-dead escape format?!  If
you just turn all leading "F" to "FF" it will be perfectly reversible...)
And the problem is there even for Quoted printable files.  E.g., shell
scripts, postscript files, etc., are affected.  Yes, very low probability,
but I just want to know whether there is a way to avoid it.

    Bob> Your better option would be to convert to Maildir format mailbox.
    Bob> Those do not need to escape From markers.  Here is a useful
    Bob> reference for this.

    Bob> http://www.nb.net/~lbudney/linux/software/safecat.html

The only real problem is that the mail will actually be stored *first* in a
V7 mailbox by procmail or sendmail or exim or whatever, when the damage is
done.  Later when you try to split it into many files, you can't undo the
damage.

Anyway, thanks very much for your response.

Regards,
Isaac.



Reply to: