Calling for a vote on the release of Apache SpamAssassin 4.0.1
fine with me, +1
I've been running trunk (and now 4.0.1) under amavisd on FreeBSD 14.0,
perl 5.36, bayes on redis. Works well ...
... except that I had to downgrade module Mail::DKIM to 1.20230212,
as the newer 1.20240124 crashes
Messages via o365 seem to have a problem with this..
Jan 23 09:51:51.081 [1569369] dbg: check: tagrun - tag
RELAYSUNTRUSTEDREVIP is now ready, value:
ARY:[71.53.92.40,5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.2.8.0.6.9.0.1.3.0.6.2]
Jan 23 09:51:51.081 [1569369] dbg: check: tagrun - tag
Calling for a vote on the release of Apache SpamAssassin 4.0.0
+1 for a long-awaited release
and thanks to everyone for making it happen!
Have been running trunk for months in production, and relying on
normalize_charset (which now became a default) since a long time.
It makes writing rules
On 2016-06-14 20:17, pgndev wrote:
I've installed a new instance of SA
spamassassin -V
SpamAssassin version 3.4.1
running on Perl version 5.18.2
module_info Mail::SpamAssassin Mail::SPF
Name:Mail::SpamAssassin
Version: 3.004001
Group|security|
Component|Security|Plugins
Sorry for unintentionally overwriting the assignment to security,
was a mid-air collision. I'll rest now :)
Mark
Per the release policy at
https://wiki.apache.org/spamassassin/ReleasePolicy, we encourage
everyone to test this release but I need two +1's from PMC members to
make the release official.
NOTE: The 3.4.1 files are available at
http://people.apache.org/~kmcgrail/devel/ NOT at the links below.
This passes all the tests including the xt tests from the build
instructions and I believe covers all the issues tagged for 3.4.1 in
bugzilla.
I believe we are ready for 3.4.1 pending testing this release
candidate.
+1 looks good to me.
Downloads are available from:
gpg -v --keyserver wwwkeys.pgp.net --recv-key F7D39814
gpg: Invalid option -v
(the '-v' should have been a '--verbose' or left out, I suppose)
Actually, the -v works with gpg2 but not with gpg1,
and the --verbose works with both.
Mark
Did some final editing on build/announcements/3.4.1.txt,
I think I'm done now. Others please feel free to edit to will.
Mark
Sarang Shrivastava wrote:
Yes, indeed CRM114 has a lot criterias for categorization of data and
that
can be done via a host of methods, including regexes, approximate
regexes,
a Hidden Markov Model, Orthogonal Sparse Bigrams, WINNOW, Correllation,
KNN/Hyperspace, or Bit Entropy.
We can take
Sarang,
I am Sarang Shrivastava, an open source enthusiast. This year in the
Gsoc
2015 a series of events happened after which I landed up here with SA.
I made a proposal for SA Building a statistical classifier plugin for
SA
Thanks for applying to GSoC, and thanks to Kevin for accepting
Quanah Gibson-Mount wrote:
--On Wednesday, April 15, 2015 3:34 PM +0200 Mark Martinec wrote:
Don't know. It might be worth taking a look at the CRM114 classifier,
which implements a number of methods. The CRM114 can be used as a
plugin to SpamAssassin, or can be called from Amavis and results
The build/announcements/3.4.1-rc2.txt now contains some rough
approximation
of release notes. I tried to collect some of the notable changes from
the SVN changelog and new features, but ran out of time for finer
editing.
It's probably still too long/detailed - feel free to edit to will and
As the possessive quantifier is
just a shorthand for the independent subexpression (?pattern), which
was introduced with 5.8, wouldn't it be just easier to rewrite these
few rules and avoid the possessive quantifier, along with all their
conditionals.
The widest possible support does generally
Back in November 2014 there was a thread:
sa-update lint fail on __PDS_FROM_2_EMAILS
which resulted in the introduction of a can(perl_min_version_...)
directive:
[Bug 7107] RFE: if() preprocessor directive should support a test for
perl version
I don't mind having the possibility to test
Has anyone done any real testing of Redis as a bayes backend?
Talking
with one of our customer, with a trivial 60,000 accounts, they are
seeing:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
22452 redis 20 0 28.7g 28g 740 S 9.6 72.4 1139:38
redis-server
28GB
On 02/12/2015 11:04 PM, Quanah Gibson-Mount wrote:
Has anyone done any real testing of Redis as a bayes backend? Talking
with one of our customer, with a trivial 60,000 accounts, they are
seeing:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
22452 redis 20 0 28.7g
Quanah Gibson-Mount wrote:
I'm pondering upgrading what we ship in zimbra to a 3.4.1 pre-release.
Is current head thought to be stable enough for usage?
Just these days it's in a bit of flux. As far as I'm concerned,
what is missing is a resolution of [Bug 7133] and [Bug 7130],
working on it.
:-) Well I don't want to change the vetting process for a release and
xt/60_perlcritic.t has been used for years on the code base.
Suggestions what we can do to resolve the issue that also passes that
test so we don't have to go down that rabbithole?
There are some other perlcritic warnings
There are some other perlcritic warnings about modifying $_ in list
functions
(in sa-update, spamassassin, spamd). Opening a PR would be warranted.
What is a PR? A bugzilla ticket?
Yes, a problem report. Sorry for using terminology from another
context.
If there are other perl critic
Yep that was done to pass the XT tests for a release. Joe can you
look at those returns again?
That advice from perlcritic needs to be taken with a large grain of
salt.
In the past I have been bitten by this several times. It is generally
safer to leave 'return undef' unless one carefully
Yep that was done to pass the XT tests for a release. Joe can you
look at those returns again?
That advice from perlcritic needs to be taken with a large grain of
salt.
In the past I have been bitten by this several times. It is generally
safer to leave 'return undef' unless one carefully
2015-01-14 18:06, je Alex Regan napisal
Hi,
I'm using amavisd-new-2.9.1 and perl-5.18.4 on fedora20 with the svn
spamassassin snapshot from today, and receive the following message:
Jan 14 11:59:21 mail01 amavis[19431]: (19431-18) _WARN: Use of
uninitialized value in concatenation (.) or
Kevin A. McGrail wrote:
I'm working on packaging 3.4.1-rc1 and fixed a few bugs but It's not
ready for announcement of voting. I will need to review if the rc1 is
burned and we move on to rc2 but wanted to get this mailed out so
people can look at things.
I'd like to get Bug 7106 resolved
Jan Hejl wrote:
Redis seems to be pretty stable except lots of connections.
Connections grow continuously up to max client limit. I've solved this
by settng timeout 1 value within redis.conf, but there's still lots
of CLOSE_WAIT connections. Has this been solved within BUG #7034?
Yes, I
me wrote:
I agree that would make a trivial yet useful addition to functionality.
It probably does not help with PR #7080, but may be useful with other
mentioned applications. Will add something along these lines, thanks!
Done:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7099
Paul Stead wrote:
Awesome,
Might it be useful to have other tags set as well?
LASTEXTERNALHELO - similar to the common tag in PerMsgStatus
LASTEXTERNALIP - as above
Anything else that could be handy?
Indeed, the LASTEXTERNALIP, LASTEXTERNALRDNS, and LASTEXTERNALHELO
could just as well be
2014-11-03 11:51, Paul Stead wrote:
I think a tag of SENDERDOMAIN would be handy to have so it can be used
with askdns and other rules which can make use of tags.
This would help address the following bug, which could be implemented
with a simple rule:
Kevin A. McGrail wrote:
I wanted to bring this up because Google is moving forward with
https://tools.ietf.org/html/rfc6530 and as they write at
http://googleenterprise.blogspot.com/2014/08/a-first-step-toward-more-global-email.html,
they are taking the first steps on this issue.
I expect this
I've added both * IvoTruxa * Ivo Truxa to the Contributors group
now. Please test again. You'd be the first on that list with a space
in your name.
I usually have a space in my wiki usernames too (MoinMoin and
MediaWiki).
Mark
2014-02-20 Tomasz Potega wrote:
I have run into some problems trying to upgrade to 3.4.0.
The '-x' ('--nouser-config') option of spamd doesn't seem to work
correctly.
Tracing the spamd child process I can see it tries to open a user_prefs
file of the pattern (absolute path):
[...]
The cause
Do we want to be aware of creating rules that may cause problems for
pre-3.3.2
installs? As I said, the primary use of that warning is for rule devs.
I think the need for this warning is long gone by now.
The warn() should either be turned into a dbg(), or just commented out.
This problem
2014-02-11 23:34, Kevin A. McGrail wrote:
Evening all, it's been a very long day getting SA 3.4.0 out the door.
I've gone through all of the existing documentation for a release,
resolved any discrepancies and completed it.
[...]
I'll be working to document things as they stand, get some
On behalf of the PMC, the ASF SpamAssassin Project is pleased to
announce the availability of our 3.4.0 subject to vote by the PMC per
the Project's ReleasePolicy
(http://wiki.apache.org/spamassassin/ReleasePolicy). There are no
substantial changes between this version and rc6. I have tested
Btw,
--- build/announcements/3.4.0.txt~ 2014-02-07 13:48:31.182496000 +0100
+++ build/announcements/3.4.0.txt 2014-02-07 18:36:05.784495713 +0100
@@ -284,3 +284,3 @@
-The sa-learn command has a new option option --max-size .
+The sa-learn command has a new option --max-size .
@@
-The sa-learn command has a new option option --max-size .
+The sa-learn command has a new option --max-size .
- gpg --verify Mail-SpamAssassin-3.4.0-pre1.tar.bz2.asc
+ gpg --verify Mail-SpamAssassin-3.4.0.tar.bz2.asc
Please commit and I can update the website. This is
On behalf of the PMC, the ASF SpamAssassin Project is pleased to
announce the availability of our sixth release candidate for 3.4.0
subject to vote by the PMC under lazy consensus. The key changes in this
version are the round-robin changes from bug 6996 when using spamd with
both ipv6 and
Mark wrote:
. Raspberry PI under Raspbian (Debian 7.2 (wheezy) on ARM), perl
5.14.2
Kevin wrote:
It kills me that you are checking this. Is this just a whim or are
there people using ARM clusters with SpamAssassin?
It is mostly just for fun. Actually it's the closest machine
I have with a
bayes_store_module_additional Mail::SpamAssassin::Util::TinyRedis
You are right. I added that to keep the require module which I thought
was keeping with the existing structure.
Someone then added a Use module. If the use module works, we can rip
out the additional module code I
It's been pointed out to me that the proposed announcement text now
shows in the section 'Redis database backend for a Bayes database'
example a new configuration directive:
bayes_store_module_additional Mail::SpamAssassin::Util::TinyRedis
I wonder what's the purpose and need for this.
Jan,
Before you embark on heavy testing - to avoid double work - consider
waiting for my fix at Bug 6996, expected tomorrow.
Ok, done. Either apply the patch attached to the bug report,
or (probably simpler) just checkout trunk from subversion
( svn checkout
Jan,
i'm sorry i've been too busy past few days
No problem, as long as we still have you in contact :)
converting InnoDB to TokuDB
engine. Excited with results - TokuDB is ~ 4x times less space used and
~ 4x times faster in my use case than InnoDB (even well tunned).
Interesting news!
Btw,
Jan,
I can understand now where the problem is, but don't see an easy solution yet.
It should work as it is if you remove the --round-robin option.
Please open a problem report on the bugzilla.
Mark
Jan,
I can understand now where the problem is, but don't see an easy solution
yet. It should work as it is if you remove the --round-robin option.
Please open a problem report on the bugzilla.
Please try the attached patch.
It adds some debugging, and handles the --round-robin case
by
Kevin A. McGrail wrote:
Anyone know why this dbg was disabled? I found it useful and thought
perhaps it should be restored but maybe it's too much output?
--- lib/Mail/SpamAssassin/Plugin/DNSEval.pm (revision 1562570)
+++ lib/Mail/SpamAssassin/Plugin/DNSEval.pm (working copy)
@@ -370,7
Jan,
i'm trying to run 3.4.0-rc5 on my test machine, but when I run:
/usr/sbin/spamd -D -r /var/run/spamd.pid -m 10 -u qscand -s null --timeout-
child=105 -l --nouser-config --max-conn-per-child=100 --round-robin
Good. Thanks for giving a try.
it starts infinite loop of child creation
Jan,
Please also tell us the OS in use, version of the IO::Socket::IP module,
and the version of Perl.
$ perl -le 'use IO::Socket::IP; print IO::Socket::IP-VERSION'
Mark
:33 PM, Mark Martinec wrote:
2) ask the Net::DNS folks if they'd be willing to put back the
unconditionally double-quoted form for 0.71, and keep it there
for at least until SpamAssassin 3.4 really hits the streets;
meanwhile suggest people to switch Net::DNS to 0.71 or to 0.68
Committers/PMC:
Please vote to release 3.4.0-rc3.
Looks good, thanks!
+1 from me.
I'm now running it on one production
system and have been monitoring it for a while. So far so good!
Same here.
Files at http://people.apache.org/~kmcgrail/devel/
Proposed Announcement follows.
Just
This build failed:
https://builds.apache.org/job/SpamAssassin-trunk/8895/
Looking further, is this a Memory issue?
https://builds.apache.org/job/SpamAssassin-trunk/8895/testReport/make_test/
t_spf_t/test__3/
I don't think it's a memory issue.
Why are we failing on a new for DNS?
Aug 6 08:24:47.384 [6584] dbg: dns: is Net::DNS::Resolver available? yes
Aug 6 08:24:47.384 [6584] dbg: dns: Net::DNS version: 0.49
Took some effort to find a Net::DNS that old (March 2005, 8+ years),
it is no longer on CPAN.
# Current time GMT: Tue Aug 6 08:52:22 2013
[...]
Aug 6
Malformed UTF-8 character (unexpected non-continuation byte 0x6e,
immediately after start byte 0xf6) in transliteration (tr///) at
/data/masscheckwork/weekly_mass_check/masses/../lib/Mail/SpamAssassin/DnsResolver.pm
line 627.
On a second thought, this should never have happened.
It indicates
On 2013-07-13 15:41, Axb wrote:
my weekly masdcheck which just ran a while ago spit a huge list of
Malformed UTF-8 character (unexpected non-continuation byte 0x6e,
immediately after start byte 0xf6) in transliteration (tr///) at
At last I went through build/announcements/PROPOSED-3.4.0.txt
and changed most of my shorthands/itemizations into a (hopefully)
more readable prose. It is longish, please feel free to re-edit it
in any way you (all) see fit.
As far as the code is concerned, I think it is ready for rc3 and
the
On Sunday 23 June 2013 17:48:46 Benny Pedersen wrote:
also missing redis plugin seen in diag, what perl module is needed
for this ?
Module is 'Redis', version 1.954 or later:
http://search.cpan.org/~melo/Redis-1.961/
Mark
Please vote to release 3.4.0-rc2.
Files at http://people.apache.org/~kmcgrail/devel/
Looks good, signatures are alright, tests pass,
diff to trunk makes sense.
+1 for rc2
Proposed Announcement follows.
Was distracted by Bug 6945 and other duties yesterday so
I didn't yet prepare other
+1 for rc2
I think you are actually voting against it with your statements below.
A release candidate *is* the release.
If it is voted yes, the actual release is built from the same code for
the rc with a version change. You can't vote for rc2 + extra stuff [...]
So I'm reading this
Ok, let me put it this way: I'd publish the RC2 as it is and let people
play with it for few days, hoping for some feedback.
Likely my poor wording in the request for a vote coupled with the length
of time since a previous release but rc2 *is* published. You aren't
voting to publish rc2.
Was distracted by Bug 6945 and other duties yesterday so
I didn't yet prepare other contributions for the announcement
text. Will do so, but for RC2 it's alright as it is.
[...] though I would be fine with README and similar
text/grammatical/reformatting changes.
Did some more editing on
On Friday 21 June 2013 19:44:05 Benny Pedersen wrote:
mark.martinec...@ijs.si 2001:1470:FF80:0088::
how can awl get this in from my mta in ipv4 ?
By parsing Received header fields. Even if last mail hops were
over IPv4, a mail message may still have traveled through,
or be submitted from an
So, we wouldn't be able to unlearn historical emails (processed
before the upgrade),
Yes.
but there'd be few other side-effects?
Right, practically no other ill effects. The tokens format remains unchanged.
yes old learned mails cant be unlearned, even bayes_tokens is equal,
it cant
On Wednesday 19 June 2013 10:51:05 Axb wrote:
Unless Marc comes up with more drastic changes, or Henrik reports some
issue, I'm ok for a RC2.
My Redis update worked well (after some sweat/handlholding) and is in
production.
No further changes to code are planned from my side.
I may tweak the
i have not taked into account that the backup format could have changed
aswell, with makes it pointless to make backup
The backup format hasn't changed.
You may create a backup bayes file in your current setup (SQL or whatever)
using sa-learn --backup filename, then switch to a Redis backend
The backup format hasn't changed.
not even bayes_version ?
Remains unchanged.
You may create a backup bayes file in your current setup (SQL or
whatever)
using sa-learn --backup filename, then switch to a Redis backend
and reload a database with sa-learn --restore filename
this
I may tweak the PROPOSED-3.4.0.txt a little today,
need to check the Changes log.
Excellent.
Committed a first round of edits on PROPOSED-3.4.0.txt, mainly
dealing with a Redis backend. Please edit/revise to will...
Some more is to come probably...
Mark
Some more is to come probably...
I have now assembled about 200 text lines from SVN change logs
of the more pronounced changed since 3.3.2. Still needs to be
compressed and converted into a readable prose before adding
to release notes. Later...
Mark
To be clear, if the polish involves changing the code, then you are
asking for an rc2.
The changes should be reflected in RC1 to avoid ppl having to trash
their Bayes data due to a data format change. This would not be very
kind and could scsare potential early adopters away and give
I'm sorry the work on Lua happened to coincide with Kevin's work on RC1.
No worries! I've been documenting much more of the process which is the
real time drain. I can cut a new rc in a hour or sooner now I believe
other than waiting for a make disttest to complete.
Should I wait 1 week
Axb,
Testing was under Redis 2.6.13, perl 5.18.0, on FreeBSD.
Are you using Pedro Melo's Redis Perl module?
http://search.cpan.org/~melo/Redis-1.961/
Indeed, still at 1.951 (from ports).
I see I need to update to a more recent version...
Mark
Quanah Gibson-Mount wrote:
Ok, so I should be fine if I update my source checkout? ;)
Yes, should be just fine.
- running in production under perl 5.17.9 (FreeBSD),
- tested on an IPv6-only host (works fine except Razor,
using an external DNS recursive server on a dual-stack host),
-
bugzilla-dae...@bugzilla.spamassassin.org skrev den 2013-02-21 03:56:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=4877
is there a sample domain to test with ?
it would be incorect to to solve domain owners faults in dkim
what Mail::DKIM was this bug created with ?
There is
me writes:
I'd leave out all the 'promotions validated' and 'auto-generated rules'.
Kevin writes:
I might get around to that but it's pretty low priority for a Changes
file. Do you have an automated command that could do that so we can
update the build/README file for the Create the
I don't know if this is worth submitting a bug or not.
It is, please do so. Cosmetic, but head-scratching.
When I run 'perl Makefile.PL' I get the message:
NOTE: the optional fetch binary is not installed.
And then the explination about IPv6. But as I do have both curl wget
installed,
$ svn ci -m 't/rule_names.t fix for
Parse errors: No plan found in TAP output'
Sending t/rule_names.t
Committed revision 1429187.
Now it's skipping t/rule_names.t - was that the intent?
Yes, this is now as it was and as intendend.
That rule is controlled by
run_rule_name_tests=y/n
(re-sending the message for the second time without a list of rules,
which caused posting to bounce at mx1.eu.apache.org: due to hitting
[can't name the hitting rules to avoid hitting them again])
I'm going through tests which report skipped: (no reason given),
checking to see what it takes to
Back to the two URIBL tests.
https://builds.apache.org/job/SpamAssassin-trunk/8283/testReport/
Anyone got a moment to look into this?
We've ween this before (need to find a ref...).
The additional text on URIBL rules can be wrong (belonging
to another test). Running the same test more
Kevin,
OK, so we are consistently failing this test on Jenkins
[...]
But your thinking this is a bug similar to freemail where we have
incorrect output going into the report?
I think so, but I need to check to make sure.
Or could it be something DNS related such as rate limiting?
Not
On Saturday January 5 2013 01:07:09 John Hardin wrote:
On Fri, 4 Jan 2013, Kevin A. McGrail wrote:
FYI that rule_name.t failed for me during a make disttest.
I'm getting this with an up-to-date sandbox:
Test Summary Report
---
t/rule_names.t (Wstat: 0
t/rule_names.t (Wstat: 0 Tests: 0 Failed: 0)
Parse errors: No plan found in TAP output
Files=167, Tests=3079, 1551 wallclock secs ( 1.61 usr 0.36 sys + 920.64
cusr 37.64 csys = 960.25 CPU)
Result: FAIL
Failed 1/167 test programs. 0/3079 subtests failed.
Yes, my
Kevin A. McGrail wrote:
1 - Anyone know what the made-doc-stamp file does?
no idea
2 - Should a prelease version still include the svn revision?
SpamAssassin 3.4.0-pre1-r1406273. This is during the testing as part of
the build process.
Can't hurt to have it, makes it easier to find the
On 12/14/2012 12:33 PM, Mark Martinec wrote:
2) ask the Net::DNS folks if they'd be willing to put back the
unconditionally double-quoted form for 0.71, and keep it there
for at least until SpamAssassin 3.4 really hits the streets;
meanwhile suggest people to switch Net::DNS to 0.71
I think we will focus on 3.4 released with the fix.
People using 3.3 can apply the patch, yes?
This is certainly an option. Timeliness of this depends much
on the responsiveness of popular Unix/Linux distributions,
I'd expect that a majority of end-users are reluctant
to apply local patches if
This means if we have to
drop support for older Net::DNS, I would support that as well.
No need to, this is not in question.
Right now, as I understand it:
A) you've already patched sa-update in trunk to handle this and it works
with older and newer Net::DNS versions
Right.
B) Rather
Any thoughts on the workaround as proposed by Willem?
Anybody familiar enough with the DNS infrastructure
of the project to dare implementing it?
Mark
I tried to report to the bug tracker but it's down:
https://issues.apache.org/SpamAssassin/
Don't know, seems fine now.
Please open a PR anyway for documentation purposes.
Net::DNS has broken sa-update -
https://rt.cpan.org/Ticket/Display.html?id=81760
Interesting. The Net::DNS 0.68 docs
Axb,
Such a sample doesn't convince me (Yet) as it doesn't show potential FPs
due scans on raw encoded attachments after 4 lines of txt/html as well
as timing per body rule type.
Could you let me have this sample corpus to compare results with
spamc/spamd under different conditions?
On Tuesday October 23 2012 22:26:00 Axb wrote:
Spamc/Spamd's skip size method has made a huge *positive* difference
on FPs, and scan times.
The FNs wouldn't *ever* have been caught by a chunk method due to the
kind of content included above threshold.
Out of curiosity, during the last 10
On 10/2/2012 12:36 PM, Axb wrote:
Yep - heaven knows why it worked till today and all of a sudden...
Mark made some changes recently. It's possible zlib wasn't require
previously, possibly?
Some changes indeed [Bug 6842],
although I don't think I touched anything regarding zlib.
Mark
On Sunday May 20 2012 21:34:07 Kevin A. McGrail wrote:
I am both humbled and honored to report that I have accepted the
nomination of the SpamAssassin PMC to serve as the new project chair.
On April 18th, the Board of Directors for the Apache Software Foundation
accepted the nomination and
John Hardin wrote:
One thing I noticed while troubleshooting the recent ruleqa problems on
the zone VMs was the number of failed SSH logins to random and system
accounts. I was contemplating putting in explicit DenyUsers for the
various system accounts, but I was a little reluctant to do
It's been a week. But you've been making excellent progress on closing
bugs. If you want to keep that up and put off switching to RTC I wouldn't
object. Hell, I'd bring you a sandwich if you lived within a few hours of
here.
I have the first part of the sa-update change mostly ready, will
Kevin,
I even received an email from AXB that is very simple and failed DKIM tests.
I also found that many emails where I'm disabling iframes, for example,
are what's causing my DKIM errors.
The key idea is to do the DKIM validation *before* sanitizing mail.
What's the easiest way with
- Trunk switches to R-T-C in 1 week in preparation for the release
I think there has been ample warning. Since this has been deemed a
necessary step, how about doing it now? Or tomorrow?
Please wait for a few days more. At least I'd like to finish the
sa-update/IPv6 thing and avoiding one
Seems I've broken some of the SA tests. Will fix these later tonight...
Mark
Seems I've broken some of the SA tests. Will fix these later tonight...
Argh, t/SATest.pm does not have 'use strict', any typo in a
variable name is left unnoticed (or breaks something else).
Ok, looks good now. Fixed dnsbl_subtests.t, t/sa_check_spamd.t,
t/spamd_protocol_10.t, and
Kevin wrote:
- 3.4.0 will be the next release
- 3.3.x development is ceased barring a major bug and we won't backport
changes currently in trunk to 3.3
+1
- Add 3.4 SVN branch and 3.4.0 as a version for Bugzilla
- Add 3.4.1 as a version for Target Milestone
done.
- Trunk switches to
On 2011-09-13 22:23, dar...@chaosreigns.com wrote:
We waste so much time backporting to the last branch. And trunk has been
incredibly stable. I hate to see releases that aren't taken from trunk,
seems like a waste of time and effort.
for once I agree with Darxus :)
There are a few
There are a few usefull additions/fixes in 3.4 trunk which won't ever
get backported and it would be a pity to have to wait
Why not back port the few features/fixes?
diff -U2 sa-3.3 sa-3.4 | (cd sa-3.3; patch)
:)
Seems to me the 3.4 (trunk) is being much better tested by
active
I'm trying to review svn revision 1165372. Anyone know the command /
url to give me a patch of these changes? I want to try it with 3.3 and
some other changes I've been working on and I can't remember a way to do
this.
svn diff -c1165372
Mark
On 6/7/2011 7:22 PM, Adam Katz wrote:
header EXTRA_MPART_TYPE Content-Type =~ / type=/i
On 06/07/2011 08:00 PM, Matt Kettler wrote:
A lot of times rules start off with the writer thinking about the
whole line, and after they put it down as a rule, there may be
frivolous
1 - 100 of 310 matches
Mail list logo
