On Tue, Sep 09, 2014 at 07:10:34AM +0200, Axb wrote:
> On 09/09/2014 07:04 AM, Henrik K wrote:
> >On Tue, Sep 09, 2014 at 03:45:33AM +0200, Karsten Bräckelmann wrote:
> >>
> >>There is one down side: A new dependency on Regexp::List [1]. The RE
> >>pre-compile one-time upstart penalty should be neg
On 09/09/2014 07:04 AM, Henrik K wrote:
On Tue, Sep 09, 2014 at 03:45:33AM +0200, Karsten Bräckelmann wrote:
There is one down side: A new dependency on Regexp::List [1]. The RE
pre-compile one-time upstart penalty should be negligible.
[1] Well, or a really, really f*cking ugly option that ta
On Sep 8, 2014, at 7:45 PM, Karsten Bräckelmann wrote:
>
> Opinions? Discussion in here, or should I move this to dev?
Given that TLDs can and do change on a timescale more frequent than many people
update their version of SA (myself included), I would vote for a method that
treats this as a c
On Tue, Sep 09, 2014 at 03:45:33AM +0200, Karsten Bräckelmann wrote:
>
> There is one down side: A new dependency on Regexp::List [1]. The RE
> pre-compile one-time upstart penalty should be negligible.
>
> [1] Well, or a really, really f*cking ugly option that takes a
> pre-optimzed qr// blo
On 9. sep. 2014 04.29.55 Karsten Bräckelmann wrote:
Apart from that nitpick, I understand you would be in favor of a Valid
TLD option, rather than hard-coded. Noted.
Perl programmer make there signature in perl code
Well i still thinking about url reputation, but since nearly all kind of
si
>>embedded in the rules.
> ^
>Code, not rules. Which basically is the issue here...
Just read what I *mean* and not what I type. ;-)
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
"...Life is not a journey to the grave with the intention of arriving
safely in one pretty
On Mon, 2014-09-08 at 21:45 -0500, Dave Pooser wrote:
> On 9/8/14 8:45 PM, "Karsten Bräckelmann" wrote:
>
> >There is one down side: A new dependency on Regexp::List [1]. The RE
> >pre-compile one-time upstart penalty should be negligible.
> >
> >[1] Well, or a really, really f*cking ugly option
On Mon, 2014-09-08 at 22:37 -0400, listsb-spamassas...@bitrate.net wrote:
> On Sep 8, 2014, at 21.45, Karsten Bräckelmann wrote:
>
> > Some discussion of the underlying issue.
> >
> > On Tue, 2014-09-09 at 02:59 +0200, Karsten Bräckelmann wrote:
> >> At the time of the 3.3.2 release, the .club T
On 9/8/14 8:45 PM, "Karsten Bräckelmann" wrote:
>There is one down side: A new dependency on Regexp::List [1]. The RE
>pre-compile one-time upstart penalty should be negligible.
>
>[1] Well, or a really, really f*cking ugly option that takes a
>pre-optimzed qr// blob containing the VALID_TLDS
On Sep 8, 2014, at 21.45, Karsten Bräckelmann wrote:
> Some discussion of the underlying issue.
>
> On Tue, 2014-09-09 at 02:59 +0200, Karsten Bräckelmann wrote:
>> At the time of the 3.3.2 release, the .club TLD simply didn't exist. It
>> has been accepted by IANA just recently. Of course I was
On Mon, 2014-09-08 at 22:15 -0400, Daniel Staal wrote:
> --As of September 9, 2014 3:45:33 AM +0200, Karsten Bräckelmann is alleged
> to have said:
>
> > This incidence is part of the initial round of IANA accepting generic
> > TLDs. There's hundreds in this wave, and some are abused early. This
--As of September 9, 2014 3:45:33 AM +0200, Karsten Bräckelmann is alleged
to have said:
This incidence is part of the initial round of IANA accepting generic
TLDs. There's hundreds in this wave, and some are abused early. This is
moonshine registration, nothing like new TLDs being accepted in
Some discussion of the underlying issue.
On Tue, 2014-09-09 at 02:59 +0200, Karsten Bräckelmann wrote:
> At the time of the 3.3.2 release, the .club TLD simply didn't exist. It
> has been accepted by IANA just recently. Of course I was conveniently
> using a trunk checkout for testing and kind of
On Sep 8, 2014, at 7:17 PM, Alex Regan wrote:
>> Please use plain-text rather than HTML. In particular with that really
>> bad indentation format of quoting.
>
> It doesn't seem possible with gmail directly any longer, so I've set up
> thunderbird for this. Maybe it is, but not after clicking a
On Mon, 8 Sep 2014, Alex Regan wrote:
Did you understand that the number of previously not seen tokens has
absolutely nothing to do with auto-learning?
Yes, that was a mistake.
Did you understand that all
tokens are learned, regardless whether they have been seen before?
That doesn't reall
On Sep 8, 2014, at 6:59 PM, Karsten Bräckelmann wrote:
> It also should be possible to simply replace that Perl module
> with the current trunk version.
It seems like this is doable, and I just tried it... a test run on the previous
spample now hits my template. Hopefully just dropping the tru
Hi,
Please use plain-text rather than HTML. In particular with that really
bad indentation format of quoting.
It doesn't seem possible with gmail directly any longer, so I've set up
thunderbird for this. Maybe it is, but not after clicking around in the
obvious places.
X-Spam-MyReport: To
On Mon, 8 Sep 2014, Amir Caspi wrote:
Since I'm not running 3.4, this particular grep doesn't work for me, but with
John Hardin's advice I set up the following rule, which should catch all URIs:
uri ALL_URI /.*/
tflags ALL_URI multiple
Debug output shows the following:
Sep 8 20:0
On Mon, 2014-09-08 at 18:08 -0600, Amir Caspi wrote:
> On Sep 8, 2014, at 4:09 PM, Karsten Bräckelmann
> wrote:
>
> > Pulled the sample from pastebin and fed to spamassassin -D with your
> > custom rule added as additional configuration. That rule hits.
>
> It does not hit on mine, and I think
On Mon, 8 Sep 2014, Amir Caspi wrote:
Nope, it does not. Per above, it seems that SA 3.3.2 doesn't like the TLD.
Nope, it doesn't:
https://svn.apache.org/viewvc/spamassassin/branches/3.3/lib/Mail/SpamAssassin/Util/RegistrarBoundaries.pm?view=markup
Is there a patch I can apply that would f
On Sep 8, 2014, at 4:09 PM, Karsten Bräckelmann wrote:
> Pulled the sample from pastebin and fed to spamassassin -D with your
> custom rule added as additional configuration. That rule hits.
It does not hit on mine, and I think I've figured out why. I'm using SA 3.3.2
with perl 5.8.8 on CentOS
On Mon, 2014-09-08 at 11:35 -0600, Amir Caspi wrote:
> One of my spammy URI template rules is, for some reason, not hitting
> any more. Spample here:
>
> http://pastebin.com/jy6WZhWW
>
> In my local.cf sandbox I have the following:
>
> uri __AC_STOPRANDDOM_URI1
> /(?:stop|halt|quit|leave|l
On Sep 8, 2014, at 12:06 PM, Axb wrote:
>> imo, an URI rule shouldn't have a boundary delimiter
I normally have one to signify the end of the URI, as this is intended to
reduce FPs (just in case some legitimate email might match this but have
something after the domain). This delimiter normal
On 9/7/2014 1:47 AM, Henrik K wrote:
Also there's my patch to make SA handle big blobs gracefully:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6582 Skipping
large messages is a bit of 90's mentality since technically it's
pointless.
Which reminds me I need to write a config option
On 09/08/2014 08:03 PM, Axb wrote:
On 09/08/2014 07:35 PM, Amir Caspi wrote:
Hi all,
One of my spammy URI template rules is, for some reason, not hitting
any more. Spample here:
http://pastebin.com/jy6WZhWW
In my local.cf sandbox I have the following:
uri __AC_STOPRANDDOM_URI1
/(?:stop|halt
On 09/08/2014 07:35 PM, Amir Caspi wrote:
Hi all,
One of my spammy URI template rules is, for some reason, not hitting
any more. Spample here:
http://pastebin.com/jy6WZhWW
In my local.cf sandbox I have the following:
uri __AC_STOPRANDDOM_URI1
/(?:stop|halt|quit|leave|leavehere|out|exit|disal
Hi all,
One of my spammy URI template rules is, for some reason, not hitting
any more. Spample here:
http://pastebin.com/jy6WZhWW
In my local.cf sandbox I have the following:
uri __AC_STOPRANDDOM_URI1
/(?:stop|halt|quit|leave|leavehere|out|exit|disallow|discontinue|end)\.[a-z0-
27 matches
Mail list logo
