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.
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_HIDDEN
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/content
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
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
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
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 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
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
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
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 prominently
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 on this,
John Hardin wrote:
http://pastebin.com/m1268fbe6
Thanks. Here's the problematic URI:
http://../cd.asp?i=572550545UserID=4DFEDDHIIBCFBH55
in the unsunscribe link.
Which was actually:
a href=3D=22=2E=
=2E/cd=2Easp?i=3D572550545=26UserID=3D4DFEDDHIIBCFBH55=22
And thus:
a
Adam Katz wrote:
John Hardin wrote:
http://pastebin.com/m1268fbe6
Thanks. Here's the problematic URI:
http://../cd.asp?i=572550545UserID=4DFEDDHIIBCFBH55
in the unsunscribe link.
Which was actually:
a href=3D=22=2E=
=2E/cd=2Easp?i=3D572550545=26UserID=3D4DFEDDHIIBCFBH55=22
And thus:
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 understand the
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
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 I
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 a href=a.bc/.secret
On May 15, 2009, at 5:44, Adam Stephens adam.steph...@bristol.ac.uk
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
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 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 KA7OHZ
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:
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 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_HIDDEN /.{8}\/\../
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 might
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:
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 when
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
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:
snip
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
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 isn't
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
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 worst couldn't
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 losing money
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 make a
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
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?
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
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
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 knows.
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.
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.
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
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
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
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
even
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
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,
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 dedicated
mouss wrote:
Is phishing really a problem for banks? I don't think so.
You're kidding right?
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
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
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:
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
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 now
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 :)
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
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
59 matches
Mail list logo
