At 11:10 2003-12-10 -0600, Chuck Campbell wrote:
> When we went through this last summer the consensus was to use the
> FROM_ header for the date/time stamp.
Do you mean a header that is named FROM_ in my mail, or a procmail macro
named FROM_ ?
Well, seeing as a check of the documentation would reveal that there is no
procmail macro "FROM_" (or variable for that matter), I'd have to say the
former seems like a rather logical conclusion.
From_ is the standard way the procmail regulars refer to the
mbox-separating From line which doesn't have a colon after the "From",
since just referring to the "From" line is prone to interpretation -- is it
the From: field, or the From(with_a_space) ?
That header contains the envelope sender and the date the message was
received at the present host. That date information is used by some people
to validate "stale" messages - checking the Date: header against the date
the message was received to determine if the message appears to have been
sent from another dimension (either a nimrod who can't set their clock
properly, or a spammer), rather than checking it against the current
timestamp (which might initially seem like a fine idea, but won't work when
you're reprocessing a mailbox, whereas the From_ line doesn't change just
because you re-read your mail, and thus remains a reasonable indicator of
when a message was locally received).
Keep in mind that if you're using fetchmail and depositing the mail in the
local mailspool, if you really want to use the first received header, you'd
better verify that it actually contains the Received: data for the arrival
at your remote mailhost, rather than being a locally generated Received:
(such as if your fetchmail posts the message to your local SMTP, rather
than invoking procmail on it directly). While fetchmail has options to
grab the first or last Received: header, it doesn't have any options for
"grab the second one".
<offtopic_but_related>
I'm working on a DNSBL checker for a discussion list site (though we intend
to maintain DNSBL at SMTP time, there's interest in checking posts against
candidate DNSBLs so that we can determine which ones would have an impact
upon legitimate users if they were utilized), and to that end, it is
necessary to be able to check the host the message was relayed by -- but to
traverse the Received headers to the first NON BACKUP MX for our own host,
so that we can get an acurrate picture of the relay mailhost. At best,
this would be tedious within procmail, and would involve multiple external
program invocations. I expect to utilize a small helper program written
specifically to the task, which will be able to parse the Received headers
and do it's job. Additionally, since the basic form of the DNBSL script
involves calling host multiple times (from procmail, a shell script is
called, passed the reverse dotted quad IP address and a list of dnsbl
zones, that script loops on the zones and calls the host util to do
lookups), it has a much higher overhead than a single program which simply
does multiple DNS lookups in one shot and returns the composite results.
Anyway, if you find yourself needing to pay attention to other received:
headers, you might have to tinker. OTOH, you could match for a Received:
BY your upline mailserver and hope that works out consistently.
</offtopic>
Actually I believe I want the last fetchmail added Received: header, since
it is the actual time and date the message hit my own mail server.
And yet, the From_ mbx header is so much easier to parse.
>From campbell(_at_)starbase(_dot_)neosoft(_dot_)com Mon Jun 11 08:54:50 2001
Surely this header looked curious in the context of this discussion.
Received: from starbase.neosoft.com (starbase.neosoft.com [206.109.1.32])
by helium.inexs.com (8.9.3/8.9.3) with ESMTP id IAA19196
for <campbell(_at_)[63(_dot_)140(_dot_)126(_dot_)166]>; Mon, 11 Jun
2001 08:54:49 -0500
Note difference between the timestamps in the the Receved: and the From_
are fairly negligible.
---
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