Re: crm114 and procmail: eating mails

"Ger Hobbelt" <[email protected]> writes:

> 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/
>>  >> ### <-
> [...]
>>  > 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.

The following [1] says it's the size of the message in bytes.

>>  # 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:)

Zip boum. That's not the case. Even if everybody can read / write the
file and the folder in wich is the file.

> 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.

All is fine regarding the available free space. 7 gigabytes should be
okay :)

> 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.

As said above, the file is readable / writable for everybody as the
folder in wich it is. It exists. It does not contains any byte.

> 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:
>
> [...]
>
> 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!)

Thanks for the tip but don't worry for that, I'm a backup fanatic :)

> 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.

With these lines in my .procmailrc, the test mail is well copied in
the /usr/share/crm114/blubber.txt file and delivered into the mailbox.

Other point: my setup crap is on a 64 bit architecture. Could it be a
problem?

Thanks for everything and best regards,
-AJ

[1] http://partmaps.org/era/procmail/mini-faq.html#log-entries

-------------------------------------------------------------------------
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