17 comments

Add a comment…

Sign in

prestine

Your email address

Check!

invalid email

(thinking…)

Reset

or sign in with

• 
• 

UserVoice password

Forgot password?

Create a password

Your name

I agree to the terms of service

Signed in as (Sign out)

Close

Close

Post comment Submitting...

• John Veldhuis commented  ·  October 3, 2012 2:56 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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 Brown commented  ·  June 14, 2012 9:58 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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 Fietzek commented  ·  June 22, 2011 6:11 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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.

• Dirk commented  ·  May 30, 2011 7:03 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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 Kull commented  ·  June 6, 2010 6:54 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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 Roth commented  ·  June 3, 2010 11:57 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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-asg320HA commented  ·  May 25, 2010 7:47 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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 Brown commented  ·  December 16, 2009 9:47 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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.

• Microsaft commented  ·  November 5, 2009 10:56 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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 Amatulli commented  ·  November 4, 2009 12:32 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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 Paris commented  ·  November 4, 2009 8:25 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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 Amatulli commented  ·  November 3, 2009 6:07 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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.

• jmmacip commented  ·  October 15, 2009 1:19 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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.

• Stoomaroo commented  ·  October 7, 2009 4:56 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

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

• andre commented  ·  October 2, 2009 5:36 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

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

• WolleD commented  ·  June 22, 2009 2:24 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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 Alfson commented  ·  May 5, 2009 3:28 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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.