snow leopard to Yosemite upgrade, part trois: procmail bug problem

Sincerely hoping this is the last part. In part deux we figured out question #4 from my list in part 1. So now on to questions #3 and #1, as I hope #2 will take care of itself.

Actually I'm pretty sure that if I fix #3, then #2 will be fine. Why? Because it's true for the lovely Carol; her .procmailrc isn't problematic, and her email went fine into Maildir/new ⇒ Maildir/cur.

Yes! I've got to take my encouragement when I can.

Anyway, to debug #3, I tried this:

mini1:~ collin$ cat Mail/backup/92784 | strace procmail
-bash: strace: command not found
mini1:~ collin$ 

Dang. There is no strace, but there is a truss, dtruss actually, on Mac OS X. It requires root privileges. So I became root and ran procmail on a minimal .procmailrc which nonetheless has a line like

FROM=`sed 1d | formail -I reply-to: -I resent-from: -I return-path: | \
        formail -rzxTo:`

Sure enough, the dtruss output convinced me that this particular feature is b0rken in the current procmail.

Fortunately, that's the only place I use that in .procmailrc, and it's not actually needed. So I said…

mini1:~ collin$ cat Mail/backup/92708 | procmail
mini1:~ collin$ 

and clicked "Get mail" on thunderbird. It asked for my password, and there my mail was.

So there's something rotten in the Yosemite version of procmail 3.22. That was with /usr/bin/procmail, and I wondered if the mac port version would have a similar issue. Yes :(.

mini1:~ collin$ cat Mail/backup/92862 | formail -imessage-id: | /opt/local/bin/procmail .procmailrc.1.18
Abort trap: 6
mini1:~ collin$ 

Guess I'd better file a ticket.
Done: https://trac.macports.org/ticket/46623

---

Now for question #1: the issue may have been as simple as needing to add a component to $PATH, as:

mini1:~ postman$ grep PATH tunnel.sh
PATH=$PATH:/usr/sbin:/usr/local/bin
mini1:~ postman$ 

Formerly, fetchmail was in some common place like /usr/bin but I had to install it myself, which I did Sunday. So now it's in /usr/local/bin/fetchmail—which probably wasn't in root’s path and hence might not be in $PATH at all given that the script is invoked by root from launchctl.

But I think everything works now. Whew!