On 12/18/2015 11:32 AM, John Hardin wrote:
On Fri, 18 Dec 2015, Mark Martinec wrote:
On 2015-12-18 16:29, Axb wrote:
On 12/18/2015 04:17 PM, Mark Martinec wrote:
> On 2015-12-17 22:41, Axb wrote:
> > could you make a version using redirector_pattern so the
redirected
> > target can be looked up via URIBL plugin?
> > Isn't this already the case? Redirect targets are added
> to a list of URIs and are subject to same rules as
> directly collected URIs.
>
I suggested converting the rawbody rule John was working on into a
redirector_pattern
Note that the following rule as posted by John:
uri __GOOG_MALWARE_DNLD
m;^https?://[^/]*\.google\.com/[^?]*url\?.*[\?&]download=1;i
would not currently work as a redirector_pattern due to the problem
I posted in my today's reply (Re: redirector_pattern question);
i.e. where the redirector target contains "http:", followed
by other URI arguments (like "&download=1" here).
Right, and I would take that into account when composing the
redirector_pattern. That extra bit is there to avoid treating *all*
google redirects as malware downloads.
Question: has anyone ever seen a *legit* (non-spam, non-phishing,
non-malware) google redirect like that in an email? Maybe this rule is
too restrictive and we should be suspicious of *all* google redirects?
I do it occasionally, if I am sending a link to someone and I
right-click -> "copy link location" on the search results. I'd be
suspicious of those sorts of links, but not too suspicious.
