The latest content update (pushed today, my time) gave me the following warning in the task when I installed it
VSYS1: Rule 'Outbound_Traffic' application dependency warning: Application 'gmail-base' requires 'smtp' to be allowed, but 'smtp' is denied by rule 'Outbound_Bad'
WTF? Since when does GMail require SMTP? The local installations don't use SMTP - they connect to GMail over HTTP/HTPS, and the GMail back-end servers do the SMTP stuff. Why does Palo Alto now think GMail requires SMTP? I should add that I have checked the release notes for this content release and they mention *nothing* about there being a change to the gmail-base app signature.
I'm not allowing SMTP outbound from everything, because the idiots who run crap like iJunk get my outbound address into blackholes by using misconfigured junk which identifies itself as "localhost.localdomain" in the SMTP EHLO sessions - yet I need GMail for regular use.
Anyone know what the hell is going on here? Impressed I am not.
Well, got my answer back from PA support.
Apparently, this was done to make some crApple device work properly, no doubt it broke as part of the on-going wars between Google and Apple.
From the last reply
To clarify further, Bug 52402 has already been filed with the category of resolved.
The reason for this dependency is that when using gmail on iPhone, the traffic goes out through smtp. After some live tests, it was decided to add smtp as the dependency app. Since this change is minor (no signature change but app definition change only), our release note generation script didn't automatically pick this up properly by adding gmail in the modified app release note section.
We will work with QA to make sure this shouldn't happen again in the future!
So I re-applied the update (which crashed the management plane, but that's maybe because of the quick upgrade/rollback I did in the first place), got the same warning - but web-based Gmail still works.
So now, I get a bloody warning every time I commit a policy change. Yay.
When using clients to access Gmail, the outgoing mail server is smtp.gmail.com and this uses SMTP over SSL or StartTLS. This traffic will be identifed as smtp when using StartTLS or when the SSL session is decrypted.
He directly addressed this in his original description of the question... he's not using actual clients, he's using strictly web-based Gmail:
The local installations don't use SMTP - they connect to GMail over HTTP/HTPS, and the GMail back-end servers do the SMTP stuff. Why does Palo Alto now think GMail requires SMTP? I should add that I have checked the release notes for this content release and they mention *nothing* about there being a change to the gmail-base app signature.
If that's the case, why have I *never* seen this warning before the last content package pushed to my device (375-1810).
I have not changed my rulebase. I have not changed my filtering parameters. I have been manually installing content updates since day dot (I have been bitten with automatic upgrades before, and I refuse to allow them to install automatically), and I have never once seen this warning on content install.
There was no mention of this change in the release notes. There's no comment anywhere that I can find from Palo Alto which says, or has said, that SMTP is a requirement. The previous application definition release has NO mention of SMTP being a dependency in the gmail app, or in any of its sub-apps.
I don't believe that SMTP is required at all for the Gmail web app - indeed, I've never seen a single packet going to Gmail which is identified as "SMTP" by the Palo Alto.
So for Palo Alto to suddenly push an app content release which links SMTP to Gmail without notice is a fail on their part, plain and simple.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!