Warum stimmte Procmail nicht mit dieser Regel überein?

438
Amiramix

Ich habe die folgende Regel, um alle E-Mails mit verdächtigen Anhängen in einen dedizierten Ordner zu senden:

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

Mir ist jedoch gerade aufgefallen, dass eine E-Mail mit einem ZIP-Anhang durchgeschlüpft ist, und ich kann nicht herausfinden, warum (meine @ E-Mail und meine E-Mail-Adresse enthielten meine E-Mail und meinen Host, die ich verschleiert habe):

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)sollte übereinstimmen? Liegt es an den Anführungszeichen?

1
Ich benutze `procmail` nicht, aber es sieht so aus, als müssten die Konfigurationszeilen einer vollständigen Zeile entsprechen. In diesem Fall müssen Sie die Zeile` ^ einfügen, da sich der Name in einer separaten Zeile von der Klassifizierung befindet . * name =. * \. (zip | exe | rar | rtf | docm) | \ `in Ihre Konfiguration. AFH vor 8 Jahren 0
Das dachte ich, aber anscheinend erweitert procmail gefaltete Kopfzeilen, wenn es an die Bedingung angepasst ist. Ich habe viele Ressourcen gefunden, die dasselbe behaupten, und ich gehe davon aus, dass dies etwas anderes ist, sofern nichts anderes nachgewiesen wird. Sehen Sie sich dies unter anderem an: https://www.mhonarc.org/archive/html/procmail/2006-06/msg00119.html Amiramix vor 8 Jahren 0
Entschuldigung, ich habe nach Strohhalmen gegriffen. Ansonsten sieht der Ausdruck, wie Sie sagen, in Ordnung aus. AFH vor 8 Jahren 0
Ein großes Lob für die Aufnahme einer kurzen, repräsentativen Testnachricht. tripleee vor 8 Jahren 0

1 Antwort auf die Frage

1
tripleee

Der Beitrag, zu dem Sie einen Link erstellen, gibt zwar an, dass gefaltete Header korrekt verarbeitet werden, dieses Rezept untersucht jedoch den Hauptteil und nicht den Header.

Es ist eine Fehlfunktion von Procmail, dass MIME-Strukturen nicht richtig erkannt werden. Dies wäre eine wichtige Ergänzung zu einem modernen Mail-Filter. Aber die Entwicklung von Procmail wurde bereits Anfang der 2000er Jahre eingestellt (und schon einmal zuvor, als der ursprüngliche Entwickler losließ).

Als grobe Problemumgehung könnten Sie eine MIME-Multipart-Nachricht an der MIME-Grenze zeitweilig aufteilen und jeden Teil einem separaten Procmail-Rezept zuführen. Dies wird jedoch schnell spröde und komplex (theoretisch könnten MIME-Nachrichten beliebig tief verschachtelt sein, wenn auch für die meisten) Aus praktischen Gründen müssen Sie nur ein oder zwei Ebenen nach unten rekursieren - alles, was darüber hinausgeht, ist wahrscheinlich ein Sprung oder etwas Ähnliches, nicht direkt ein Merkmal der zu untersuchenden Nachricht.

Da Ihr Regex nur wenige mögliche (realistische!) Split-Punkte hat, können Sie ihn umwandeln, um mögliche Zeilenumbrüche zu berücksichtigen:

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

Sie werden den (($)[ ].*)*Zusatz an einigen Stellen bemerken . Dies berücksichtigt einen möglichen Zeilenumbruch ( ($)), gefolgt von einem Leerzeichen (Tabulator oder Leerzeichen [ ]), gefolgt von etwas, das null oder mehrmals wiederholt wird.

(Abgesehen davon wäre dies möglicherweise etwas einfacher zu debuggen:

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

Damit können Sie VERBOSE=yesdas Ergebnis jedes einzelnen Regex in diesem komplexen Rezept mit mehreren Regexen im Protokoll sehen.)

Wenn Sie ein vollständig wasserdichtes Rezept benötigen, schreiben Sie vielleicht ein einfaches Skript in Python oder Perl (oder Ruby oder ... was haben Sie), um die MIME-Struktur zu normalisieren. Ich erinnere mich, dass es vor emillanger Zeit ein Tool gab, das so etwas tat, aber es war nie sehr gut etabliert, geschweige denn gut dokumentiert. (Tatsächlich wurde IIRC speziell für das Anschließen an pre-MIME sendmailentwickelt und war für fast alle anderen Anwendungen nahezu unmöglich.)

Oh toll! Ich wusste, dass Header automatisch gefaltet werden und dass procmail mit MIME-Teilen nicht richtig funktioniert, aber irgendwie keine Verbindung zwischen diesen beiden hergestellt hat. Ihre Antwort macht völlig Sinn. Vielen Dank! Amiramix vor 8 Jahren 0