Почему procmail не соответствует этому правилу?

337
Amiramix

У меня есть следующее правило для отправки всех писем с подозрительными вложениями в отдельную папку:

# Emails with attachments :0 * ^Content-Type: multipart/ { :0 B * ^Content-Type: application/(zip|x-zip-compressed)|\ ^Content-Type:.*name=.*\.(zip|exe|rar|rtf|docm)|\ ^Content-.*attachment.*name=.*\.(zip|exe|rar|rtf|docm)|\ ^Content-.*application.octet-stream.*name=.*\.(zip|exe|rar|rtf|docm) $L/.3_my._quarantine/ } 

Однако я только что заметил, что электронное письмо с вложенным zip-файлом проскользнуло через него, и я не могу понять, почему (мой @ email и myemail содержали мою электронную почту и мой хост, который я запутал):

X-Priority: 3 (Normal) From: scanner47578858@myemail.com To: "my@email.com" <my@email.com> Subject: Attached File Date:Mon, 16 May 2016 17:16:47 +0530 Message-Id: <272843899191709486.0001.scannerTxNo.0051@scannerF04EF6.myemail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="53594271E1EBE7BBDAF4BBA9"  --53594271E1EBE7BBDAF4BBA9 Content-Type: application/x-compressed; name="my@email.com_3602848_97891076672132.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="my@email.com_3602848_97891076672132.zip" 

AFAICS ^Content-Type:.*name=.*\.(zip|exe|rar|rtf|docm)должен совпадать? Это из-за кавычек?

1
Я не использую `procmail`, но похоже, что строки конфигурации могут потребовать совпадения с полной строкой, и в этом случае, поскольку имя находится на отдельной строке от классификации, вам может понадобиться вставить строку` ^ . * name =. * \. (zip | exe | rar | rtf | docm) | \ `в вашу конфигурацию. AFH 8 лет назад 0
Это то, что я думал, но, очевидно, procmail расширяет сложенные заголовки при сопоставлении с условием. Я нашел много ресурсов, претендующих на то же самое, и я предполагаю, что это нечто иное, если не доказано обратное Посмотрите это, например, среди других: https://www.mhonarc.org/archive/html/procmail/2006-06/msg00119.html Amiramix 8 лет назад 0
Извини, я хватался за соломинку. В противном случае, как вы говорите, выражение выглядит хорошо. AFH 8 лет назад 0
Благодарность за включение короткого репрезентативного тестового сообщения. tripleee 8 лет назад 0

1 ответ на вопрос

1
tripleee

The post you link to does indeed state that folded headers are handled correctly, but this recipe is examining the body, not a header.

It is a misfeature of Procmail that it doesn't recognize MIME structures correctly; this would be an important addition to a modern mail filter; but alas, Procmail development ceased already in the early 2000s (and already once before then, when the original developer let go).

As a crude workaround, you could temporarily split a MIME multipart message on the MIME boundary, and feed each part to a separate Procmail recipe, but this quickly becomes brittle and complex (in theory, MIME messages could be nested arbitrarily deeply, though for most practical purposes, you only need to recurse one or two levels down -- anything beyond that is probably a bounce or something like that, not directly a feature of the message you are examining).

Because your regex has only a few possible (realistic!) split points, you can refactor it to account for possible line breaks:

:0 * ^Content-type: multipart/ { :0B * ^Content-Type: application/(zip|x-zip-compressed)|\ ^Content-Type:.*(($)[ ].*)*name=.*\.(zip|exe|rar|rtf|docm)|\ ^Content-.*attachment.*(($)[ ].*)*name=.*\.(zip|exe|rar|rtf|docm)|\ ^Content-.*application.octet-stream.*(($)[ ].*)*name=.*\.(zip|exe|rar|rtf|docm) $L/.3_my._quarantine/ } 

You'll notice the (($)[ ].*)* addition in a few places. This accounts for a possible newline (($)) followed by a whitespace character (tab or space, [ ]) followed by anything, repeated zero or more times.

(As an aside, this would perhaps be slightly easier to debug with scoring:

 :0 B * 1^1 ^Content-Type: application/(zip|x-zip-compressed) * 1^1 ^Content-Type:.*(($)[ ].*)*name=.*\.(zip|exe|rar|rtf|docm) * 1^1 ^Content-.*attachment.*(($)[ ].*)*name=.*\.(zip|exe|rar|rtf|docm) * 1^1 ^Content-.*application.octet-stream.*(($)[ ].*)*name=.*\.(zip|exe|rar|rtf|docm) ... 

With this, you can see in the VERBOSE=yes log the result of each individual regex in this complex multi-regex recipe.)

If you need a completely watertight recipe, perhaps write a simple script in Python or Perl (or Ruby or ... what have you) to normalize the MIME structure. I remember there was a tool called emil a long time ago which did something like this, but it was never very well-established, let alone well-documented. (In fact, IIRC it was designed specifically to plug into pre-MIME sendmail, and was near-impossible to use for anything else.)

О, круто! Я знал, что заголовки складываются автоматически и что procmail не работает с частями MIME должным образом, но каким-то образом не установил связь между этими двумя. Ваш ответ полностью имеет смысл. Спасибо! Amiramix 8 лет назад 0

Похожие вопросы