procmail配方导致错误的时间戳 [英] procmail recipe causes wrong timestamp

问题描述

此否则有效的配方会导致邮件客户端将接收"时间误解为5小时.这是唯一使用的配方.比较写在两个标题中的日期/时间时，基本上没有区别.什么是解决的好方法?食谱可以补偿吗?

This otherwise working recipe causes mail clients to misinterpret the "received" time as 5hrs fast. This is the only recipe in use. When comparing date/time written into both headers, there's essentially no differences. What's a good way to address? Can a recipe compensate?

LOGFILE=$HOME/proclog
VERBOSE=YES 

# prevent qmail (the program that is calling procmail 
# as a filter) from delivering the original mail.

EXITCODE=99 

MAILDIR=$HOME/boxes/mydomain.com
INBOX=$MAILDIR/bob
GREY=$MAILDIR/bob^/.imap/grey
JUNK=$MAILDIR/bob^/.imap/Junk
TEST=$MAILDIR/bob^/.imap/Test 

:0
* ^Subject:.*test
${TEST}

# Spam level < 2.0: it's probably real email, deliver as normal 
:0
${INBOX}

以下是电子邮件的标头，该电子邮件是在下午4:05发送的，但显示在晚上9:05在桌面电子邮件客户端和iOS上收到.

Below is the header of an email that was sent at 4:05pm, but shows being received at 9:05pm on a desktop email client, and iOS.

Return-Path: <[e-mail]>
Delivered-To: username-domain:[e-mail]
X-Envelope-To: [e-mail]
Received: (qmail 16283 invoked from network); 29 Jan 2015 00:05:59 -0000
Received: from mailwash46.pair.com (IP ADDRESS)
  by tanha.pair.com with SMTP; 29 Jan 2015 00:05:59 -0000
Received: from localhost (localhost [127.0.0.1])
    by mailwash46.pair.com (Postfix) with SMTP id 31958EBC17
    for <[e-mail]>; Wed, 28 Jan 2015 19:05:59 -0500 (EST)
Received: from tanha.pair.com (tanha.pair.com [IP ADDRESS])
    by mailwash46.pair.com (Postfix) with ESMTP id 0E9EBEBFB5
    for <[e-mail]>; Wed, 28 Jan 2015 19:05:59 -0500 (EST)
Received: from [192.168.1.230] (c-IP ADDRESS.hsd1.wa.comcast.net [IP ADDRESS])
    by tanha.pair.com (Postfix) with ESMTPSA id BE211F1D10
    for <[e-mail]>; Wed, 28 Jan 2015 19:05:58 -0500 (EST)
User-Agent: Microsoft-Entourage/12.20.0.xxxx
Date: Wed, 28 Jan 2015 16:05:57 -0800
Subject: 405pm test
From: "Robert" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: 405pm test
Thread-Index: AdA7V1sU8z5udBOZSUyJx4az1tpIXA==
Mime-version: 1.0
Content-type: multipart/alternative;
    boundary="B_3505305958_xxxxxx"

还有一封显示正确时间(基本上相同)的电子邮件:

And an email that shows correct times (essentially the same):

Return-Path: <[e-mail]>
Delivered-To: username-domain:[e-mail]
X-Envelope-To: [e-mail]
Received: (qmail 22574 invoked from network); 30 Jan 2015 02:35:23 -0000
Received: from mailwash46.pair.com (IP ADDRESS)
  by tanha.pair.com with SMTP; 30 Jan 2015 02:35:23 -0000
Received: from localhost (localhost [127.0.0.1])
    by mailwash46.pair.com (Postfix) with SMTP id 4CF3BEBF9D
    for <[e-mail]>; Thu, 29 Jan 2015 21:35:23 -0500 (EST)
Received: from tanha.pair.com (tanha.pair.com [IP ADDRESS])
    by mailwash46.pair.com (Postfix) with ESMTP id 4C278EBF97
    for <[e-mail]>; Thu, 29 Jan 2015 21:35:23 -0500 (EST)
Received: from [192.168.1.230] (c-IP ADDRESS.hsd1.wa.comcast.net [IP ADDRESS])
    by tanha.pair.com (Postfix) with ESMTPSA id 55E98F1BF8
    for <[e-mail]>; Thu, 29 Jan 2015 21:35:21 -0500 (EST)
User-Agent: Microsoft-Entourage/12.20.0.xxxxxxxx
Date: Thu, 29 Jan 2015 18:35:16 -0800
Subject: test
From: "Robert." <[e-mail]>
To: "[e-mail]" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: test
Thread-Index: AdA8NWF58VbsQ1XhgkuMBHgxsaYksg==
Mime-version: 1.0
Content-type: multipart/alternative;
    boundary="B_3505401322_xxxxxxxx"

推荐答案

我试图为接收日期"寻找适当的规范，但找不到任何规范.但是，我偶然发现了 https://bugzilla.mozilla.org/show_bug.cgi?id= 402594 (在两行之间表示邮件客户端实际上正在解析此信息的Received:标头).现在，问题仍然存在，他们要查看哪个Received:标头，在有问题的情况下此标头有什么问题?那里没有任何内容可以具体翻译为21:05(由IMAP客户端显示的时间戳的精确副本对于诊断很方便)，因此这完全是推测性的-但如果您能提出更好的推测，请至少我可以向您展示如何解决如何替换标题中的技术性问题.

I tried to look for a proper specification for "received date" but could not find any. However, I stumbled across https://bugzilla.mozilla.org/show_bug.cgi?id=402594 which between the lines indicates that mail clients are in fact parsing the Received: headers for this information. Now, the question remains, which Received: header do they look at, and what's wrong with this header in your problematic case? There is nothing there which specifically translates to 21:05 (an exact copy of the timestamp displayed by your IMAP client(s) would be handy for diagnostics) so this is entirely speculative -- but if you can come up with better speculations, at least I can show you how to solve the technical question of how to replace something in the headers.

我假设我们应该查看最顶部的Received:标头，并简单地将其时区标准化为您希望看到的任何东西(似乎是-0800 PST).

I am assuming we should look at the topmost Received: header and simply normalize its time zone to whatever you expect to see (which seems to be -0800 PST).

TZ="America/Los_Angeles"
:0fhW
* ^Received:[   ]*from[         ]*.*($[         ].*)*; \
        ()\/(Mon|T(ue|hu)|Wed|Fri|S(at|un)), \
        [0-3 ][0-9] (A(pr|ug)|Dec|Feb|J(an|u[nl])|Ma[ry]|Oct|Sep) \
        20[1-9][0-9] [0-2][0-9]:[0-5][0-9]:[0-6][0-9] [-+][01][0-9][0134][05] \
        \([A-Z]+T\)
| d=`date -R -d "$MATCH"`; sed "s/$MATCH/$d/"

现在，这显然很脆弱，但至少可以粗略地向您展示如何做到这一点.对于一种更可移植且更健壮的方法，我也许可以将其处理到一个外部脚本(Python，Perl，您拥有什么)中，而不是使用Procmail和Shell脚本进行编码. (当然，您仍然可以从Procmail运行它-我只是简单地编写一个可以在所有传入电子邮件中运行的脚本，该脚本只会修改需要更改的电子邮件.)

Now, this is obviously rather brittle, but at least shows you in rough terms how this could be done. For a more portable and robust approach, I would perhaps work this into an external script (Python, Perl, what have you) instead of coding it in Procmail and shell script. (You could still run it from Procmail, of course -- I would simply make a script which can be run on all your incoming email, which would only modify the ones which need to be changed.)

这将从第一个匹配的标头中提取日期戳(也许您应该对其进行调整，使其仅在-0500时区才匹配?)，然后将特定日期字符串上的任何匹配替换为新的，通过调用date -R -d，以捕获的日期作为参数，它将其转换为正在运行的任何时区(我们使用TZ变量赋值设置了该时间-这是棘手的伏都教，我永远都不会记得数字时区的正确语法所以我只是查询了-0800的通用名称.

This extracts the date stamp out of the first matching header (maybe you should tweak it to only match on -0500 time zones in particular?) and replaces any match on that specific date string with a new one, produced by calling date -R -d with the captured date as the argument, which converts it to whatever time zone this is running in (which we set with the TZ variable assignment -- this is tricky voodoo, I can never remember the correct syntax for numeric time zones so I simply looked up a common name for -0800).

datestamp正则表达式是临时的，但我似乎记得至少一个月的某个数字天是空格vs零填充，leap秒和时区距UTC甚至都不是几小时.我敢肯定，我仍然缺少一些细节，或者只是愚蠢的想法.

The datestamp regex is ad hoc, but I seem to have remembered at least space vs zero padding for single-digit days of the month as well as leap seconds and time zones which are not on even hours from UTC. I'm sure there are still some details that I am missing, or just silly thinkos.

我忽略了一个甚至更高的(qmail xxx invoked from network)标头-它具有不同的非RFC822格式的时间戳，因此我想您的IMAP客户端也将忽略它.

There's an even more-topmost (qmail xxx invoked from network) header which I am ignoring -- it has the time stamp in a different, non-RFC822 format, so I'm guessing this is ignored by your IMAP client, too.

\/正则表达式捕获令牌之前的古怪空括号是因为Procmail 在行首出现反斜杠时很古怪.

The wacky empty parentheses before the \/ regex capturing token is because Procmail is wacky when it comes to a backslash at the start of a line.

这篇关于procmail配方导致错误的时间戳的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！