procmail
[Top] [All Lists]

Re: Whose responsibility is the blank line?

2004-02-12 16:27:33
At 15:23 2004-02-12 -0600, Skip Montanaro wrote:
Until today, all these failures had turned up in spam mailboxes (I run
SpamBayes' sb_filter.py script from my procmailrc file to score incoming
mail)

I'm guessing THAT program is what emits to the mailbox in question. THAT program needs to ensure there's a TRAILING newline when it writes messages.

 so I wasn't all that concerned that I might miss a spam.  I'd just add
a blank line in a text editor.  Today, chkmail alerted me to a missing blank
line in my main mbox, which is filled from my last procmailrc rule:

    # everything else falls through to here.
    :0
    mbox

Danger Will Robinson!

Skip didn't use a LOCKFILE flag on this recipe.

I see nothing in my procmail logfile which would suggest a failure.  In
fact, no new output has found its way to that file in a couple weeks.  The
last one was a Python traceback.

Uhm, I'm guessing something WRITTEN to the file BY a python script?

I have a fairly long procmailrc file, but it's also pretty straightforward.

If some process OTHER than procmail is writing to the mailbox files, you should ensure that the other process does locking, AND that it *ENDS* the output with an extra blank line.

It would seem this sort of problem has to be due to some sort of locking
failure between multiple procmail instances.

Not 'zactly possible in your case - you're not USING locking in your recipe, which itself is a problem, but should only be a real issue when you have multiple processes writing to the one mailbox at the same time.

Is procmail supposed to insure there's a blank line after every message it adds to a mailbox or is the mail supposed to end with "\n\n" when procmail gets it? I'd welcome any clues to its cause.

* The FIRST message doesn't have a blank line before the From_ header.

* Procmail ADDS a blank line following messages when it adds them to a *nix mbx file, regardless of whether it it the first or nth message.

* if the EXISTING file (say, written to by another app) doesn't have a trailing blank line, then when procmail adds a message, that message will not have a blank line between the previous message and the newly added one, because procmail doesn't _READ_ the mailbox or parse it in any way - it is merely appending material onto the end.

With a couple of edited message files, you could easily confirm what procmail does from within a sandbox.

Addendum: This morning I found a missing blank line between messages in two
mailboxes.  The interesting thing is the first message in both cases is the
same message.  (The same message being in two mailboxes is by design.)  That
would suggest that procmail does nothing to insure that there is a blank
line after each message.  Is that the case?  Is there a way to get it to
enforce that requirement?

What else are you using to manipulate these mailboxes? Perhaps a crummy MUA, or writing messages to it from some other program?


I am aware of one situation where procmail's "extra blank line" doesn't work properly - when the input message lacks a terminating newline, and thus, adding an extra newline (which procmail will do), only succeeds in adding the newline which SHOULD have been there on the original input message:

[LF] is a linefeed
[EOF] is the EOF marker (not a character)

Typical message:

This is the last line[LF][EOF]

which procmail would write to the mbx as:

This is the last line[LF][LF][EOF]

A problem message would be:

This is the last line[EOF]

Which procmail would write out to the mbx as:

This is the last line[LF][EOF]

... which lacks a trailing BLANK line.

Such messages are themselves rather nonstandard, though it wouldn't hurt if procmail recognized them and compensated.


I rather doubt this is the problem you're encountering.

---
 Sean B. Straw / Professional Software Engineering

 Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.


_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>