рецепт procmail вызывает неправильную отметку времени

Этот рецепт, который работает в другом месте, заставляет почтовые клиенты неверно интерпретировать «полученное» время как 5 часов быстро. Это единственный рецепт в использовании. При сравнении даты и времени, записанных в оба заголовка, по существу нет различий. Каким образом можно обратиться? Может ли рецепт компенсировать?рецепт procmail вызывает неправильную отметку времени

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" <[email protected]> 
To: "[email protected]" <[email protected]> 
Message-ID: <D0EEB965.49C7D%[email protected]> 
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." <[email protected]> 
To: "[email protected]" <[email protected]> 
Message-ID: <D0F02DE4.49D82%[email protected]> 
Thread-Topic: test 
Thread-Index: AdA8NWF58VbsQ1XhgkuMBHgxsaYksg== 
Mime-version: 1.0 
Content-type: multipart/alternative; 
    boundary="B_3505401322_xxxxxxxx"

источник

2015-01-29 bobzIlla

Почтовые клиенты не должны интерпретировать заголовки «Received:» в любом случае. Не могли бы вы показать пример того, как он выглядит и как вы хотите, чтобы он выглядел? Мое подозрение в том, что это просто UTC против местного и совсем не так. – tripleee

У моего почтового клиента есть отправленный и полученный столбец. В столбце отправки указано правильное время. На ios (Mail) отображается только + 5 часов. Я должен отметить, что (как я понимаю) без вызова EXITCODE = 99 система отправляет исходное электронное письмо (через qmail, я думаю), а затем отправляет отфильтрованную версию procmail того же письма туда, куда ему сказали, чтобы идти. Это 2-е отфильтрованное письмо, которое показывает временное несоответствие. – bobzIlla

Похоже, что это не заголовки 'Received:', но в любом случае, пожалуйста, включите заголовки примерного сообщения в свой вопрос и укажите, какая часть не так. – tripleee

Я пытался искать правильную спецификацию «получили дату», но не смог найти. Однако я наткнулся на 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 и сценарии оболочки. (Разумеется, вы все равно можете запустить его из Procmail - я просто создам скрипт, который можно запустить на все входящие письма, которые будут изменять только те, которые необходимо изменить.)

Это извлекает дату штамп из первого совпадающего заголовка (возможно, вы должны настроить его, чтобы он соответствовал только часовым поясам -0500 в частности?) и заменяет любое соответствие в указанной строке даты новой, созданной путем вызова date -R -d с зафиксированной датой в качестве аргумента , который преобразует его в любой часовой пояс, в котором он выполняется (который мы установили с назначением переменной TZ - это сложное вуду, я не могу вспомнить правильный синтаксис для числовых часовых поясов, поэтому я просто искал общее имя для -0800).

Регулярное выражение datestamp является ad hoc, но, похоже, я помню как минимум пробел или нулевой пробел для однозначных дней месяца, а также секунд прыжка и часовых поясов, которые не на часах с UTC. Я уверен, что есть еще некоторые детали, которые мне не хватает, или просто глупые мысли.

Существует еще более-самый верхний заголовок (qmail xxx invoked from network), который я игнорирую - он имеет отметку времени в другом формате, отличном от RFC822, поэтому я предполагаю, что это тоже игнорируется вашим клиентом IMAP.

Необычные пустые круглые скобок перед захватом маркеров \/ регулярных выражений, потому что Procmail является дурацким, когда дело доходит до обратного косых черт в начале строки.

источник

2015-01-30 05:39:27 tripleee

Еще одно предположение заключается в том, что клиент каким-то образом запрашивает сервер IMAP для отметки времени, которая как-то поддерживается во внутренней базе данных. Возможно, выясните, какой IMAP-сервер это и что Qmail каким-то образом делает что-то особенное при доставке в хранилище сообщений. – tripleee

Хорошо, спасибо. Я признаю, что это немного превосходит меня. Msg не досталась. Вот журнал, извините, это не более читаемо: procmail: Выполнение «d =' date -R -d »$ MATCH« '; sed» s/$ MATCH/$ d/"" дата: незаконный вариант - R использование: date [-jnu] [-d dst] [-r seconds] [-t west] [-v [+ | -] val [ymwdHMS]] ... [-f fmt date | [[[[[cc] yy] mm] dd] HH] MM [.ss]] [+ format] d =: Команда не найдена. d: Неопределенная переменная. procmail: ненулевой код выхода (1) из «d =' date -R -d »$ MATCH« '; sed» s/$ MATCH/$ d/"" procmail: сработало спасение нефильтрованных данных – bobzIlla

GNU 'date 'имеет параметр' -R', который формирует формат даты RFC822, но, видимо, у вас его нет (или ваш GNU 'coreutils' действительно старый). Еще один момент для написания этого на переносимом языке сценариев. – tripleee

Я отправляю второй ответ, чтобы обратиться к серверной стороне IMAP с точки зрения Procmail.

Если Qmail делает что-то особенное при доставке в ваш почтовый ящик, вам нужно сделать то же самое из рецептов Procmail. Так, где у вас есть

:0 
$INBOX

вместо него вы должны иметь

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

Я сожалею, что не могу быть более конкретным о том, что должно быть в трубопроводе. В зависимости от сервера IMAP, вы можете найти популярные действия доставки для Dovecot, Courier (который, как представляется, предпочитает maildrop за procmail), Cyrus и т. Д .; или просто посмотрите конфигурацию Qmail своего провайдера, чтобы узнать, что он делает.

источник

2015-01-30 07:09:57 tripleee

Большое спасибо. Я продолжу отбрасывать это. – bobzIlla

рецепт procmail вызывает неправильную отметку времени

ответ

Смежные вопросы