An external sender did send an email which is PGP Inline encrypted with our public key.
His attached public key has been automatically imported but not trusted yet, as there
is no automatic mechanism to do so.
Cipermail Version 5.0.4
The log states:
06 Aug 2021 10:47:05 | INFO incoming; MailID: 96a3f2d1-a2ac-46da-abfd-
f1afda2de434; Recipients: [example(a)domain.tld]; Originator:
sender(a)external.tld; Sender: sender(a)external.tld; Remote address:
XXX.XXX.XXX.XXX; Subject: Some Subject; Message-ID:
<5285c5f4d0274c328350c62b0d49dd38(a)FDSFSDAFASDFA.com>;
(mitm.application.djigzo.james.mailets.Log) [Spool Thread #2]
06 Aug 2021 10:47:05 | INFO Subject filter is disabled for the sender;
MailID: 96a3f2d1-a2ac-46da-abfd-f1afda2de434; Recipients:
[example(a)domain.tld] (mitm.application.djigzo.james.mailets.Default)
[Spool Thread #2]
06 Aug 2021 10:47:05 | INFO To internal recipient(s); MailID:
96a3f2d1-a2ac-46da-abfd-f1afda2de434; Recipients: [example(a)domain.tld]
(mitm.application.djigzo.james.mailets.Default) [Spool Thread #2]
06 Aug 2021 10:47:05 | WARN PGP/INLINE signature was not valid;
Failure message: Public key not found in trust list.; MailID: 96a3f2d1-
a2ac-46da-abfd-f1afda2de434
(mitm.common.security.openpgp.PGPRecursiveValidatingMIMEHandler) [Spool
Thread #2]
06 Aug 2021 10:47:05 | WARN PGP/INLINE signed message contained mixed
content; MailID: 96a3f2d1-a2ac-46da-abfd-f1afda2de434
(mitm.common.security.openpgp.PGPRecursiveValidatingMIMEHandler) [Spool
Thread #2]
06 Aug 2021 10:47:05 | INFO Message has been PGP decrypted; MailID:
96a3f2d1-a2ac-46da-abfd-f1afda2de434; Recipients: [example(a)domain.tld]
(mitm.application.djigzo.james.mailets.PGPHandler) [Spool Thread #2]
06 Aug 2021 10:47:05 | INFO Message handling is finished. Sending to
final recipient(s); MailID: 96a3f2d1-a2ac-46da-abfd-f1afda2de434;
Recipients: [example(a)domain.tld]; Originator: sender(a)external.tld;
Sender: sender(a)external.tld; Remote address: XXX.XXX.XXX.XXX; Subject:
Some Subject; Message-ID:
<5285c5f4d0274c328350c62b0d49dd38(a)FDSFSDAFASDFA.com>;
(mitm.application.djigzo.james.mailets.Log) [Spool Thread #2]
One line says "Failure message: Public key not found in trust list" but
the following message says "Message has been PGP decrypted".
Still the mail reaches the user mailbox in encrypted sate.
Either the obviously wrong success message is a bug or something i
don't understand is going on.
I never dealt with PGP Inline before but i would expect that the decrypted "Inline" content is inserted right in the message instead of beieng attach as an attachment.
I never dealt with PGP Inline before but i would expect that the
decrypted "Inline" content is inserted right in the message instead
of beieng attach as an attachment.
This can only happen if the email is not detected as being PGP/MIME
encoded. If the email is not detected as PGP/MIME it will treat the
MIME part as PGP/INLINE.
You said:
The original message content
Are the reported headers the outer headers, i.e., the top headers? Or
are these headers from a MIME part?
Can you send the complete full headers?
Kind regards,
Martijn Brinkers
···
On Thu, 2021-08-19 at 16:07 +0000, wilson.meier--- via Users wrote:
--
CipherMail email encryption
Email encryption with support for S/MIME,
OpenPGP, PDF Messenger and Webmail Messenger
Return-Path: <>
Received: from [x.x.x.x] ([x.x.x.x]) by mx.kundenserver.de
(mxeue112 [x.x.x.x]) with ESMTPS (Nemesis) id 1MYOma-1mc4Z70XGE-00VLt4
for <recipient(a)domain.ltd>; Thu, 19 Aug 2021 17:52:19 +0200
Received: from mail1.someserver.com ([x.x.x.x]) by mx.kundenserver.de
(mxeue112 [x.x.x.x]) with ESMTPS (Nemesis) id 1MVtwJ-1mgDIs0Uzd-00RnFN
for <recipient(a)domain.ltd>; Thu, 19 Aug 2021 17:52:19 +0200
DomainKey-Signature: <snip>
DKIM-Signature: <snip>
IronPort-SDR: <snip>
Received: from someserver.com ([x.x.x.x])
by someserver.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Aug 2021 15:52:18 +0000
Received: from someserver.com.dir ([x.x.x.x]) by
someserver.com.dir ([x.x.x.x]) with Microsoft SMTP Server id
15.01.2308.014; Thu, 19 Aug 2021 17:52:18 +0200
Received: from someserver.com.dir (x.x.x.x) by
someserver.com.dir (x.x.x.x) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2308.14; Thu, 19 Aug 2021 17:52:18 +0200
Received: from unknown (HELO smtp-someserver.com.domain-dns.net) ([x.x.x.x])
by someserver.com with ESMTP/TLS/AES256-GCM-SHA384; 19 Aug 2021 15:52:18 +0000
Received: from x.x.x.x ([x.x.x.x])
by someserver.com (Totemo SMTP Server) with SMTP ID 148
for <recipient(a)domain.ltd>;
Thu, 19 Aug 2021 17:52:18 +0200 (CEST)
The problem is that Totemo produces an email which is not a valid PGP/MIME email
A PGP/MIME email should have an multipart/encrypted or multipart/signed content type. A special content type allows a system to easilly detect that a message is PGP or not without having to scan the complete message. Compare this with PGP/INLINE (aka PGP classic) where a PGP part can be anywhere in the MIME blob. To support PGP/INLINE, every email has to be scanned from top to bottom in order to detect possible PGP parts. This makes PGP/INLINE much more resource intensive (and this is the reason it’s not enabled by default in the CipherMail gateway).
The example emails you sent me shows that the email from Totemo has a multipart/mixed content type. The gateway therefore does not detect this as being a PGP/MIME message. If the gateway has PGP/INLINE enabled, it will scan for PGP/INLINE parts. Since PGP/MIME contains PGP parts, and if PGP/INLINE is enabled, those parts will be decrypted. The resulting message however will still have the same MIME structure because PGP/INLINE will not change the MIME structure.
Supporting this is not trivial because now the gateway has to scan every email from top to bottom for a PGP/MIME part. This defeats the purpose of PGP/MIME.
Hello,
I just stumbled upon this and thought I add my 2 cents.
In my experience, totemo will set the correct content-type if the pgp encryption action in the rule designer is set to use PGP/MIME.
So the sender might have some influence they can take over this.
Was there a public key attached in the test mails you received?
In most cases where we don’t encounter a */signed or */encrypted content-type at the message header level, it was usually because of a third system that tried to add a disclaimer (or more recently, external mail warnings) to still encrypted/signed messages. Some systems re-encapsulate the encoded multipart in another multipart in that case.
Thanks for the extra information. The example email has a PGP public key attached (with content-type application/pgp-keys).
It looks like this resulted in changing the email to a multipart/mixed message. Perhaps Totemo tries to attach a key after encrypting the email instead of after encrypting.