Re: crm114 and procmail: eating mails

On Tue, Apr 22, 2008 at 9:23 PM, Antoine Junod <[email protected]> wrote:
>  >> ### ->
>  >> :0fw: .lockmsg
>  >> | /usr/bin/crm114 -u /usr/share/crm114/ --fileprefix /usr/share/crm114/ mailfilter.crm
>  >>
>  >> :0
>  >> /var/vpopmail/domains/my.domain.com/tickets/.maildir/
>  >> ### <-
[...]
>  Below are the relevant parts of mailfilter.cf (all but the
>  comments). The only thing I've changed is the password. And I've
>  checked the availability of the mime decoder and the cache dupe
>  command.
[...]
>  > Also, run procmail with VERBOSE=yes and catch the whole log for a test run
>  > with crm recipe active.
[...]
>  procmail: Assigning "LASTFOLDER=/var/vpopmail/domains/vecchio.shockfish.com/tickets/.maildir/new/1208892095.397_1.vecchio"
>   Folder: /var/vpopmail/domains/vecchio.shockfish.com/tickets/.maildir        0

I don't know procmail so I don't know when it says 'Folder: yadayada
N' where N=0 or other value; might be useful to check up on that in
the manual or elsewhere.

>  # Mailfilter.cf
>  :log_to_allmail.txt:  /yes/

The line above means that each of those munched emails that passed
through the crm114 filter (yeah, I checked up on the procmail manual
to decode that recipe stuff, didn't find info on that 'Folder: ...
logline though...) must also show up in the file (mailfilter.crm
snippet follows ~ line 210:)

#      Does the user want us to log all incoming mail?  This is handy for
#      testing and auditing purposes.
{
        match [:log_to_allmail.txt:] /yes/
        output [:*:fileprefix:allmail.txt] <append> /:*:_dw:/
}

i.e. each email should be appended to the file (in your case):

  /usr/share/crm114/allmail.txt

Given the fact that this is an evergrowing file, the first thing to
check is make sure the /usr/share/crm114 partition (or at least the
partition it is residing on) has enough disc space to store another
bunch of 'em. UNIX 'df' to the rescue.

Next on the list is making sure it exists and if the procmail user is
allowed in there. (I heard you said something about chmod 0777? Might
be enough to tick that one off as well, but better see if the
allmail.txt file exists at all and/or is growing when fed extra
emails.


The point is that if it doesn't exist (yikes) or doesn't grow (ouch),
that either

a) crm114 never gets the email properly fed in the first place, or
b) crm114 can for some unfathomable reason not execute the script, at
least not up to line ~ 210 where that log statement resides.

On the other hand, if allmail.txt grows with every email tested, that
means we have to look at the second part of the crm114 script AND the
reception of the crm114 produced output by procmail as it acts as
piped filter there if I read the 'procmail recipe' docu correctly.


And because you just might not want to loose your email during this
ordeal, here's an important snip from a googled spamassassin procmail
recipe that applies here too:

****************************************************
Danger! Achtung! Aviso!

If you are unsure about changes you make to your recipes, always put
in a safety net at the top of your (first) recipe file:

    :0c:
    /var/mail/backup

This will put copies of all mail in ~/var/mail/backup. You may wish to
read the procmailex(5) manpage which gives an example of how to keep
only the last 32 (or whatever you specify) messages.

Careless procmail rules with no safety net (e.g., /dev/null has no
safety net) may result in lost email messages!

I am not responsible for lost or damaged mail. If you doubt the safety
of these procmail recipes, do not use them.
****************************************************

so yours might become

:0cfw: lockfile

for the time being, then. Just a safety measure for now... ('Backup?
Backup you say?! But /that/ wasn't in the package when /I/ got it!)



>  :undo_interruptus: /no/

[EXTREMELY off-topic] Paolo, did you notice that ':humhumhum.txt:'
logging variable up there? The exception to your assumption that
nobody would ever use dotted vars, when discussing the class-like
classifier output suggestion for easier pR-scripting. Well, Bill does
use them ;-) Though only once in his life as far as I can tell. :-))
[/EXTREMELY off-topic]


-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt


PS: when in doubt over everything, try this to see if the procmail
pipe-filter thingy works as advertised:

:0cfw:
| tee /usr/share/crm114/blubber.txt

:0
/your-var-mail-dump-dir-etc

which should copy your test email to the file
/usr/share/crm114/blubber.txt and otherwise work as expected, i.e. not
drop the email on the way out to the subsequent :0 mail-dump-dir
action block.
Why do this? If 'tee' works well, it's 'probable cause' for crm114 +
mailfilter.crm, while when ti /doesn't/, it's time to put procmail on
the spiked bench.


Just cutting up the probable area of jeopardy here. Hope it helps.


--------------------------------------------------
web: http://www.hobbelt.com/
 http://www.hebbut.net/
mail: [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone