This is a bit of a nasty post, growing out of 2 months of experience with this feature. First I'll explain why I think it is useless in its current form, and then I'll come to why I think it may be a fundamentally flawed idea.

It is useless, because it does not work.
While that may be a blanket statement, it is essentially true.

Ok, it does work, it even works with a PGP keyserver. The problem is that you can't know that it does, or if it does.
I found that it did work with an external email address, but not in a loopback test. It did sign all emails though.
But it does not log that anywhere, so if you have an important message that must be encrypted, you can't use it, because not only you can't know if it will encrypt it, but you can't even find out afterwards!

It does not work with keys that have multiple email addresses associated (PGP). But you can't upload the same key multiple times with single email addresses.


Now I've explained why the implementation does not work, I'll come to why I think it's a fundamentally flawed concept.

The whole point of encryption and signing is that you establish a trusted communication channel between sender and receiver.

But not only does the astaro save those keys without keyphrases and the private keys are accessible to administrators, it doesn't even verify the identity of the sender.
Anybody with access to subnets that are trusted by the astaro or with an account can use every key that is present in the system by changing his sender address.

The second obstacle is a problem of the implementation, making it useless. The first one, that the keys are not stored securely inside the system, can't be surmounted, I think.

So the whole system does not work, and shouldn't be used in any circumstance, because it lets the users (and the receivers of the signed mails) think that there is some added security which in reality does not exist.

It is possible to configure the SMTP Proxy in an insecure fashion. If you do that, you are correct that the Astaro won't refuse to encrypt/sign emails presented for relaying from authenticated users.

When used with a good mail server (we use Exchange), it's the mail server that confirms the sender's identity. When we configure the Astaro, the only item on the 'Relaying' tab that can relay off the Astaro is the mail server, so most of your objections are obviated.

I'm not sure about your concern for the certs and private keys not being secure from the administrator of the Astaro. The point of the Astaro implementation is to facilitate encryption/signing in an unobtrusive way for the users. If you have one who has the skills and need for security from the administrator, just don't create him as an 'Internal User' and have him do encryption and signing in his email client.

Cheers - Bob
PS You must have gone to university in the US - your English is better than most native speakers!

__________________
ACE V7 - Astaro Preferred Partner since V3
Addicted to my iPhone!

Thanks for your feedback. I agree to some levels that doing this type of broad encryption at the gateway has drawbacks. However the system does work when used as intended, which is to offload the need of having to educate and train each end user on how an encryption system works, and ensuring they do it when sending to certain addresses or senders. It is used throughout Astaro's customer base, for example a common implementation is when all mail from the company using Astaro and mail encryption wants to ensure all mails to "lawfirm@ourlawcompany.com" or "joe@myaccountingfirm.com" is encrypted. While for general, growing support of encryption the key harvesting is a nice feature and works well, most users load in the certs or keys of their intended recipients.

That being said, we are investigating ways to make the process even easier, and with better tracking and options. However with any system, usually the easier it gets, the more the most security-minded individual loses control. For example, the most popular clientless encryption solutions start by sending a plain-text email to the recipient informing them how to retrieve their encrypted mail, and even put the credentials in the message! This is insecure yes, but it solves the CUSTOMER problem that the acutal text or message itself is encrypted, and currently the laws and regulations they are conforming to by using encryption doesnt dissallow the transmitting of how to receive sensitive information in insecure ways, just that the information itself not be transmitted. Silly perhaps, but if it solves their problems, they are happy with it.

Thanks again for the feedback, we'll take it in account!

__________________
Angelo Comazzetto
Astaro AG
--------------------------------------------------------
Visit the KB for documentation and help (www.astaro.com/kb)
Astaro is FULLY free for home use, including all subscriptions. Download it from http://my.astaro.com

Using the ASG for email encryption moves the endpoint of the trusted channel from the users e-mail client to the ASG. This doesn't mean the concept is fundamentally flawed, you just need to do it correctly. If users who you can't trust have access to your webadmin, you shouldn't use ASG email encryption, indeed (probably, your whole security concept is flawed then).
You still have a trusted channel between your ASG and the recipient - and that is the intention of the system.
If you need security in your internal network, you need to encrypt directly in your mail client - there is no possibility to let any kind of gateway do that.