Re: Google/Postini and Ironport Javascript Issue

jwiegert1 · ‎10-17-2011

I can't find anything on this site about the issue, but I did get an email about it. I have had this JavaScript issue with a few sites. Is there any way to query the Postini SMTP servers before sending an email? And then generate an alert to the user that the mail may have not gone through?

Dear Cisco IronPort Customer,

Cisco has learned of an issue impacting delivery of encrypted email (PXE envelopes) to recipients whose email is filtered by Google Postini.

On Thursday, October 6th, Google made a change to their security rules to block all emails containing JavaScript. The explanation provided by Google was that JavaScript represents a security threat. Cisco’s usage of JavaScript in encrypted email (PXE envelopes) enhances usability and security for its users.

Whom does it affect?
This affects our encryption customers who send encrypted mail (PXE envelopes) to their customers who use Google. Encrypted emails (PXE envelopes) get blocked. The only way for Cisco’s customers to find out that business critical emails are impacted is via manual business to business contact.

What is Cisco doing?
JavaScript plays a key role in ensuring the security and enhancing usability of encrypted mail, thus eliminating it from PXE envelopes is highly undesirable. At this point, Google is unwilling to change its policy of blocking all messages containing JavaScript.
Cisco continues to work with Google to address this issue.

What should customers do?
Google will only respond to its own customers. If you are experiencing issues with delivery of secure messages to Google customers, we ask that you have your recipients escalate the issue to Google.
Additionally, to help us track this situation, please contact Cisco IronPort Customer Support if you are impacted.

Andreas Mueller · ‎10-19-2011

Hello jwiegert1,

there is no way for the appliance to figure out if a destination uses filtering by Postini or not, so configuring an alert would require that you are aware which of your recipient domaains have that kind of filtering enabled. For these you'd add a condition in the filter that enables encryption and sends a note to the sender. More important though as the note states is to inform your business partners to get in contact with Google/Postini, or to whitelist your domain.

Regards,

Andreas

macklinmc · ‎10-24-2011

Not definitive of course but Postini's instructions on TLS connections is that the IP ranges 64.18.0.0/20 and 207.126.144.0/20 are theirs and their MX records for clients always fall in that range.

For awhile until a permanent solution is determined, any outgoing SMTP session to one of those IPs is a Postini corporate client. Gmail looks like 209.85.128.0/17 and 74.125.0.0/16. I'm guessing Gmail is likewise affected.

Not sure it's possible to code that in a C-series. Not familiar enough with IEA/PXE yet to know if it can detect it. We're just planning a move to IEA/PXE and sort of wondering if Cisco will do more than tell us to ask clients to whitelist us. Does Gmail have a customer service desk so I can ask to be whitelisted for all of Gmail, call someone for each email address? More likely we're out of luck.

IEA/PXE does have a webmail feature but I don't want to maintain thousands of mailboxes that may be single use.

I'm hoping Cisco commits to changing the Java to an HTML front end with the code back at the server.

Anxiously awaiting news from Cisco.

Jason Meyer · ‎10-24-2011

Our environment is sending e-mails to @gmail.com and thus far have had none bounce back.

What's the current status of this?

Anyone seeing rejections from Google?

Jason Meyer

Andreas Mueller · ‎10-24-2011

Jason,

the rejections only occur on hosts that use the Postini filtering network as a prefilter, gmail itself seems to use a different approach. So that's why gmail is currently not affected by this issue.

Regards,

Andreas

macklinmc · ‎10-25-2011

Thanks for the clarification. That's a bit of good news for sure.

We're doing TLS with Postini clients and likely wouldn't use the Secure Envelope for them much. Gmail is a much larger issue for us to communicate securely with customers. Still, the concept of sending Javascript in an email could be a long term issue. we don't accept it in our gateway and generally try to convert Secure Envelope usage to B2B TLS. The Gmail, Hotmail, etc. services are the main targets for us to use IEA/PXE.

Andreas Mueller · ‎10-25-2011

Hello Macklin,

I agree with you that Javascript in emails does not make much sense, as it is a security threat and therefore disabled in basically all email clients that support HTML mail. However, the secure Envelope comes as an attachment and not as HTML message, for exact that reason. So the Java/Javascript does not reside within the email body, and therefore should not be considered to be more dangerous than other attachments containing script or code.

Regards,

Andreas

Jason Meyer · ‎10-26-2011

Thanks for the information, the part that we are struggling with is we have no idea who is using Postini, so we are basicaly waiting for the calls to start coming in from our users indicating problems.

Any thoughts on that?

Or any news on Google changing it's mind?

jwiegert1 · ‎10-28-2011

We have had the issue with two places so far. One had to whitelist us and the other we have a workaround. I don't believe Gmail use the same Postini system as companies would get. I tested it to my Gmail account and had no issues. Cisco does need to keep us updated.

mgkramer99 · ‎03-12-2012

Are people still seeing issue with this?

We just turned on auto-encrypt and are starting to receives complaints that messges are not arriving in recipients inbox nor their junk mail folders. It's as if the message is getting dropped on the floor.

Mike Kwilosz · ‎04-18-2012

I know a lot of our users still experience this. We've been able to track it back to people trying to send to googlemail.com domains. Does anyone have any further info on this? Its really a nuisance.