Firewalls blocking pages with Marketo tracking code

[Natali_Talevski]

Hi all,

Does anyone else have issues with firewalls blocking access to webpages that have come from Marketo emails? When some recipients click through on the Marketo link (complete with tracking code) they get an error saying the page is blocked. Yet when they go to the page directly, it works fine.

Any reason the tracking might be doing this? Is there a way around it other than removing the tracking (which I don't want to do as I want to see who clicks on what).

Thanks

Natali

[SanfordWhiteman]

If you are using a custom branding domain CNAME (i.e. go.example.com) pointing to your mkto-* host (i.e. mkto-sj010203.com) then you are doing almost everything you can to combat detection by an aggressive outbound web filter. If the filter has mkto-*.com on a blacklist then it's trivial for the filter to determine that's where your links are going.

I say "almost everything" above because you could run your Marketo tracking domain in such a way that the web filters would never see mkto-*.com -- so they'd be unable to block based on that match.  However, whether such an approach is ethical, or even legal, is debatable if you know the web filter is trying to block connections to Marketo click tracking. In other words, if you felt that mkto-*.com was mistakenly blacklisted according to the known policies of the firm, that's one thing, but if you admit they're following an explicit anti-Marketo and/or anti-click-tracking policy and you try to subvert it, that's problematic.

I would be curious about the exact error/reason given by the web filter.  If the reason is "we do not support click tracking redirectors" or "we hate Marketo users" it's accurately blocking your tracking domain and you have to let it ride.  But if the reason (however unlikely) is "we do not support JavaScript redirectors" then you can get around that without being unethical. Or if the reason is actually "go.example.com is seen as a malware host" or "go.example.com is inappropriate for business-day browsing" (assuming you are a legit B2B company) those would also be worthy of proactive measures (in these cases, temporarily changing your tracking domain would be a reasonable test).

Really like to know the explicit reason given by the filter.

Oh, and something else: if the filter doesn't block Munchkin tracking from running on the destination page (would be pretty weird to let Munchkin go if they have a general anti-tracking policy, but could be) then you could skip over Clicked Link in Email tracking, which does not use Munchkin, and still get pretty good coverage via the Munchkin events (Visit Web Page and Clicked Link on Web Page) by including the lead identifier in the query string.  This will of course not work for any assets that can only be tracked via the tracking server, like PDFs.

[Samantha_McCol1]

Thank you for the excellent response, Sanford Whiteman. We are experiencing the same issue, I believe. Here is the exact error message, I receive it in both Chrome and IE:

    -

It first came to our attention ~2 months ago. It occurs at random times and to random people, on and off. Some of the people on our team have/had the issue, others have never experienced it, and we know that others outside of our company have experienced the problem as well. Strangely.. if the brower's history/cache is cleared, the links will then work again, for a period of time.

Thoughts/suggestions beyond what was already covered?

[SanfordWhiteman]

This is a much lower-level problem than using a Marketo CNAME. I experience immediate disconnection from https://mail.beyondtrust.com/  even when I'm outside a firewall.  This is going to affect all users.

Are you sure you actually uploaded (and have continued paying for) Marketo's SSL service on the branding domain mail.beyondtrust.com?  I receive BT mailings (I am a customer) and the links have http://mail.beyondtrust.com, not https://mail.beyondtrust.com. I am not redirected to the non-working SSL site.

[Samantha_McCol1]

Ah, well, I am new to the company and this issue was just brought to my attention so I don't have those answers but I will certainly direct them to the right people.

My first thoughts though, this doesn't happen to everyone, and the links work if you delete your cache. That doesn't make sense, but I will definitely explore this further.

[SanfordWhiteman]

Believe me, https://mail.beyondtrust.com, the domain in your screenshot, does not work.

Deleting your cache won't make SSL connections to a non-SSL site work.  What deleting your cache can do is erase stored redirects from http:-->https: (which may mean that the visit "works" because you never reach the https: site). But if the https: site doesn't work, it doesn't!