[BUG] BOGUS_ENCRYPTED_AND_TEXT for p7m attachments

filippocarletti commented 3 years ago

Prerequisites

[X] Put an X between the brackets on this line if you have done all of the following:
- Read about bug reporting in general: https://rspamd.com/doc/faq.html#how-to-report-bugs-found-in-rspamd
- Enabled relevant debugging logs: https://rspamd.com/doc/faq.html#how-to-debug-some-module-in-rspamd
- Checked the FAQs about Core files in case of fatal crash: https://rspamd.com/doc/faq.html#how-to-figure-out-why-rspamd-process-crashed
- Tried ASAN package and obtained the ASAN report (if possible): https://rspamd.com/doc/faq.html#asan-builds
- Checked that your issue isn't already filed: https://github.com/issues?utf8=%E2%9C%93&q=is%3Aissue+user%3Arspamd
- Checked that there is not already an experimental package or master branch

Describe the bug Emails containing a signed attachment (extension p7m) trigger both BOGUS_ENCRYPTED_AND_TEXT and BROKEN_HEADERS.

Steps to Reproduce

Use thunderbird or any other MUA to compose an email
Attach "file.p7m" to the email
Send to rspamd protected address

Expected behavior Email received without the two above symbols added

Versions

Rspamd daemon version 2.7 on CentOS 7

Additional Information

I can provide a p7m file for testing, but I'm not comfortable attaching it to a public issue (revealing the signature).

Roundcubemail is the only client I found which doesn't trigger the symbols. Here's a diff between an email created from thunderbird ("Test p7m.eml") and roundcube ("Test p7m rc.eml"):

--- "Test p7m.eml"  2021-08-05 16:38:50.816684857 +0200
+++ "Test p7m rc.eml"   2021-08-05 15:43:25.945147409 +0200
@@ -1,14 +1,14 @@
- boundary="------------3A9554E5A4F117B0C13F63FB"
-This is a multi-part message in MIME format.
---------------3A9554E5A4F117B0C13F63FB
-Content-Type: text/plain; charset=utf-8; format=flowed
-Content-Transfer-Encoding: 8bit
+ boundary="=_2dcfd8a074436ae27738b8237e286296"
+--=_2dcfd8a074436ae27738b8237e286296
+Content-Transfer-Encoding: 7bit
+Content-Type: text/plain; charset=US-ASCII;
+ format=flowed

 attached
-
---------------3A9554E5A4F117B0C13F63FB
-Content-Type: application/pkcs7-mime;
- name="CIAO.pdf.p7m"
+--=_2dcfd8a074436ae27738b8237e286296
 Content-Transfer-Encoding: base64
+Content-Type: application/octet-stream;
+ name=CIAO.pdf.p7m
 Content-Disposition: attachment;
- filename="CIAO.pdf.p7m"
+ filename=CIAO.pdf.p7m;
+ size=30681

vstakhov commented 3 years ago

I cannot reproduce it with a simple p7m attachment. I see completely different headers. So I need samples to reproduce and possibly fix...

filippocarletti commented 3 years ago

I sent a sample to your email address. [EDIT] But it bounced. Resending in a password protected zip file. Thanks.

filippocarletti commented 3 years ago

@vstakhov where can I send you a sample? Thank you.

tpl1969 commented 3 years ago

We have the same problem here. When I attach a file with suffix .p7m, it is rejected by rspamd with BOGUS_ENCRYPTED_AND_TEXT and HEADER_BROKEN Symbols.

Rspamd is on Centos 7: rspamd-3.0-2.x86_64

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

filippocarletti commented 2 years ago

Similar behaviour using Rspamd 3.2:

BOGUS_ENCRYPTED_AND_TEXT(10.00){smime part;},BROKEN_HEADERS(8.00){},ENCRYPTED_SMIME(-0.50){}

LucaNonato commented 2 years ago

This is a big issue here in Italy since more and more companies are sending/receiving those digitally signed P7M using ordinary e-mail.

If there's anything i can do to help you fix it just ask: we have tens of servers running RSPAMD and can do whatever test you like. :)

Cheers! Luca

LucaNonato commented 2 years ago

FYI we tried adding "application/x-pkcs7-signature -99" to "/var/lib/rspamd/mime_types.inc.local" but didn't help.

Cheers! Luca

mapreri commented 2 years ago

Indeed, I'm also seeing this issue here, indeed with Italian companies!

@LucaNonato what kind of workaround did you employ in the end?

LucaNonato commented 2 years ago

@LucaNonato what kind of workaround did you employ in the end?

@mapreri Unfortunately using the worst - but currently also the only - possible solution: i lowered the scores for BOGUS_ENCRYPTED_AND_TEXT and BROKEN_HEADERS (!!!) from 10 to 1, and for our customers this fixed the issue.

I obviously don't like it but fortunately this didn't increase the SPAM that passed through the mailserver since those two symbols are triggered (almost?) only by P7M attachments.

See: Impossibile inviare o ricevere email con allegati firmati (.p7m)/Unable to send or receive emails with signed attachments (.p7m)

mapreri commented 2 years ago

Ok, I have done the same thing myself indeed, I was hoping for something more clever, but indeed I don't think I ever met anything match BOGUS_ENCRYPTED_AND_TEXT so it doesn't really matter.

mitsecsrl commented 1 year ago

Same problem here, I will lower the score too, but I think this can only be a temporary fix Any news on a permanent one? @vstakhov did you manage to get the sample? Thanks

TomFuch commented 4 months ago

Still the same Problem with current Version 3.8.4. I think this is because, rspamd uses this function in misc.lua to determine if the message is signed or encrypted. The Problem is that when u get a smime encrypted message the body don't contain any mime parts. Now when u will check if the message is encrypted I think we must use the content-type header... isn it? Body only contains an Base64Block

alainwolf commented 2 weeks ago

I ran into this with an S/MIME signed mail which had a public OpenPGP key as attachment. That was sent to establish secure communications between two companies. I was surprised by the "10". I don't think I ever encountered such a high score by a single rule.

BOGUS_ENCRYPTED_AND_TEXT (10) [pgp part]
SIGNED_SMIME (-2)
ENCRYPTED_PGP (-0.5)
MIME_GOOD (-0.2) [multipart/signed,multipart/mixed,multipart/alternative,text/plain]
MIME_BASE64_TEXT (0.1)
TO_MATCH_ENVRCPT_ALL (0)
FREEMAIL_CC (0) [gmail.com]
HAS_ATTACHMENT (0)
MID_RHS_MATCH_FROM (0)
FROM_EQ_ENVFROM (0)
RCVD_COUNT_ZERO (0) [0]
RCPT_COUNT_TWO (0) [2]
TO_DN_NONE (0)
FROM_HAS_DN (0)
DKIM_SIGNED (0) [example.net:s=2024]
FREEMAIL_ENVRCPT (0) [gmail.com]
ARC_NA (0)
MIME_TRACE (0) [0:+,1:+,2:+,3:+,4:~,5:~,6:~]

At the same time it got misinterpreted as ENCRYPTED_PGP together with the justified SIGNED_SMIME See also #3205, which supposedly has been fixed a few years back, but maybe not completely.

Rspamd daemon version 3.10.2

CPU architecture x86_64; features: avx, sse2, sse3, ssse3, sse4.1, sse4.2
Hyperscan enabled: TRUE
Jemalloc enabled: TRUE
LuaJIT enabled: TRUE (LuaJIT version: LuaJIT 2.1.1725453128)
ASAN enabled: FALSE
BLAS enabled: FALSE
Fasttext enabled: FALSE

The MUA submitting the message was Thunderbird 'Nebula' 128.3.1esr (64-bit).

What I also don't understand: Where is this is even set? The symbol is listed as part of the mime_tpyes group, but I can't find any module or other configuration neither on my systems nor on the Rspamd documentation website.

rspamd / rspamd