On Thursday September 2 2010 01:52:28 Runbox wrote:
> Would you please remove Runbox.com from that list as we have not been a
> free email provider since 2001.
> Kim
Thanks, removed!
Should propagate with the next sa-update.
Mark
Hello,
Would you please remove Runbox.com from that list as we have not been a free
email provider since 2001.
Kim
--
View this message in context:
http://old.nabble.com/FreeMail-plugin-updated-tp23468766p29599495.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
On Mon, 8 Mar 2010, Ned Slider wrote:
John Hardin wrote:
On Mon, 8 Mar 2010, Ned Slider wrote:
>
> So I've refined the rule to specifically exclude hitting on the sequence
> ../. which stops the rule triggering on multiple relative paths.
>
> uriLOCAL_URI_HIDDEN_DIR/(?!.{6}\.
John Hardin wrote:
On Mon, 8 Mar 2010, Ned Slider wrote:
So I've refined the rule to specifically exclude hitting on the
sequence ../. which stops the rule triggering on multiple relative paths.
uriLOCAL_URI_HIDDEN_DIR/(?!.{6}\.\.\/\..).{8}\/\../
How about:
uri LOC
On Mon, 8 Mar 2010, Ned Slider wrote:
Adam Katz wrote:
> > On 15-May-2009, at 12:46, Adam Katz wrote:
> > > uri URI_HIDDEN /.{7}\/\../
LuKreme wrote:
> > That won't catch
> > http://www.spammer.example.com/.../hidden-malware.asf, it will only
> > catch the relative url form "../path/to/c
Adam Katz wrote:
On 15-May-2009, at 12:46, Adam Katz wrote:
uri URI_HIDDEN /.{7}\/\../
LuKreme wrote:
That won't catch
http://www.spammer.example.com/.../hidden-malware.asf, it will only
catch the relative url form "../path/to/content" which SA improperly
prefaces with "http://";
uri URI_HID
>> On 15-May-2009, at 12:46, Adam Katz wrote:
>>> uri URI_HIDDEN /.{7}\/\../
LuKreme wrote:
>> That won't catch
>> http://www.spammer.example.com/.../hidden-malware.asf, it will only
>> catch the relative url form "../path/to/content" which SA improperly
>> prefaces with "http://";
>>
>> uri URI_H
On Fri, 15 May 2009, LuKreme wrote:
Of course, if SA didn't preface URIs with http:// on its own, this
wouldn't be an issue. However, I am not willing to call that a bug as I
suspect there is a very good reason for it.
It's a bug in the specific case of a URI like "../whatever", as it doesn't
On 15-May-2009, at 14:35, LuKreme wrote:
On 15-May-2009, at 12:46, Adam Katz wrote:
uri URI_HIDDEN /.{7}\/\../
That won't catch http://www.spammer.example.com/.../hidden-
malware.asf, it will only catch the relative url form "../path/to/
content" which SA improperly prefaces with "http://";
On Fri, 15 May 2009, LuKreme wrote:
On 15-May-2009, at 12:46, Adam Katz wrote:
uri URI_HIDDEN /.{7}\/\../
That won't catch http://www.spammer.example.com/.../hidden-malware.asf,
How so? That rule matches "ple.com/.." in that URI.
--
John Hardin KA7OHZhttp://www.impsec.
On 15-May-2009, at 12:46, Adam Katz wrote:
uri URI_HIDDEN /.{7}\/\../
That won't catch http://www.spammer.example.com/.../hidden-
malware.asf, it will only catch the relative url form "../path/to/
content" which SA improperly prefaces with "http://";
uri URI_HIDDEN /.{8}\/\../
Will catch
On May 15, 2009, at 5:44, Adam Stephens
wrote:
LuKreme wrote:
On 12-May-2009, at 18:27, John Hardin wrote:
uri URI_HIDDEN/\/\../
Ah, that's very very nice.
Scoring it at 3.0, too aggressive?
I'd say so - I'm seeing lots of FPs on this, most prominently on
mail from mail.el
John Hardin wrote:
> What about an explicit "https://.."; URI?
I have no problem marking that as spam (you're thinking too hard).
>> I should also have noted that while this works around the SA bug, it
>> also ignores hidden dirs and files appearing early in relative paths,
>> like
>
> That hre
Adam Katz wrote:
Adam Katz wrote:
Relative URIs are only safe when prefacing the URI. Requiring the
protocol beforehand should do the trick. Since "http://"; is the
implied protocol and is 8 chars, we get this:
uri URI_HIDDEN /.{8}\/\../
Ned Slider wrote:
Yep - that works great for me and
On Fri, 15 May 2009, Adam Katz wrote:
Adam Katz wrote:
Relative URIs are only safe when prefacing the URI. Requiring the
protocol beforehand should do the trick. Since "http://"; is the
implied protocol and is 8 chars, we get this:
uri URI_HIDDEN /.{8}\/\../
Ned Slider wrote:
Yep - that w
> Adam Katz wrote:
>> Relative URIs are only safe when prefacing the URI. Requiring the
>> protocol beforehand should do the trick. Since "http://"; is the
>> implied protocol and is 8 chars, we get this:
>>
>> uri URI_HIDDEN /.{8}\/\../
Ned Slider wrote:
> Yep - that works great for me and I un
Adam Katz wrote:
John Hardin wrote:
http://pastebin.com/m1268fbe6
Thanks. Here's the problematic URI:
http://../cd.asp?i=572550545&UserID=4DFEDDHIIBCFBH55
in the unsunscribe link.
Which was actually:
=2E/cd=2Easp?i=3D572550545=26UserID=3D4DFEDDHIIBCFBH55=22>
And thus:
This is *ve
John Hardin wrote:
>> http://pastebin.com/m1268fbe6
>
> Thanks. Here's the problematic URI:
>
>http://../cd.asp?i=572550545&UserID=4DFEDDHIIBCFBH55
>
> in the unsunscribe link.
Which was actually:
> =2E/cd=2Easp?i=3D572550545=26UserID=3D4DFEDDHIIBCFBH55=22>
And thus:
>
This is *very*
On Fri, 15 May 2009, Ned Slider wrote:
John Hardin wrote:
On Fri, 15 May 2009, Adam Stephens wrote:
>
> I'm seeing lots of FPs on this, most prominently on mail
> from mail.elsevier-alerts.com
Really? Sites are sending out legitimate URLs pointing to hidden
directories?
Could you pos
John Hardin wrote:
On Fri, 15 May 2009, Ned Slider wrote:
Adam Stephens wrote:
LuKreme wrote:
> On 12-May-2009, at 18:27, John Hardin wrote:
> > uri URI_HIDDEN/\/\../
> > > Ah, that's very very nice.
> > Scoring it at 3.0, too aggressive?
>
I'd say so - I'm seeing lots of FPs o
On Fri, 15 May 2009, Ned Slider wrote:
Adam Stephens wrote:
LuKreme wrote:
> On 12-May-2009, at 18:27, John Hardin wrote:
> > uri URI_HIDDEN/\/\../
>
>
> Ah, that's very very nice.
>
> Scoring it at 3.0, too aggressive?
>
I'd say so - I'm seeing lots of FPs on this, most pro
John Hardin wrote:
On Fri, 15 May 2009, Adam Stephens wrote:
LuKreme wrote:
On 12-May-2009, at 18:27, John Hardin wrote:
> uri URI_HIDDEN/\/\../
Ah, that's very very nice.
Scoring it at 3.0, too aggressive?
I'd say so - I'm seeing lots of FPs on this, most prominently on mail
Adam Stephens wrote:
LuKreme wrote:
On 12-May-2009, at 18:27, John Hardin wrote:
uri URI_HIDDEN/\/\../
Ah, that's very very nice.
Scoring it at 3.0, too aggressive?
I'd say so - I'm seeing lots of FPs on this, most prominently on mail
from mail.elsevier-alerts.com
I believ
On Fri, 15 May 2009, Adam Stephens wrote:
LuKreme wrote:
On 12-May-2009, at 18:27, John Hardin wrote:
> uri URI_HIDDEN/\/\../
Ah, that's very very nice.
Scoring it at 3.0, too aggressive?
I'd say so - I'm seeing lots of FPs on this, most prominently on mail
from mail.elsevier-
LuKreme wrote:
On 12-May-2009, at 18:27, John Hardin wrote:
uri URI_HIDDEN/\/\../
Ah, that's very very nice.
Scoring it at 3.0, too aggressive?
I'd say so - I'm seeing lots of FPs on this, most prominently on mail
from mail.elsevier-alerts.com
--
--
On Sun, May 10, 2009 at 01:08:29PM +0300, Henrik K wrote:
>
> http://sa.hege.li/FreeMail.pm (see inside for some documentation)
> http://sa.hege.li/FreeMail.cf (for some examples)
I've added suggestion for this:
header __freemail_reply eval:check_freemail_replyto('reply')
meta FREEMAIL_REPLY (__f
neil wrote:
Hi;
Ned Slider wrote:
>First up, from Mike's inspiration above, I came up with these:
I took your rule and added some meta rules to it. I'm getting hits on
phishes, but I haven't seen any legitimate traffic hit it.
This may be that I have not seen any real bank mail or it could be
Hi;
Ned Slider wrote:
>First up, from Mike's inspiration above, I came up with these:
I took your rule and added some meta rules to it. I'm getting hits on
phishes, but I haven't seen any legitimate traffic hit it.
This may be that I have not seen any real bank mail or it could be that
it misse
Henrik K wrote:
>> When I run "spamassassin --lint" no problems are reported. Any thoughts
>> on why this is happening only when updating the sought rules?
>
> It seems sa-update only lints the directory that it downloaded, thus no
> freemail_domains cf is ever seen. I've now reduced the warning
Ned Slider wrote:
uriLOCAL_URI_PHISH_UK3
m{https?://.{1,40}/.{1,60}\.(ac|co|gov)\.uk}
describeLOCAL_URI_PHISH_UK3contains obfuscated UK phish link of
form example.com/bank.co.uk
Ah, this rule hits on unsubscribe links etc, which wasn't what was
intended. For example:
On Tue, May 12, 2009 at 07:25:26PM -0700, Bill Landry wrote:
> Hi Henrik,
>
> > I've revamped fully the old code. Works still the same, but has some new
> > functions. It's also a bit more careful when parsing body (new parser,
> > emails inside <> are ignored, as well ones inside urls etc), so it
On 12-May-2009, at 18:27, John Hardin wrote:
uri URI_HIDDEN/\/\../
Ah, that's very very nice.
Scoring it at 3.0, too aggressive?
--
No matter how fast light travels it finds the darkness has always
go there first, and is waiting for it.
Bill Landry wrote:
> Hi Henrik,
>
>> I've revamped fully the old code. Works still the same, but has some new
>> functions. It's also a bit more careful when parsing body (new parser,
>> emails inside <> are ignored, as well ones inside urls etc), so it might
>> even reduce FPs and add hits, who k
Hi Henrik,
> I've revamped fully the old code. Works still the same, but has some new
> functions. It's also a bit more careful when parsing body (new parser,
> emails inside <> are ignored, as well ones inside urls etc), so it might
> even reduce FPs and add hits, who knows.
>
> Domains are now
John Hardin wrote:
On Wed, 13 May 2009, Ned Slider wrote:
uriLOCAL_URI_HIDDEN_DIRm{https?://.{1,40}/\.\w}
describeLOCAL_URI_HIDDEN_DIRcontains hidden directory of form
example.com/.something
the fourth might be indicative of a hacked server with a hidden
phishing directo
On Wed, 13 May 2009, Ned Slider wrote:
uri LOCAL_URI_HIDDEN_DIRm{https?://.{1,40}/\.\w}
describe LOCAL_URI_HIDDEN_DIR contains hidden directory of form
example.com/.something
the fourth might be indicative of a hacked server with a hidden
phishing directory.
Any comments?
Mike Cardwell wrote:
Marc Perkel wrote:
Or maybe I'm trying to reinvent a wheel someone already has up and
running :-)
a bank without SPF or DKIM signing is NOT worth using
Yes - but I think what he's saying is that you have to start with a
list of bank domains, the test those domains with
John Hardin a écrit :
> On Tue, 12 May 2009, Ned Slider wrote:
>
>> Then you get phish where the From address is a bank domain, and the
>> envelope address is from a completely unrelated domain with a valid
>> spf record so even a simple From_Bank && spf_pass isn't going to work.
>
> That might m
Marc Perkel a écrit :
>
>
> mouss wrote:
>> Is phishing really a problem for banks? I don't think so.
>
(I'll forgive you for snipping the rest of the paragraph, and thus
isolating a single phrase which was part of a context...).
> You're kidding right?
>
No. I never heard of a bank losin
On Tuesday 12 May 2009, LuKreme wrote:
>On 11-May-2009, at 17:20, Marc Perkel wrote:
>> mouss wrote:
>>> Is phishing really a problem for banks? I don't think so.
>>
>> You're kidding right?
>
>No, he has a point. The people with the problem are the customers. The
>bank is at best neutral and at wo
On 11-May-2009, at 17:20, Marc Perkel wrote:
mouss wrote:
Is phishing really a problem for banks? I don't think so.
You're kidding right?
No, he has a point. The people with the problem are the customers. The
bank is at best neutral and at worst couldn't care less.
Also, despite the amou
On Mon, 2009-05-11 at 19:36 -0700, John Hardin wrote:
> On Tue, 12 May 2009, Ned Slider wrote:
>
> > Then you get phish where the From address is a bank domain, and the
> > envelope address is from a completely unrelated domain with a valid spf
> > record so even a simple From_Bank && spf_pass i
Hi;
Ned Slider wrote:
>My point is it's really not easy to track down such information even
when banks do occasionally try to do the right thing. Maybe there is
already a >list out there. If not, maybe we should compile one? It's
hard work trying to do it by yourself, but done as a group it w
On Tue, 12 May 2009, Ned Slider wrote:
Then you get phish where the From address is a bank domain, and the
envelope address is from a completely unrelated domain with a valid spf
record so even a simple From_Bank && spf_pass isn't going to work.
That might make a useful general rule, though:
John Hardin wrote:
On Mon, 11 May 2009, Marc Perkel wrote:
mouss wrote:
Is phishing really a problem for banks? I don't think so.
You're kidding right?
I think mouss' point is that if banks considered phishing "their
problem" they would be pursuing effective technological and policy
sol
On Mon, 11 May 2009, Marc Perkel wrote:
mouss wrote:
Is phishing really a problem for banks? I don't think so.
You're kidding right?
I think mouss' point is that if banks considered phishing "their problem"
they would be pursuing effective technological and policy solutions like
proper S
mouss wrote:
Is phishing really a problem for banks? I don't think so.
You're kidding right?
> > In the meantime I'm left working on the basis that for the large part,
> > banks simply don't send email to my clients so *any* email claiming to
> > be from a bank is immediately highly suspicious and could probably be
> > scored well on the way to being spam.
> >
>
> I personally use dedica
Ned Slider a écrit :
> [snip]
> I
> would really like to see the creation of a tld along the lines of .bank,
> and make it like .gov or .edu (ac.uk) where only confirmed banks and
> financial institutions can register such domains.
my $devil{"advocate"}->mode = $status->enabled;
and after banks
On 11-May-2009, at 03:11, Ned Slider wrote:
My thinking is that combined as a meta with a few simple keywords/
phrases (eg, alert, security, account suspended etc) it might make a
very effective rule against bank phish.
The only thing that needs to be done to prevent bank phish is to check
On Sun, May 10, 2009 at 01:08:29PM +0300, Henrik K wrote:
>
> Hello,
>
> I've revamped fully the old code. Works still the same, but has some new
> functions. It's also a bit more careful when parsing body (new parser,
> emails inside <> are ignored, as well ones inside urls etc), so it might
> e
Mike Cardwell wrote:
Ned Slider wrote:
Yes - but I think what he's saying is that you have to start with a
list of bank domains, the test those domains with higher scrutiny.
Does such a list exist? One of my users was getting a lot of spam
pretending to be from banks. I ended up just compili
Ned Slider wrote:
Yes - but I think what he's saying is that you have to start with a
list of bank domains, the test those domains with higher scrutiny.
Does such a list exist? One of my users was getting a lot of spam
pretending to be from banks. I ended up just compiling a regular
expressi
Mike Cardwell wrote:
Marc Perkel wrote:
Yes - but I think what he's saying is that you have to start with a
list of bank domains, the test those domains with higher scrutiny.
Does such a list exist? One of my users was getting a lot of spam
pretending to be from banks. I ended up just compi
Marc Perkel wrote:
Or maybe I'm trying to reinvent a wheel someone already has up and
running :-)
a bank without SPF or DKIM signing is NOT worth using
Yes - but I think what he's saying is that you have to start with a list
of bank domains, the test those domains with higher scrutiny.
Do
Just curious - how did you build that list?
Henrik K wrote:
Hello,
I've revamped fully the old code. Works still the same, but has some new
functions. It's also a bit more careful when parsing body (new parser,
emails inside <> are ignored, as well ones inside urls etc), so it might
even reduce
Benny Pedersen wrote:
On Sun, May 10, 2009 13:15, Ned Slider wrote:
Or maybe I'm trying to reinvent a wheel someone already has up and
running :-)
a bank without SPF or DKIM signing is NOT worth using
Yes - but I think what he's saying is that you have to start with a list
of
On Sun, May 10, 2009 13:15, Ned Slider wrote:
> Or maybe I'm trying to reinvent a wheel someone already has up and
> running :-)
a bank without SPF or DKIM signing is NOT worth using
--
http://localhost/ 100% uptime and 100% mirrored :)
Henrik K wrote:
Hello,
I've revamped fully the old code. Works still the same, but has some new
functions. It's also a bit more careful when parsing body (new parser,
emails inside <> are ignored, as well ones inside urls etc), so it might
even reduce FPs and add hits, who knows.
Domains are no
Hello,
I've revamped fully the old code. Works still the same, but has some new
functions. It's also a bit more careful when parsing body (new parser,
emails inside <> are ignored, as well ones inside urls etc), so it might
even reduce FPs and add hits, who knows.
Domains are now separated from
60 matches
Mail list logo
