It sounds like I should use the last Received: fields instead of Date:
to regenerate the From_ header. Date: is date sent and could be wrong.
How do I do this in formail? Can I grab the date in the Received: field
and create a new From_ field? They seem to have different date formats.
From shuntsbe(_at_)mail-pop Tue Feb 18 18:16:28 2003 -0800
Return-Path: <owner-javascript(_at_)adobe(_dot_)com>
Received: from cliff.corp.adobe.com ([153.32.1.186]) by
mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul
11 2001 16:32:57) with ESMTP id H9YSQT00.2UV; Fri, 7 Feb 2003
16:44:53 -0800
Date: Fri, 7 Feb 2003 16:45:00 -0800
From: Mark Erickson <mark(_dot_)erickson(_at_)adobe(_dot_)com>
These mails occur when I copy from one IMAP server to another.
It sets the From to my address, at the time I make the copy.
Therefore, I also need to change the address in the From_.
For example, here I want a From_ field that looks like:
From mark(_dot_)erickson(_at_)adobe(_dot_)com Fri Feb 7 16:44:53 2003 -0800
I might want the Sender: and not From: if Sender: is present.
Is any of this possible in formail or must I write some Perl?
Thanks,
Steve Huntsberry
Adobe Systems Inc.
shuntsbe(_at_)adobe(_dot_)com
on 2/28/03 1:16 PM, Don Hammond at
throwaway-aye6CPwTejPe(_at_)tradersdata(_dot_)com
wrote:
Tastlessly following up myself:
| [...]
|
| Looking at it your way, I could guess that the difference between the
| time a message arrives at your ISP and the time fetchmail downloads it
| would, on average, be greater than the difference between the time it
| was sent and it arrives at your ISP. In other words fetcmail's polling
| time interval is likely to be greater than the time from sender to ISP.
| On the other hand, for messages where the converse is true, the
| discrepancy in the dates can be decades. [...]
That's worded incorrectly. The converse -- messages that take more
time from sender to ISP than from ISP to download are only a subset of
the exceptions. All of this is predicated, as is LuKreme's proposition,
on the notion that the Date: header accurately reflects when the message
was set. That may be so in most cases. The point is that when it's
not, the discrepancy is likely to be significant. Using Date: (or
From:, etc.) are always dubious because they're controlled by someone
other than you. And it's not only significant for forgeries and other
deliberate attempts to deceive.
The more I think about this, the more I dislike the Date: header. I
have 8 computers with 8 different times because I've never gotten
around to setting up ntp. Not only are you subject to other people
having their clocks set drastically wrong, but you're subject to
variations in clock settings on virtually every sender's machine that
makes every different Date: header like comparing apples and oranges.
The only constant, especially if the need is for sorting, is the
date/time it arrives on your machine. That's the only thing that's
totally within your control, and the only thing that is at all reliably
comparable from one message to the next -- especially if differences of
"4-6 minutes" are significant.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail