Question

这个其他工作方法导致邮件客户误解了“收到的”＃34;时间快5小时。这是唯一使用的配方。在比较写入两个标题的日期/时间时，基本上没有差异。什么是解决的好方法？食谱可以补偿吗？

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上收到的。

User-Agent: Microsoft-Entourage/12.20.0.xxxx
Date: Wed, 28 Jan 2015 16:05:57 -0800
Subject: 405pm test
From: "Robert" <from_email@domain.com>
To: "bob@domain.com" <bob@domain.com>
Message-ID: <D0EEB965.49C7D%from_email@domain.com>
Thread-Topic: 405pm test
Thread-Index: AdA7V1sU8z5udBOZSUyJx4az1tpIXA==
Mime-version: 1.0
Content-type: multipart/alternative;
    boundary="B_3505305958_xxxxxx"

一封显示正确时间（基本相同）的电子邮件：

User-Agent: Microsoft-Entourage/12.20.0.xxxxxxxx
Date: Thu, 29 Jan 2015 18:35:16 -0800
Subject: test
From: "Robert." <from_email@domain.com>
To: "bob@domain.com" <bob@domain.com>
Message-ID: <D0F02DE4.49D82%from_email@domain.com>
Thread-Topic: test
Thread-Index: AdA8NWF58VbsQ1XhgkuMBHgxsaYksg==
Mime-version: 1.0
Content-type: multipart/alternative;
    boundary="B_3505401322_xxxxxxxx"

Answer 1

我试图寻找适当的规范＆＃34;收到日期＆＃34;但找不到任何东西。但是，我偶然发现了https://bugzilla.mozilla.org/show_bug.cgi?id=402594，这两行之间表明邮件客户端实际上正在解析此信息的Received:标头。现在，问题仍然存在，他们看到Received:标题，以及在您的问题案例中这个标题有什么问题？没有任何内容专门转换为21:05（您的IMAP客户端显示的时间戳的精确副本对于诊断非常方便）所以这完全是推测性的 - 但如果您能够提出更好的推测，那么至少我可以告诉你如何解决如何替换标题中的东西的技术问题。

我假设我们应该查看最顶层的Received:标题，并简单地将其时区标准化为您希望看到的任何内容（似乎是-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运行它 - 我只是制作一个可以在你所有收到的邮件上运行的脚本，这只会修改那些需要更改的邮件。）

这会从第一个匹配的标题中提取日期标记（也许您应该将其调整为仅匹配特定的-0500个时区？）并将该特定日期字符串上的任何匹配项替换为新的匹配项，通过调用{ {1}}将捕获的日期作为参数，将其转换为运行的任何时区（我们使用date -R -d变量赋值设置 - 这是一个棘手的巫术，我永远不会记住正确的语法对于数字时区，我只需查找-0800的通用名称。

日期戳正则表达式是临时的，但我似乎记得每个月的单位数日内至少有空间与零填充，以及闰秒和时区，这些时间与UTC相差甚远。我确定还有一些我缺少的细节，或者只是愚蠢的思想。

我忽略了一个更顶级的TZ标题 - 它有一个不同的非RFC822格式的时间戳，所以我猜这是被忽略的您的IMAP客户端。

(qmail xxx invoked from network)正则表达式捕获令牌之前的古怪空括号是因为当一行开头的反斜杠时，Procmail 是古怪的。

Answer 2

我正在发布第二个答案，从Procmail的角度解决IMAP服务器端的猜测。

如果Qmail在发送到您的收件箱时做了一些特别的事情，您需要在Procmail配方中执行相同的操作。所以你在哪里

:0
$INBOX

你应该

:0
| whatever it is that qmail is doing to deliver into "$INBOX"

对不起，我不能更具体地说明应该在管道中的内容。根据IMAP服务器，您可以查找Dovecot，Courier（但似乎更喜欢maildrop而不是procmail），Cyrus等的热门投放操作;或者只是查看你的ISP的Qmail配置，看看它在做什么。

procmail配方导致错误的时间戳

2 个答案: