On 04/20/2018 06:08 PM, Martijn Brinkers wrote:
> Opaque signed are signed message but in encoded form and require a mail
> client that supports S/MIME. Clear text signed messages can be read with
> a non S/MIME aware mail client. Outlook opaquely signs a message before
> encrypting it.
> Can you check with a mail client that supports S/MIME (Thunderbird,
> Outlook etc.) whether you can read the message?
> If the message is opaquely signed, the "solution" is to have ciphermail
> remove the signature. The result in then a normal message.
Looked good in first tests.
Thanks for helping out.
I have an issue with the decryption of S/MIME mails, and hope someone
can be of help.
To be honest I did not got very deep down the rabbit hole with this one,
as I expect it to be a common problem someone else might already have
S/MIME mail is decrypted but given back to the mail queue as an empty
mail with an attachment called "smime.p7m". This attachment includes the
message in plain and certificate information. But this does not happen
with all S/MIME encrypted mails.
Version: 3.3.1-0. Built: 2017-10-07-08:36.
I guess this might be related to mails which are signed\encrypted by a
local client and the corporate exchange server adds corporate text
signatures to that mail. ( like the "think before print " or legal
Looking into the mails after ciphermail has decrypted them shows the
Mails that get decrypted to empty message and "smime.p7m" attachment
Mails decrypted correctly:
Thanks in advance for any hint/help.
Am 13.04.18 um 12:00 schrieb users-request(a)lists.djigzo.com:
> The DLP patterns are a sender only property. That means that only the
> DLP patterns configured for the sender are taking into account. The main
> reason this was designed to be a sender only setting is that it's
> unclear how to handle recipient specific DLP rules if there are multiple
> recipients of a message. You can configure the DLP rule for the sender.
> However that means that if the message is sent to some other domain by
> that sender that the DLP fires as well. If you do not want that you can
> disable DLP checking by default for all domains and only enable it for
> the sender and recipient domain you want the rule for. You might get
> more flexibility by editing the xml mail flow file though.
thanks for your answer; but this wasn't my question ;-)
my question was: I'm looking for a way that will drop the delivery for
outgoing mails NOT having the word 'redfox:' in the body, something like
a inverted badword. Is there something in place to build a rule like this?
Hi Martijn, hi list.
first of all: thanks for this great gateway :-)
I wonder how to deal with the regex-engine within the DLP.
What I'm trying to achieve is, that mails to a specific domain will be
blocked when a special word (classification: *whatever*) is missing.
I tried this as pattern; but it turns out that this isn't working:
could someone give me little hind?
thanks in advanced + best gegards,