On the subject of getting timestamp informtion from the From_ line instead
of running date, Rik Kabel listed some problems that arise when the end
recipient is in a different timezone from the ISP where the From_ line is
timestamped and procmail is invoked.
| You _can_ handle these completely within procmail. The complexity of
| doing so convinced me that setting TZ and invoking date is worth the
| cost in hair loss. My current setup does this once, pulling in the date
| and time for later parsing and manipulation within procmail.
When I had an account on Netcom, whose timestamp is two hours earlier than my
local time, I settled for having my procmail days run from 2 AM to 2 AM my
time; I considered that less trouble than running date. Heck, most people
who are awake between midnight and 2 AM consider it part of the previous day
anyway. Rik is clearly in a position where that isn't good enough.
| Of course, if someone has an rc to handle these problems as well, I
| would be happy to learn from it. Also, if there is a way to have my
| ISPs sendmail insert datestamps from my timezone, I would appreciate
| learning how to do it.
If one is running procmail on one's local machine rather than at the ISP,
the local machine should be updating the From_ timestamp anyway (or the local
invocation of procmail can do it with -f-), so I'm going to take it that Rik
is running procmail on his ISP's hardware, not his own.
If one is calling procmail from ~/.forward at your ISP, this might work:
"| ... TZ=whatever /path/to/procmail -f- ..."
I found that putting TZ=new_setting into procmail's arguments didn't work;
procmail appears to do "-f-" before considering any new value to TZ set
among its arguments (where usually, with procmail, one can put variable
assignments).
If the ISP is running procmail as the MDA, though, and one is doing all mail
throwing there, then I guess that the only alternative to forking a program
for every incoming message (either date to get the current time or procmail
or formail to update the From_ line) is to live with the ISP's timezone
setting.