404698 2019-02-22 12:52:18 +0000 Decryption Oracle based on replying to PGP or S/MIME encrypted emails 2019-07-31 02:15:35 +0000 1 1 2 Applications kmail2 crypto unspecified Debian stable Linux RESOLVED FIXED NOR normal --- 1 jens.a.mueller+kde pim-bugs-null aacid asturm beuc dvratil faure montel nate null+samzain rdieter sknauss stupor_scurvy343 https://commits.kde.org/messagelib/ac360b3a57eacbf0542ed0800e6054db76f01398 5.11.2 0 oldest_to_newest 1839744 0 jens.a.mueller+kde 2019-02-22 12:52:18 +0000 In the scope of academic research in cooperation with Ruhr-Uni Bochum and FH Münster, Germany we discovered a security issue in KMail: An attacker who is in possession of PGP or S/MIME encrypted messages can embed them into a multipart message and re-send them to the intended receiver. When the message is read and decrypted by the receiver, the attacker's content is shown. If the victim replies, the plaintext is leaked to an attacker's email address. The root cause for these vulnerabilities lies in the way KMail (and many other mail clients) handle partially encrypted multipart messages. ----------------------------------------- *Leaking plaintext through reply/forward* ----------------------------------------- /Attacker model/: Attacker is in possession of PGP or S/MIME encrypted messages, which she may have obtained as passive man-in-the-middle or by actively hacking into the victim's mail server or gateway /Attacker's goal/: Leak the plaintext by wrapping the ciphertext part within a benign-looking MIME mail sent to and decrypted+replied to by the victim /Attack outline:/ If KMail receives a multipart email, as depicted below, it decrypt the ciphertext part(s), together with the attacker-controlled text (which may be prepended and/or appended). multipart/mixed |--- Attacker's part |--- [encrypted part to leak] +--- [Attacker's encrypted part] A benign-looking attacker's text may lure the victim into replying. Because the decrypted part is also quoted in the reply, the user unintentionally acts as a decryption oracle. To obfuscate the existence of the encrypted part(s), the attacker may add a lot of newlines or hide it within a long conversation history. A user replying to such a ‘mixed content’ conversation thereby leaks the plaintext of encrypted messages wrapped within attacker-controlled text. Please find attached a raw .eml file which depicts the issue. --------------- Countermeasures --------------- Do not decrypt emails unless the PGP or S/MIME encrypted part is the root node -- and therefore the only part -- in the MIME tree (exception: multipart/signed for encrypted-then-signed S/MIME messages). Another, potentially less secure, option would be to quote only the very first MIME part in replies. 1839745 1 118288 jens.a.mueller+kde 2019-02-22 12:52:40 +0000 Created attachment 118288 Proof-of-concept PGP 1839746 2 118289 jens.a.mueller+kde 2019-02-22 12:52:53 +0000 Created attachment 118289 Proof-of-concept S/MIME 1849273 3 dvratil 2019-04-08 16:55:35 +0000 In KMail this attack requires that user would enable "Automatic decryption of encrypted messages when viewing" option in KMail settings, which is disabled by default. Without this option enabled the user has to click on "Decrypt" on the part that the attacker wants to leak. At this point, the user will still clearly see which part of the content was encrypted and which part was not. When the user wants to reply to this decrypted message, the content would indeed get leaked to the attacker. However, I believe that at this point KMail has done enough to prevent (by not enabling auto-decryption by default) and warn (by clearly showing which part is encrypted and which not) the user so he or she could judge for themselves the potential risks when replying to the message. 1849484 4 jens.a.mueller+kde 2019-04-09 15:41:27 +0000 Things may have changed in the meantime, but for the version we tested (v5.2.3), there is no need to click on "Decrypt Message". While the plaintext is not shown to the user, if he does not explicitly click "Decrypt Message", the plaintext is still included in replies -- just re-tested for S/MIME and PGP/MIME. Note that KMail was tested in the default settings (the option "Attempt decryption of encrypted messages when viewing" was *not* set). 1849561 5 sknauss 2019-04-09 20:54:50 +0000 (In reply to Daniel Vrátil from comment #3) > In KMail this attack requires that user would enable "Automatic decryption > of encrypted messages when viewing" option in KMail settings, which is > disabled by default. As Jens already explained, this setting does not help here. This Setting only do not trigger decryption directly when you view the mail. But if you reply the mail is decrypted in anycase. And we use the same code paths for rendering the view and prepare the reply/forward. 1850137 6 aacid 2019-04-13 10:39:21 +0000 I am not sure I understand where the problem is, potentially means you need to explain it in simpler words (or that i need to learn how to read long sentences :D) Is this problem? * A sends encrypted email to B * C intercepts that email * C resends the email modified to B (adding his own reply address and some plain text) * B answers to C * C can see the original email 1850145 7 jens.a.mueller+kde 2019-04-13 12:29:02 +0000 Exactly that's the problem. Note that not only one message, but hundreds of captured messages can be wrapped and leaked with one single reply. Traditional message takeover attacks under a new identity (C) are considered as an acceptable risk in email e2e encryption because it is assumed that given the context of the message (e.g.,“Hi A, [...] Yours, B”) B can tell that this message is not originally from C and could easily discover the deception. However, using MIME wrapping, C can make a different content being displayed to B (if B does not carefully scroll down the whole message conversation) and therefore potentially trick B into replying to C. 1850523 8 aacid 2019-04-15 21:36:49 +0000 Right i can see the problem. Question is, are those kind of messages that you are suggesting to stop supporting "common" or even is there a reason for someone to be sending messages like that? Or if you get a message like this it's most probably someone trying to trick you? Because if those messages are common, stopping to work on them is going to be a pain for the people that have a valid usecase. 1850592 9 jens.a.mueller+kde 2019-04-16 09:06:50 +0000 Imho, there are no legitimate use cases for `partial encryption` in S/MIME and PGP/MIME, but it's hard to measure if such emails do exist in the wild. In case of PGP/Inline, unfortunately, every part is encrypted separately. Note that a captured PGP/MIME message can be `downgraded` to be interpreted in the context of PGP/INLINE. 1851106 10 jens.a.mueller+kde 2019-04-18 13:30:36 +0000 Update: Here's a full (public) report on the issue: https://arxiv.org/ftp/arxiv/papers/1904/1904.07550.pdf For KMail, CVE-2019-10732 was assigned for reply-based `decryption oracles`. 1851642 11 faure 2019-04-21 17:14:23 +0000 Interesting problem. Here's my feedback. - Preventing KMail from *sending* such messages would obviously be no help (one could just craft that message by hand or using another email client). - Preventing the user from replying to such a message would be very weird user experience (sorry, you are not allowed to reply to this message!) - So I guess the best solution is that when replying, we don't decrypt parts that were encrypted in the original message. I.e. if we are replying with a copy of those parts, and they were encrypted, they should be copied "as is". This would prevent any newly-added recipient from reading those, but that's fair enough I would say. I wouldn't really know how to implement this though. Might be tricky if the tree in memory only has the decrypted version. - Alternatively, KMail could say "for security reasons, these parts are going to be removed from your reply". But this also requires that we somehow know that these parts used to be encrypted in the original email. 1851728 12 faure 2019-04-22 09:31:07 +0000 About the original suggestion: "Do not decrypt emails unless the PGP or S/MIME encrypted part is the root node -- and therefore the only part -- in the MIME tree (exception: multipart/signed for encrypted-then-signed S/MIME messages)." This would mean if you attach a non-encrypted image (say, company logo) to an encrypted email, the recipient can't reply to the email anymore? I think we always want to decrypt the main text part? (fuzzy term, I don't know what the actual logic is in kmail, but I mean the text that gets quoted). 1851915 13 sknauss 2019-04-22 21:21:16 +0000 @Jens: what version did you test? You set "Debian Stable" and "5.10.3" this does not match. Debian stable has 16.04.3 aka 5.2.3. I now started to look into the issue, but I can't reproduce it with the attached messages for 18.08.3 nor for master. At least for the encrypted content to be simple text. Do I need to construct a mimetree inside the encrypted message parts? And this make totally sense, as we have already have the concept of firstTextNode inside ObjectTreeParser, that takes effect here. I added the proof-of-concept mails to our autotests: https://phabricator.kde.org/D20757 the plain.reply files are the output of the reply window. For those you have a test environment for messagelib, those can view such mails and reply/forward: GNUPGHOME=<buildpath of messagelib>/messagecore/autotests/gnupg_home/ kmail --view 404698-gpg.mbox A short explanation, how a reply/forward is created (everything in messagelib): * templateparser/src/templateparserjob constructs a new KMime::Message mMsg from a given mOrigMsg. * TemplateParserJob uses MimeTreeParser::ObjectTreeParser to get htmlContent/plainTextContent. At least for plainTextContent it is easy to follow, that only the content from first text node is used. For htmlContent it looks, like we merge different htmlNodes via messagepart.cpp:HtmlMessagePart::fix() 1851921 14 sknauss 2019-04-22 21:44:01 +0000 (In reply to David Faure from comment #11) > - Preventing KMail from *sending* such messages would obviously be no help > (one could just craft that message by hand or using another email client). ACK. > - Preventing the user from replying to such a message would be very weird > user experience (sorry, you are not allowed to reply to this message!) jepp bad UX. > - So I guess the best solution is that when replying, we don't decrypt parts > that were encrypted in the original message. I.e. if we are replying with a > copy of those parts, and they were encrypted, they should be copied "as is". > This would prevent any newly-added recipient from reading those, but that's > fair enough I would say. > I wouldn't really know how to implement this though. > Might be tricky if the tree in memory only has the decrypted version. > > - Alternatively, KMail could say "for security reasons, these parts are > going to be removed from your reply". But this also requires that we somehow > know that these parts used to be encrypted in the original email. Both things are not that hard to solve. We have MimeTreeParser::ObjecttreeParser that returns a MessagePart tree. This is a tree, where only visual interesting nodes of the Mime messages with the additional information of each node, about their encrypted status, used keys etc... To get an idea about those trees look at mimetreeparser/autotests/data/*tree files, these are the MessagePart tree for the corresponding mbox. Also TemplateParser, that is responsible for creating a reply/template, uses MimeTreeParser::ObjecttreeParser, so we are able to filter out bad nodes. 1852779 15 jens.a.mueller+kde 2019-04-26 10:09:00 +0000 @David: This would mean if you attach a non-encrypted image to an encrypted... Absolutely, such an email could not be decrypted anymore if you follow our suggestions (or had to be manually decrypted on the command line). While this may seem a bit harsh, we have not seen any mail client that allows to send such "partially encrypted" emails (e.g., with unencrypted attachments), and I think handling such edge cases can become a security nightmare. Either the whole mail is encrypted or it's not, everything else gives a false sense of security, imho. However, I see the developer's perspective and the and the fear of potentially breaking things, too. I guess a rule like "in case of an encrypted, multipart email, reply only with the first part" *should* be fine too. @Sandro: We originally tested in version 5.2.3 on Debian 9.8 (stretch). This version is probably outdated by now. 1852785 16 sknauss 2019-04-26 11:00:21 +0000 (In reply to Jens Mueller from comment #15) > @David: This would mean if you attach a non-encrypted image to an > encrypted... > > Absolutely, such an email could not be decrypted anymore if you follow our > suggestions (or had to be manually decrypted on the command line). While > this may seem a bit harsh, we have not seen any mail client that allows to > send such "partially encrypted" emails (e.g., with unencrypted attachments), > and I think handling such edge cases can become a security nightmare. Either > the whole mail is encrypted or it's not, everything else gives a false sense > of security, imho. One client that supports sending encrypted mails with unencrypted attachment is kmail (but you need to do it explicitly). One common use case, of such partial encrypted mails are mails forwarded via Mailman. Mailman adds a non encrypted footer to each email. So not supporting these mails make would break my workflow. This was the reason, why I fixed a several things, because I didn't wanted to see this footer in the reply ;D And I see a big difference between displaying such broken mails and replying. > However, I see the developer's perspective and the and the fear of > potentially breaking things, too. I guess a rule like "in case of an > encrypted, multipart email, reply only with the first part" *should* be fine > too. I think so, too, that reply to only one part you be fine. > @Sandro: We originally tested in version 5.2.3 on Debian 9.8 (stretch). This > version is probably outdated by now. yes! Did you tested any other version? 1855745 17 sknauss 2019-05-12 21:59:21 +0000 Git commit d397aa46e809203c94e31891caac57affac746d9 by Sandro Knauß. Committed on 12/05/2019 at 20:34. Pushed by knauss into branch 'Applications/19.04'. Test mails for Decryption Oracle based on replying to PGP or S/MIME. Summary: In order to make sure we never add a Decryption Oracle add test mails to TemplateParser. Reviewers: #kde_pim, aacid, dfaure Subscribers: kde-pim Tags: #kde_pim Differential Revision: https://phabricator.kde.org/D20757 A +120 -0 templateparser/autotests/data/404698-gpg.mbox A +51 -0 templateparser/autotests/data/404698-gpg.mbox.plain.reply A +88 -0 templateparser/autotests/data/404698-smime.mbox A +51 -0 templateparser/autotests/data/404698-smime.mbox.plain.reply https://commits.kde.org/messagelib/d397aa46e809203c94e31891caac57affac746d9 1855754 18 120026 sknauss 2019-05-12 22:10:25 +0000 Created attachment 120026 html mail with two images embeded. There is one question, how we should handle forwards with embedded images. We have a testcase with two images embedded (see attachment), that are added to the forwarded message. IMO this is not a security issue, as we do not parse those two images (aka do not encrypt them) and just copy them like they were sent over the wire. So we can't leak private information. 1855757 19 sknauss 2019-05-12 22:14:40 +0000 Git commit a58286aec8f300d78c570726924baa91d9a22771 by Sandro Knauß. Committed on 12/05/2019 at 21:48. Pushed by knauss into branch 'Applications/19.04'. Merge branch 'CVE-2019-10732' into Applications/19.04 Fixes the CVE-2019-10732, with additional tests, to make sure, we fixed the CVE completely. FIXED-IN: 5.11.2 CCMAIL: security@kde.org https://commits.kde.org/messagelib/a58286aec8f300d78c570726924baa91d9a22771 1855758 20 sknauss 2019-05-12 22:14:40 +0000 Git commit 8f9b85b664be0987014c5d2485e706ab5a198e1b by Sandro Knauß. Committed on 12/05/2019 at 20:37. Pushed by knauss into branch 'Applications/19.04'. Make unexpected data leak harder via reply. ObjectTreeParser.htmlContent/plainTextContent may concats different encrypted parts without the user noticing it. That would lead to a Decryption oracle. We have already a logic to find the topleveltextNode in MimeTreeParser, this does not take HTML nodes into account nor that TEXT nodes may have several PGP Inline blocks. That plaintextContent for HtmlMessagePart is not return QString(), that bubbled up by testing the stuff. M +5 -0 mimetreeparser/src/messagepart.cpp M +1 -0 mimetreeparser/src/messagepart.h A +31 -0 templateparser/autotests/data/openpgp-inline-space.mbox A +1 -0 templateparser/autotests/data/openpgp-inline-space.mbox.html.reply A +1 -0 templateparser/autotests/data/openpgp-inline-space.mbox.plain.reply M +46 -14 templateparser/src/templateparserjob.cpp https://commits.kde.org/messagelib/8f9b85b664be0987014c5d2485e706ab5a198e1b 1855759 21 sknauss 2019-05-12 22:14:43 +0000 Git commit ac360b3a57eacbf0542ed0800e6054db76f01398 by Sandro Knauß. Committed on 12/05/2019 at 20:37. Pushed by knauss into branch 'Applications/19.04'. Decryption Oracle based on forwarding PGP or S/MIME mails (CVE-2019-10732) Summary: Add test coverage for mail forwarding. Test Plan: all tests passes forward (text/html): [x] PGP Mime text [x] PGP Mime html [x] S/MIME [x] PGP inline Reviewers: #kde_pim, vkrause, aacid, dfaure Subscribers: kde-pim, security-team Tags: #kde_pim Differential Revision: https://phabricator.kde.org/D20847 A +72 -0 templateparser/autotests/data/404698-gpg-attachments.mbox A +66 -0 templateparser/autotests/data/404698-gpg-attachments.mbox.forwarded.mbox A +1 -0 templateparser/autotests/data/404698-gpg-attachments.mbox.html.reply A +5 -0 templateparser/autotests/data/404698-gpg-attachments.mbox.plain.reply A +83 -0 templateparser/autotests/data/html-attachment1.mbox.forwarded.mbox A +28 -0 templateparser/autotests/data/html-attachment2.mbox.forwarded.mbox M +162 -0 templateparser/autotests/templateparserjobtest.cpp M +9 -0 templateparser/autotests/templateparserjobtest.h https://commits.kde.org/messagelib/ac360b3a57eacbf0542ed0800e6054db76f01398 1862350 22 beuc 2019-06-12 14:59:32 +0000 Hi, As part of the Debian LTS project, I'm trying to fix this vulnerability in Debian Jessie, which ships kdepim 4.14.1. I'm attempting to backport https://commits.kde.org/messagelib/8f9b85b664be0987014c5d2485e706ab5a198e1b but the API is very different, I'm not even sure there are available functions to expose the MIME parts and extract their quotable content independently. Do you think this is doable? 1862386 23 beuc 2019-06-12 18:57:26 +0000 I wrote something cruder but that works with the 404698-* messagelib test cases: https://www.beuc.net/tmp/kdepim-CVE-2019-10732.patch This should be a good compromise, let me know if I missed something. I plan to upload an update shortly, probably next week :) 1866082 24 sknauss 2019-06-28 15:38:27 +0000 (In reply to beuc from comment #23) > I wrote something cruder but that works with the 404698-* messagelib test > cases: > https://www.beuc.net/tmp/kdepim-CVE-2019-10732.patch > This should be a good compromise, let me know if I missed something. > I plan to upload an update shortly, probably next week :) The code looks like it should be enough. But the surrounding code has changed a lot between 4.14.1 and had less tests etc. It may be that there are other things to fix. 1872141 25 null+samzain 2019-07-31 02:15:35 +0000 118288 2019-02-22 12:52:40 +0000 2019-02-22 12:52:40 +0000 Proof-of-concept PGP 00-pgp-mime-reply-mix-crlf.eml message/rfc822 1996 jens.a.mueller+kde U3ViamVjdDogVGVzdGNhc2UgJ3JlcGx5LW1peC1jcmxmJyAoUEdQL01JTUUpClRvOiBicnVjZXdh eW5lNDVAd2ViLmRlCkZyb206IGJydWNld2F5bmU0NUB3ZWIuZGUKTUlNRS1WZXJzaW9uOiAxLjAK Q29udGVudC1UeXBlOiBtdWx0aXBhcnQvbWl4ZWQ7IGJvdW5kYXJ5PSJCT1VOREFSWSIKCi0tQk9V TkRBUlkKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluCgpQbGVhc2UgcmVwbHkgdG8gdGhpcyBtZXNz YWdlCi4KLgouCi4KLgouCi4KLgouCi4KLgouCi4KLgouCi4KLgouCi4KLgouCi4KLgouCi4KLgou Ci4KLgouCi4KLgouCi4KLgouCi4KLgouCi4KLgouCi4KLgouCi4KLgouCi4KLgoKLS1CT1VOREFS WQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9lbmNyeXB0ZWQ7IHByb3RvY29sPSJhcHBsaWNhdGlv bi9wZ3AtZW5jcnlwdGVkIjsgYm91bmRhcnk9IkRFTElNSVRFUiIKCi0tREVMSU1JVEVSCkNvbnRl bnQtVHlwZTogYXBwbGljYXRpb24vcGdwLWVuY3J5cHRlZAoKVmVyc2lvbjogMQoKLS1ERUxJTUlU RVIKQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9vY3RldC1zdHJlYW07IG5hbWU9ImVuY3J5cHRl ZC5hc2MiCkNvbnRlbnQtRGlzcG9zaXRpb246IGlubGluZTsgZmlsZW5hbWU9ImVuY3J5cHRlZC5h c2MiCgotLS0tLUJFR0lOIFBHUCBNRVNTQUdFLS0tLS0KCmhRRU1BK1hoQklabDMraTVBUWdBbVI0 Vm40VWh0K09zMjRCUStHV1Fqa0RDa25mRWxoUnhHSUpjNWhEd3FnNDcKK2Nnc05Idmh6VDdFSkc4 UW5TK1RPZHdOd21BeTZlWXVtV01SeUI2RGl2T3psTnc4V0wvbTBWbjFHLzZhMytWUQo4VHZmSkVS TWVLaVQrQ0grdFVPQnlWYkgrVGtZS3pFazFiWm50MWhzWEIwaGZvUEo0M3RZSnMzdzlQQlM1Q2Y1 CjNyakY1cHEvTG14bkhtUEcrblZqRkhkeWFlRzFvbDlITXdZL1RzRkJTSlpVaSt0a2pFNkl0a0Vv TDN1TXBkbkIKTGtkUFVaYnpPV280c0ZnUDIrMmZxM0xJZU5Pc3NVenNXdHBmZmJob1M5OUgzNjYr d09SMWJsWlZ3SzBIUCtnYwp4dHUwaTRyelEyZGZoRjRhSUJjTjJxVzQzeENZRHIzY1VWemxjT0dt Uk5MQTJ3SFl0S0dFZFJKc2xYRHIxc2Z0CmdaNTl3OVlnZTFENHRYS3YwZ1NpNDJqYTkzQVFjU0N5 MHlTZVpxeFRpRmhaaEFrNlVwcVVFcGJsWHdTVXpoNDkKRkQ5YThFM0twSTBqMVlaVUNtOEFuOHNP VHhLd2VNSFJvbSs0U05pamtSNnBDLzkrcC9JcXlTUXRBMHZkMzZmNwpRMzY1OVQ3Z1Fyb3JpcXFl dXlKOEtHSnBGN29mcHVseWdCTnh4UmkvRkI5a0ZFWndHOUp3WjlzMGhnNGR3ZE9RCmkwaDdVc3ZP T09sTXYwUnV0a2lRd0src2k3aEdOZllDWHFhenpXM0d5a0dTSVFINXBISmttYloyRDdtbGplNU8K U0o0RkpEaXFFVmpHYVhUWS8yTkVDZHBCcTRjNitSZVVXb1V2Z2RyMUcrMWQ5UTFTMmhMTFNybVRh a3dqU0lqWAplcjBLS29IWHg3N1FvdmdiVktsbGVTVWd3ZDZVTTZDRmUvS3htYWdIRTFNN1NoK0hF VldtblFaNUlYVDdTQWVtCjU1TjhwbmVvcTFGejJRZWk4NEE5K3hQSk9kTEpSTWZpeEtlUU5RMk4w d0hZQzFCYUxITGVoVVg0UU0vaHE4eVUKQzVYUEpwYXVPOG5yclpiYjJBNU1YRzcyY21FUzhKejdl OFZMU3owTytVMm1NZy81bXJrbjBuQUdUUVVDMjU3SwppazYzMDdwN1pDbFIwT0ZxdUE9PQo9Y0xs WQotLS0tLUVORCBQR1AgTUVTU0FHRS0tLS0tCgotLURFTElNSVRFUi0tCgotLUJPVU5EQVJZCgot LUJPVU5EQVJZCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L2VuY3J5cHRlZDsgcHJvdG9jb2w9ImFw cGxpY2F0aW9uL3BncC1lbmNyeXB0ZWQiOyBib3VuZGFyeT0iREVMSU1JVEVSIgoKLS1ERUxJTUlU RVIKQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9wZ3AtZW5jcnlwdGVkCgpWZXJzaW9uOiAxCgot LURFTElNSVRFUgpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL29jdGV0LXN0cmVhbTsgbmFtZT0i ZW5jcnlwdGVkLmFzYyIKQ29udGVudC1EaXNwb3NpdGlvbjogaW5saW5lOyBmaWxlbmFtZT0iZW5j cnlwdGVkLmFzYyIKCltBVFRBQ0tFUlMgRU5DUllQVEVEIE1FU1NBR0VdCgotLURFTElNSVRFUi0t Cg== 118289 2019-02-22 12:52:53 +0000 2019-02-22 12:52:53 +0000 Proof-of-concept S/MIME 00-smime-reply-mix-crlf.eml message/rfc822 1602 jens.a.mueller+kde U3ViamVjdDogVGVzdGNhc2UgJ3JlcGx5LW1peC1jcmxmJyAoUy9NSU1FKQpUbzogYnJ1Y2V3YXlu ZTQ1QHdlYi5kZQpGcm9tOiBicnVjZXdheW5lNDVAd2ViLmRlCk1JTUUtVmVyc2lvbjogMS4wCkNv bnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOyBib3VuZGFyeT0iQk9VTkRBUlkiCgotLUJPVU5E QVJZCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbgoKUGxlYXNlIHJlcGx5IHRvIHRoaXMgbWVzc2Fn ZQouCi4KLgouCi4KLgouCi4KLgouCi4KLgouCi4KLgouCi4KLgouCi4KLgouCi4KLgouCi4KLgou Ci4KLgouCi4KLgouCi4KLgouCi4KLgouCi4KLgouCi4KLgouCi4KLgouCi4KCi0tQk9VTkRBUlkK Q29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9wa2NzNy1taW1lOyBuYW1lPSJzbWltZS5wN20iOyBz bWltZS10eXBlPWVudmVsb3BlZC1kYXRhCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IGJhc2U2 NAoKTUlBR0NTcUdTSWIzRFFFSEE2Q0FNSUFDQVFBeGdnSEpNSUlCeFFJQkFEQ0JyRENCbHpFTE1B a0dBMVVFQmhNQ1IwSXhHekFaCkJnTlZCQWdURWtkeVpXRjBaWElnVFdGdVkyaGxjM1JsY2pFUU1B NEdBMVVFQnhNSFUyRnNabTl5WkRFYU1CZ0dBMVVFQ2hNUgpRMDlOVDBSUElFTkJJRXhwYldsMFpX UXhQVEE3QmdOVkJBTVRORU5QVFU5RVR5QlNVMEVnUTJ4cFpXNTBJRUYxZEdobGJuUnAKWTJGMGFX OXVJR0Z1WkNCVFpXTjFjbVVnUlcxaGFXd2dRMEVDRUdWbnFrczlNK1ZNQVVXWVRmSmo1bVl3RFFZ SktvWklodmNOCkFRRUJCUUFFZ2dFQUkzY2tvUDczZ2NaSzhlNHpKUnVyTm1DTUFQS3lsMkVtNzNE OE1YbXhwS1c5a1phNXNhR3pqTGNuNHF2WQpwYW8xVFRFNlJXalo3SEZTNHZrUldORzJnSHBJbURh L1VjWld0K3NVV0xLeDE3UzkwU1NZQlgxNTNUWUFOL01lancvSHpIOUcKN3NuK1dSZUI5bFJncFdL SngvWW9Pa3JvZjdnbFVpSjRvbHJKMGMvZm1INzBQZlJickxWajZUSkpCZGw1VzljMVI0Tk1DWUNU CjdiMFgvb3BwdElkZXNLaEw0OGt0MnAzbXFDWHJFSVJhY2lwU0lFeXE3QjlLMVdMRzBpclNJMThx dXN4UUQ1YlptTXJha2Z1RwpnajBqL1lpRG5JVGxBRGZzZUEzMnZpTXY2R3F1WWgwVUFiRTR5eDln MFEvdWFWZFBFVlpLbmRaT2w1SjcxYWtuV1RDQUJna3EKaGtpRzl3MEJCd0V3RkFZSUtvWklodmNO QXdjRUNBTEFLTWliZ0REeW9JQUVnYkFsM3o2YmxwTy9QdmljcDN3MkZOVmJodGhhCkZiU3hBSVZD TE9VVkxXbzlLajJsaEVsc29PcGhjdkN3TWZoRm1YNlU0dkxiUzVGMWRwSmxRVm1iV29KUzlHcUpx aUd6Y3E2egozRGU4cXUwM0NDNjdFOWpESUtDNDYwT3RGeENyKzBBQ0tidmxqd1NvUmh3a0E5ZjB1 OW9OWWVJTUlRQW9tRkZJQytIcDEvcm8KUWl6SG9FL09jSXBWU0ttb2dzcDVlTVhjcWtVZU1zS0hx Z0M4TWNUNTExQVFSSDAzeTZuQStDeEpMYnMydTRvN1BBUUlJbFNlClF6WmNnSlVBQUFBQUFBQUFB QUFBCgotLUJPVU5EQVJZCkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vcGtjczctbWltZTsgbmFt ZT0ic21pbWUucDdtIjsgc21pbWUtdHlwZT1lbnZlbG9wZWQtZGF0YQpDb250ZW50LVRyYW5zZmVy LUVuY29kaW5nOiBiYXNlNjQKCltBVFRBQ0tFUlMgRU5DUllQVEVEIE1FU1NBR0VdCgotLUJPVU5E QVJZLS0K 120026 2019-05-12 22:10:25 +0000 2019-05-12 22:10:25 +0000 html mail with two images embeded. html-attachment2.mbox application/mbox 859 sknauss RnJvbSBtYWlsbGlzdHNAd2hhdHRmLmNvbSAgVHVlIEp1bCAwNSAxOToyMDo1OCAyMDExClJldHVy bi1wYXRoOiA8bWFpbGxpc3RzQHdoYXR0Zi5jb20+CkVudmVsb3BlLXRvOiBtYWlsbGlzdHNAd2hh dHRmLmNvbQpEYXRlOiBNb24sIDI0IE9jdCAyMDE2IDExOjUzOjAwICswMTAwClRvOiBtYWlsbGlz dHNAd2hhdHRmLmNvbQpGcm9tOiBtYWlsbGlzdHNAd2hhdHRmLmNvbQpNSU1FLVZlcnNpb246IDEu MApTdWJqZWN0OiBUZXN0CkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L3JlbGF0ZWQ7IGJvdW5kYXJ5 PSItLS0tPV9QYXJ0XzIwMzI0XzEwNTQ2NjkxODMuMTQ3NzMwNjM4MDMwMSIKTUlNRS1WZXJzaW9u OiAxLjAKCi0tLS0tLT1fUGFydF8yMDMyNF8xMDU0NjY5MTgzLjE0NzczMDYzODAzMDEKQ29udGVu dC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9IlVURi04IgpDb250ZW50LVRyYW5zZmVyLUVuY29k aW5nOiA3Yml0Cgo8aHRtbD48aGVhZD48L2hlYWQ+PGJvZHk+SFRNTCBUZXh0PC9ib2R5PjwvaHRt bD4KLS0tLS0tPV9QYXJ0XzIwMzI0XzEwNTQ2NjkxODMuMTQ3NzMwNjM4MDMwMQpDb250ZW50LVR5 cGU6IGltYWdlL3BuZwpDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFtZT0i aW1hZ2UxLnBuZyIKQ29udGVudC1JRDogY2lkMQoKSW1hZ2UxCi0tLS0tLT1fUGFydF8yMDMyNF8x MDU0NjY5MTgzLjE0NzczMDYzODAzMDEKQ29udGVudC1UeXBlOiBpbWFnZS9wbmcKQ29udGVudC1E aXNwb3NpdGlvbjogYXR0YWNobWVudDsgZmlsZW5hbWU9ImltYWdlMi5wbmciCkNvbnRlbnQtSUQ6 IGNpZDIKCkltYWdlMgotLS0tLS09X1BhcnRfMjAzMjRfMTA1NDY2OTE4My4xNDc3MzA2MzgwMzAx LS0KCg==