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?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
7 days until Christmas
