Por que o procmail não corresponde a essa regra?

1

Eu 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, notei que um e-mail com um anexo zip passou por ele e não consigo entender por que (my @ email e myemail continham meu e-mail e meu host que 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 de aspas?

    
por Amiramix 16.05.2016 / 14:36

1 resposta

1

A postagem com a qual você faz o link realmente indica que os cabeçalhos dobrados são manipulados corretamente, mas essa receita está examinando o corpo, não um cabeçalho.

É uma falha na funcionalidade do Procmail que ele não reconhece as estruturas MIME corretamente; isso seria um acréscimo importante para um filtro de mensagens moderno; mas, infelizmente, o desenvolvimento do Procmail já cessou no início dos anos 2000 (e já uma vez antes, quando o desenvolvedor original desistiu).

Como solução alternativa, você pode 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 dos propósitos práticos, você precise reciclar apenas um ou dois níveis - qualquer coisa além disso é provavelmente um salto ou algo assim, não diretamente um recurso da mensagem que você está examinando).

Como seu regex tem apenas alguns pontos de divisão possíveis (realistas!), é possível refatorá-lo para considerar 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 representa 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.

(Como um aparte, isso talvez seja um pouco mais fácil de 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=yes log o resultado de cada regex individual nesta receita complexa de multi-regex.)

Se você precisar de uma receita totalmente impermeável, talvez escreva um script simples em Python ou Perl (ou Ruby ou ... o que você tem) para normalizar a estrutura MIME. Eu lembro que havia uma ferramenta chamada emil há muito tempo que fazia algo assim, mas nunca foi bem estabelecida, muito menos bem documentada. (Na verdade, o IIRC foi projetado especificamente para se conectar ao pré-MIME sendmail e era quase impossível de usar para qualquer outra coisa.)

    
por 23.05.2016 / 07:00