Do you recognize a good idea when you see one? We want to hear from you!
Header Image

I suggest you ...

Mail Security: Granular Encryption Control

If a user is enabled to use mail encryption there's currently only the option to sign all of their outgoing mail or nothing.

I'd like to have another option to sign only mails for listed recipients (single [billg@microsoft.com] or domain [*@astaro.com])

173 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    MicrosaftMicrosaft shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    20 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • James BrownJames Brown commented  ·   ·  Flag as inappropriate

        How can I give this more than 3 votes!

        Seriously, given how many recipients struggle with signed or encrypted emails, this is really required.

        BTW Anonymous, {plain} still works fine for me.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Hi Guys, we had our setup running with these flags since months. Now it does not work anymore. Looks like this was removed with one of the latest updates. Can someone confirm this please?

      • Claus GratzlClaus Gratzl commented  ·   ·  Flag as inappropriate

        Adding email encryption to the user selfcare would be very useful to reduce support requests. Why not enabling users to manage their encryption settings and PGP keys themselves?

      • John VeldhuisJohn Veldhuis commented  ·   ·  Flag as inappropriate

        Combine e-mail security, data leakage prevention and e-mail encryption.
        Have Data Control rules, like block, allow encrypted, encrypt automatically, allow unencrypted, etc. There no DLP tab somewhere in the console yet, so...

      • James BrownJames Brown commented  ·   ·  Flag as inappropriate

        Can we just have an 'Exceptions ' tab in the Mail Security/Encryption section. (Or maybe put it in the Options section). Here you can list the recipient addresses that will receive plain, unsigned and unencrypted mail.

        We have two customers do can't reply to any emails we send them, unless we put {plain} at the start of the subject.

      • Stephan FietzekStephan Fietzek commented  ·   ·  Flag as inappropriate

        There should also be things like:
        - control over the subject rewriting feature (Disable things like "(PGP: Plain)" in the subject of each mail).
        - remove control-keywords like {sign} and {crypt} from the outgoing mail or use another method of controlling the encryption
        - logging (feature request opened)
        - S/MIME domain certs (feature request opened)
        - importing internal users from AD/Exchange manually or even better automatically
        - ...

        I really hope Astaro will develop this great feature to an even better one.

      • DirkDirk commented  ·   ·  Flag as inappropriate

        Sascha wrote in the comment:
        "As far as I know Astaro still allows the use of some (undocumented) keywords in the beginning of the mails subject to force encryption / signing of mails. AFAIK the keywords are:

        {plain} or {clear} -> Mail will not be signed or encrypted
        {sign} -> Mail will be signed
        {crypt} -> Mail will be encrypted

        Encryption user still has to be created on AxG, but all automatic encr. and sign. functions have to be set to disabled."

        If it works, this function should be officially integratet in the filter options!

      • Volker KullVolker Kull commented  ·   ·  Flag as inappropriate

        I´m with Thomas Weber ! It is the kind of information that requires encryption. If the user set {sign} into the mails subject to force encryption / signing of mails, the encryption-system should follow this order and do not send these emails if there is no certificate of recipient available.(with non delivery message to sender).

      • Jürgen RothJürgen Roth commented  ·   ·  Flag as inappropriate

        The X-Header solution should be fine; a policy at the gateway will be really more flexible.
        We need the ability to define single users and domains where to send encrypted mails and also what kind of encryption is to use. If this will be enlarged with a whitelist and a blacklist then the astaro will have the best flexibility.

      • thw-asg320HAthw-asg320HA commented  ·   ·  Flag as inappropriate

        I really like the X-Header idea. And this header has to be obeyed. If a receipient of the mail does not have a Cert or Key otn the AxG, the mail must not be sent to that specific receipient. It is the kind of information that requires encryption. Therefore the AxG must not overrule the senders decision under no circumstances.

      • James BrownJames Brown commented  ·   ·  Flag as inappropriate

        Why is this not documented?

        I have mailing lists that will not accept my signed and encrypted emails (it makes the message too large) and some recipients are too clueless to add the certificate to their system. Each time I have to log into Astaro and turn off encryption, send the email, then turn it back on.

        So I'll just try with "{plain}" in the subject next time and see if it works.

        But you really need to have the keyword dropped form the subject so that the recipient doesn't see it.

        And the keywords probably should be able to be changed via the Web interface.

      • MicrosaftMicrosaft commented  ·   ·  Flag as inappropriate

        Can confirm that {sign} at the beginn of the subject forces the signature (if user is enabled) - keyword will remain at the subject.

        Good to know that there is a way to force, but still would prefer the "listed receipients" option!

      • Christopher AmatulliChristopher Amatulli commented  ·   ·  Flag as inappropriate

        Thats a neat feature if it exists, but modifying the subject is not the best practice. Cases where i can allow the user to enter a tag (usually from a custom button), which is hidden from plain site to cause the encryption to occur are less invasive and prone to typo's.

      • Sascha ParisSascha Paris commented  ·   ·  Flag as inappropriate

        As far as I know Astaro still allows the use of some (undocumented) keywords in the beginning of the mails subject to force encryption / signing of mails. AFAIK the keywords are:

        {plain} or {clear} -> Mail will not be signed or encrypted
        {sign} -> Mail will be signed
        {crypt} -> Mail will be encrypted

        Encryption user still has to be created on AxG, but all automatic encr. and sign. functions have to be set to disabled.

        I haven't tested it myself, so give it a try. If it works, please confirm here...

      • Christopher AmatulliChristopher Amatulli commented  ·   ·  Flag as inappropriate

        I'd like this to be expanded to rule based encryption and transport control... for example, user a sends to company b, encrypt it and require a specific transport (TLS). This should be able to be configured for sender, recipient, subject and a mail property (x-header). To give an example, in exchange i can tag a message with an x-header based on a perticipant of the mail. when that mail passes the gateway, i want to have it encrypted.

      • jmmacipjmmacip commented  ·   ·  Flag as inappropriate

        Cisco ironport already implements this using rules like if message subject begins with "confidential" then the message gets encrypted, it uses an intermediate web site to allow the recipient to open the message after registering.

      • StoomarooStoomaroo commented  ·   ·  Flag as inappropriate

        Agreed - smells like a bad IBM product polemic here, All or none. People cheer the day that "Some" appears on the horizon.

      • andreandre commented  ·   ·  Flag as inappropriate

        Why couldnt the confidentiality factor specified in the mail client (like Outlook, Thunderbird etc) be used?

      • WolleDWolleD commented  ·   ·  Flag as inappropriate

        Maybe it's possible to create several certificates per internal user and define a whitelist for every certificate. So the system can choose the certificate to use depending on the internal user and the recipient (match with whitelist from a certificate) or send the email unsigned/unencrypted (no matching at all).

      • Bob AlfsonBob Alfson commented  ·   ·  Flag as inappropriate

        Interesting idea, Microsaft. It could be a combination of two lists. If the recipient matches any pattern in the blacklist, don't sign the email, if the recipient matches any pattern in the whitelist, sign the email.

      Feedback and Knowledge Base