☰

Por que o procmail não correspondeu a esta regra?

tag-icon • tag-icon email spam-prevention email-filter procmail
Por que o procmail não correspondeu a esta regra?

Tenho a seguinte regra para enviar todos os emails com anexos suspeitos para uma pasta dedicada:

# 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/
}

No entanto, acabei de notar que um email com um anexo zip passou por ele e não consigo entender o porquê (my@email e myemail continham meu email e meu host que eu ofusquei):

X-Priority: 3 (Normal)
From: [email protected]
To: "[email protected]"
 <[email protected]>
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="[email protected]_3602848_97891076672132.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="[email protected]_3602848_97891076672132.zip"

AFAICS ^Content-Type:.*name=.*\.(zip|exe|rar|rtf|docm)deve corresponder? É por causa das aspas?

Responder1

A postagem para a qual você vincula realmente afirma que foi dobradocabeçalhossão tratados corretamente, mas esta receita examina o corpo, não o cabeçalho.

É uma característica incorreta do Procmail não reconhecer estruturas MIME corretamente; esta seria uma adição importante a um filtro de correio moderno; mas, infelizmente, o desenvolvimento do Procmail já cessou no início dos anos 2000 (e já uma vez antes disso, quando o desenvolvedor original o dispensou).

Como uma solução alternativa grosseira, você poderia dividir temporariamente uma mensagem MIME multipart no limite MIME e alimentar cada parte em uma receita Procmail separada, mas isso rapidamente se torna frágil e complexo (em teoria, as mensagens MIME podem ser aninhadas arbitrariamente profundamente, embora para a maioria Para fins práticos, você só precisa recorrer um ou dois níveis abaixo - qualquer coisa além disso é provavelmente uma rejeição ou algo parecido, não diretamente um recurso da mensagem que você está examinando).

Como sua regex tem apenas alguns pontos de divisão possíveis (realistas!), você pode refatorá-la para levar em conta possíveis quebras de linha:

: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/
}

Você notará a (($)[ ].*)*adição em alguns lugares. Isso explica uma possível nova linha ( ($)) seguida por um caractere de espaço em branco (tabulação ou espaço, [ ]) seguido por qualquer coisa, repetido zero ou mais vezes.

(Além disso, talvez fosse um pouco mais fácil depurar com pontuação:

  :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)
  ...

Com isso, você pode ver no VERBOSE=yeslog o resultado de cada regex individual nesta complexa receita multi-regex.)

Se você precisar de uma receita completamente estanque, talvez escreva um script simples em Python ou Perl (ou Ruby ou ... o que quer que seja) para normalizar a estrutura MIME. Lembro que existia uma ferramenta chamada emilhá muito tempo que fazia algo assim, mas nunca foi muito bem estabelecida, muito menos bem documentada. (Na verdade, o IIRC foi projetado especificamente para ser conectado ao pré-MIME sendmaile era quase impossível de usar para qualquer outra coisa.)

informação relacionada