if running sa-update
then is not feasible.
Sidney
Benny Pedersen wrote on 30/03/24 7:08 am:
Sidney Markowitz skrev den 2024-03-29 15:25:
7e6093c8514e1b18f3b47215dc97d51b7b70142ca2fe7242362c021bf770b2c1c1e99a8227d1c5b9b5d303e405ab9e6a7c67a60b5b03dcb6588bd68c733e2448
Mail-SpamAssassin-rules
cial users to
easily deploy Apache software; the Foundation's intellectual property
framework limits the legal exposure of its 2,500+ contributors.
For more information, visit https://www.apache.org/
--
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
With four +1, no 0, and no -1 binding votes, the vote to release Apache
SpamAssassin 4.0.1 has PASSED.
I will now commence the remainder of the release process.
Thank you everyone who has helped with coding, testing, and bug
reporting for the 4.0.1 release.
Sidney Markowitz
Chair, Apache
7e6093c8514e1b18f3b47215dc97d51b7b70142ca2fe7242362c021bf770b2c1c1e99a8227d1c5b9b5d303e405ab9e6a7c67a60b5b03dcb6588bd68c733e2448
Mail-SpamAssassin-rules-4.0.1.r1916528.tgz
Regards,
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
sid...@sidney.com
.
Please try it out before then if you can.
At that point I'll create the release build and there will be a 72
voting period before the public release process begins.
Sidney Markowitz wrote on 18/03/24 9:23 am:
Hello Everyone,
4.0.1 release candidate 1 of Apache SpamAssassin is now available
for gpg signatures in the .asc files:
Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814
Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45
Regards,
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
tall files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814
Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45
Regards,
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
If it is just a test and you know where to remove it, please go ahead.
giova...@paclan.it wrote on 23/11/23 4:43 am:
On 11/22/23 12:34, Sidney Markowitz wrote:
Does this look like something that needs to be worried about?
I got the impression from some googling that the warning was introduced
Does this look like something that needs to be worried about?
I got the impression from some googling that the warning was introduced
in perl 5.38, but the behavior being warned about always existed.
Running make test from trunk
t/basic_lint.t 5/11 Locale 'zh_CN.GB2312'
The only place I see it is in t/memory_cycles.t which checks for
use constant HAVE_DEVEL_CYCLE => eval { require Devel::Cycle; };
plan skip_all => "Devel::Cycle module required for this test" unless
HAVE_DEVEL_CYCLE;
But it is listed as a test dependency without qualification in
It's been proposed on the PMC mailing list that we put out a new 4.0.1
release to incorporate bug fixes since 4.0.0
Since that is a public dev matter, and there were no objections raised,
I'm moving further discussion here to the pubic dev mailing list.
I'm volunteering to manage the
Giovanni Bechis wrote on 28/12/22 11:43 pm:
Hi,
recently I started receiving more spam from "drive-shares-noreply at
google.com", this spam bypasses filters because it matches USER_IN_DEF_DKIM_WL that
gives the email -7.5 points.
Should we remove google.com from default whitelists ?
Spample
Henrik K wrote on 19/12/22 5:43 am:
Mass check runs from trunk, there are no ties to any specific version, aside
from testing built rules.tar.gz with all 3.4 and 4.0 releases.
It seems like
1. Branching svn would not impact mass check, which will continue to run
from trunk
2. If we ever
Henrik K wrote on 18/12/22 8:18 pm:
This is atleast third discussion of the same? All the previous times it was
concluded that branching wasn't necessary. Backporting is a pain and
usually something is forgotten. It's not like we have any real developing
going on, does anyone even have a
Kevin A. McGrail wrote on 18/12/22 3:45 pm:
One con is that we do need to get masscheck and various tools on the
server to work with the new 4.0 release. I'm not sure my eyesight is
good enough to do it anymore but I'm happy to help!
Questions:
If I were to go ahead and branch, would that
Sidney Markowitz wrote on 18/12/22 9:42 am:
> Now that we have released 4.0.0, we can if we want create a 4.0 branch
> and have trunk be for a 4.1 branch.
Or an alternative that just came to mind:
Is this perhaps the time for us to switch from svn to git?
We already have the git mirror
Now that we have released 4.0.0, we can if we want create a 4.0 branch
and have trunk be for a 4.1 branch.
Pros: If we do it now, then if something comes up that is important
enough to require a 4.0.1 patch release, we will not have commits
already in svn that are not suitable for being
lectual property
framework limits the legal exposure of its 2,500+ contributors.
For more information, visit https://www.apache.org/
--
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
branch in
svn to start parallel work towards a 4.0 release.
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
Michael Peddemors wrote on 15/12/22 6:28 am:
It is a time for rest and relaxation, so you MAY want to delay 4.0
release until after the holidays ;)
This way everyone can install the new version while all the mail servers
are shut down for their annual solstice to New Year break :)
My apologies for fat-fingering an email that was supposed to be sent to
the private PMC mailing list.
At least it didn't contain anything confidential.
The link in there will not be publicly readable until after the Board
meeting happens on 21 Dec, and now you all have a tiny glimpse of the
Hi everyone,
I don't see the usual reminder for our quarterly report to the Board,
but the usual schedule calls for it being due on the second Wednesday of
the month (time zone never specified, and whether at the beginning or by
the end of the Wednesday never specified either).
I've put
-SpamAssassin-4.0.0.zip
8ff0e68e18dc52a88fec83239bb9dc3a1d34f2dcb4c03cd6c566b97fa91242e3c8d006612aeb4df0acf43929eaaa59d542eb5cf904498343adf5eadefcb89255
Mail-SpamAssassin-rules-4.0.0.r1905950.tgz
Regards,
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
sid
and releasing 4.0.0.
Finally!
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
-SpamAssassin-rules-4.0.0-rc4.r1905746.tgz
Fingerprints of keys for gpg signatures in the .asc files:
Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814
Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45
Regards,
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
The remaining issues targeted for 4.0.0 have been closed.
I'm declaring us in R-T-C mode now while I get an RC4 building. If it
looks good, we can go right on to the 4.0.0 release.
I'm not calling for a formal vote on R-T-C. Any committer can vote -1 to
veto the R-T-C announcement if you
The remaining open bugs targeted for 4.0.0 are 8077 and 8078.
8077 has the votes, ready for Giovanni to commit and close the issue.
8078 is a blocker for 4.0.0 and is pending Henrik getting time to spend
on investigation. So that is more open-ended.
I am ready to build an RC4 as soon as the
in the .asc files:
Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814
Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45
Regards,
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
for gpg signatures in the .asc files:
Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814
Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45
Regards,
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45
Regards,
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
The Apache Software Foundation PMCs have been asked to forward this
request to their user and dev communities via their mailing lists:
Hello everyone,
The 2022 ASF Community Survey is looking to gather scientific data that
allows us to understand our community better, both in its demographic
With no votes against, we are now in RTC mode.
Committers, please post proposed commits as patches in a Bugzilla issue
for review before committing. Hold off on anything that is potentially
destabilizing.
It looks like the only thing left before we can produce a release
candidate is Kevin
Kevin A. McGrail wrote on 20/08/22 6:00 pm:
Also, Giovanni and I did a pass on the announcement at
https://docs.google.com/document/d/1BGFFfZlQxYe9-H9AyEY_MVski_VtAaTb-4BLA_exwYs/edit
and it's ready we believe. The word wrapping will need work when it's
brought back to ASCII, sorry.
Kevin A. McGrail wrote on 20/08/22 6:00 pm:
A pre-release doesn't require RTC so I'd suggest we either 1) use CTR and a
pre-3 *or* 2) I'd be +1 for RTC and a rc1.
Also, Giovanni and I did a pass on the announcement at
We are down to no more open bugs and sufficient success on the CPAN test
machines. My understanding is that testing of trunk in production environments
has gone well.
If nobody has anything that they are working on that they intend to commit, or
any other issues to bring up, I would like to
:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45
Regards,
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
Henrik K wrote on 10/05/22 4:21 pm:
A quick hack to run it without taint, created t/perlcritic.t which contains:
#!/usr/bin/perl
$ENV{'PATH'} = '/bin:/usr/bin';
-d "xt" && "$^X xt/60_perlcritic.t" =~ /(.*)/ ||
"$^X ../xt/60_perlcritic.t" =~ /(.*)/;
exec($1);
That happened to work
Henrik K wrote on 10/05/22 4:21 pm:
A quick hack to run it without taint, created t/perlcritic.t which contains:
#!/usr/bin/perl
$ENV{'PATH'} = '/bin:/usr/bin';
-d "xt" && "$^X xt/60_perlcritic.t" =~ /(.*)/ ||
"$^X ../xt/60_perlcritic.t" =~ /(.*)/;
exec($1);
I submitted a bug
Thanks, Henrik for this and the other little test things. They were
bothering me every time I ran tests the past few days while working on
the big test issues, but I had to put off fixing them.
Isn't nice when tests produce so little noise that you can finally see
the cosmetic or little
Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45
Regards,
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
It was pointed out to me that we should be calling the builds
"pre-release", we are not yet far enough along for something called a
"release candidate". With the build now at the point that make test
passes all tests without requiring it be in a checked out svn trunk
directory, and no open
Kevin A. McGrail wrote on 1/05/22 6:58 pm:
I'd recommend the next build is a prerelease build instead of an RC
build until a few people report they are running it in production. I'm
working hard to get it into production at PCCC.
+1, will do. It's just a name, and a more accurate one in this
Ok, back to CTR we go!
I'm sorry to jump back and forth on this, but the reasons for being in
R-T-C seem to have disappeared. That is something to do when there are
no more open bugs before a release and we don't want to make any new bugs.
Now it seems that there are bugs for 4.0.0, we expect to find more, and
it
Kevin A. McGrail wrote on 1/05/22 3:47 pm:
A) When was that MANIFEST change because I do believe there are a couple
of items that should be included. I think it's used with ruleqa or
something.
r1880742 | gbechis | 2020-08-11 02:29:41 +1200 (Tue, 11 Aug 2020) | 2 lines
Changed paths:
M
The instructions in build/README say to only link when doing it in a
branch. I did track the problem down to a commit that removed
20_aux_tlds.cf from MANIFEST along with another rules file, saying it
should come from sa-update. Even if I put them back, there are still
other tests breaking
A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
On Sat, Apr 30, 2022 at 9:38 PM Sidney Markowitz wrote:
I messed up with make test during the release candidate process.
I hope that I just have my setup
I messed up with make test during the release candidate process.
I hope that I just have my setup wrong, because I expect this would have
been mentioned before now if everyone gets it.
In trunk, or equivalently 4.0.0-rc1, with a clean environment,
perl Makefile.PL
make
make test
results in
I've created a new issue marked as blocker for the 4.0 milestone as a
place to concentrate discussion on remaining tasks for the release that
don't fit into other open issues.
Sidney
gt;
> On 4/30/22 11:52, Axb wrote:
> > Should we update [2][3]20_aux_tlds.cf for this relesase?
> >
> > I can't do it at the moment - any taker?
> >
> > On 4/30/22 11:27, Sidney Markowitz wrote:
> >> It's time fo
Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45
Regards,
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
It's time for a code freeze in preparation for the release of 4.0.0
release candidates.
Please do not commit anything to trunk other than the usual ongoing
rules stuff that finds its way into the rule update process.
Any new bug fixes that need to be committed for 4.0.0 should be
associated
Henrik K wrote on 30/04/22 6:13 pm:
Shall we start rolling rc's out, all bugs are closed?
That's fine with me. I'll start making one while checking whether an rc
needs a vote to be official.
If anyone can think of anything else that should be done before there is
a release candidate,
David Bürgin wrote on 23/04/22 5:32 am:
Have you considered migrating to Git before the next major release? It
has many advantages over Subversion, and would make development more
accessible and transparent for other developers.
I personally prefer working with git as compared to svn, but I
We are down to six open issues on Bugzilla with a 4.0 milestone, none
listed as blockers. Let's see if we can get a release out. I'll take
care of the release manager duties. Henrik volunteered to spend some
time wrapping up issues during the next few weeks. Of course anyone else
can help too.
Aside from anything else about this, we are overdue implementing the
phase-out of sha1 hashes in rule updates and the freezing of pre-3.4.2
rule update files to the last one published with sha1 hashes.
dar...@chaosreigns.com wrote on 13/04/21 11:00 pm:
SpamAssassin version 3.3.0 has not had a
re information, visit https://www.apache.org/
--
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
files:
Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814
Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45
Regards,
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
Henrik K wrote on 8/04/21 4:46 pm:
Could we also add 7892 in, as it's 100% trivial and safe change?
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7892
Then the other one I marked, which is not as trivial. It will rarely add an
extra wrong DNS query, which could by fixed by
Bill Cole wrote on 8/04/21 3:33 pm:
The string T_KHOP_BOTNET_4 (apparently a rule name) does not occur
anywhere in the 3.4 branch or in trunk.
Theory: it's seeing a bogus rule file that isn't in the distribution.
Maybe a user_prefs file?
After carefully ensuring that trunk was a clean
Here are failures I got running in the 3.4 branch with the rules, rulesrc, and
t.rules symlinked to trunk.
sudo make test TEST_FILES="xt/*.t"
in macOS 11.2.3
I'm not deep enough into the code to address the issue right now, just
following release steps.
Can someone please look at this and
I already mentioned this in another thread, repeating it with a suitable
Subject for clarity.
It looks like we will release version 3.4.6 to fix bug 7897 that is a
regression introduced by the fix for bug 7822. The proposed fix will revert to
the bug 7822 incorrect behavior, which is
Bill Cole wrote on 8/04/21 10:09 am:
I believe we should release a 3.4.6 in the near term (days not months)
to fix 7897 even if we have to do it with 7822 unfixed. I'd rather both
were fixed but I don't have the free cycles right now to get a good
enough understanding of the entanglements to fix
Henrik K wrote on 7/04/21 1:31 am:
I think we should release 3.4.6 because of this bug:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7897
Metas depending on uribl rules do not currently hit.. :-(
Though it seems there aren't any metas in stock ruleset that are affected.
I do have on my
SpamAssassin has not had working instruction for building under Windows since
version 3.4.1 and ActivePerl's switch to using dmake.
It looks like an alternative should use Strawberry Perl but what we have now
fails to build with it.
Does anyone here have the Windows experience and
team, please e-mail
security at spamassassin.apache.org. For more information about Apache
SpamAssassin, visit the https://spamassassin.apache.org/ web site.
Apache SpamAssassin Security Team
[1]: https://s.apache.org/ng9u9
[2]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-1946
--
Sidney
agmatic Apache License enables individual and commercial users to
easily deploy Apache software; the Foundation's intellectual property
framework limits the legal exposure of its 2,500+ contributors.
For more information, visit https://www.apache.org/
--
Sidney Markowitz
Chair, Apache SpamAs
John Hardin wrote on 18/03/21 1:48 pm:
Are there guidelines for how to (not) comment on the commit that fixes a
CVE? Blocking public access to a bug doesn't help obscure the fix if the
public comment on the fix commit is referencing a locked security bug...
What kind of comment would that be?
I've completely rewritten the wiki page describing our project's process for
handling reports and fixes of security vulnerabilities because it did not
match what we actually do.
https://cwiki.apache.org/confluence/display/SPAMASSASSIN/SecurityPolicy
I have a point I would like to bring up for
this another two days. If there are no negative responses to
consider, I'll proceed with the next steps in the release by building what we
currently have as 3.4.5.
Regards,
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
sid...@sidney.com
-SpamAssassin-rules-3.4.5-rc2.r1887567.tgz
Fingerprints of keys for gpg signatures in the .asc files:
Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814
Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45
Regards,
Sidney Markowitz
Chair, Apache SpamAssassin PMC
sid...@apache.org
Benny Pedersen wrote on 16/03/21 5:46 pm:
On 2021-03-15 23:32, sid...@apache.org wrote:
+ pyzor
+ razor
why in build stage ? :(
we would love to see no plugins enabled pr default, and if wanted
enabled make guides on what to do for enable it imho would be more
helpfull, i say this
security issue requires it.
Committers, since this is documentation, not code, and in any case not in the
3.4 branch, that file is not subject to the RTC code freeze 3.4 is now under.
Thanks,
Sidney Markowitz
Chair, Apache SpamAssassin PMC
Benny Pedersen wrote on 10/03/21 6:41 pm:
is minimal version of Mail::DKIM raised ?
It still set in Makefile.PL to minimum version 0.31 recommended 0.37.
Is there a Bugzilla issue for the problem you have described? I'm afraid I
don't know much about DKIM. Nothing new will be going into
We have to release 3.4.5.
There have been three commits since the final preparation of 3.4.5-rc1,
including the fix for the AskDNS bugs and 7875. Those seem safe enough to
include in a release.
Please don't commit to the 3.4 branch without a review and vote (RTC mode),
which should
: If there are student developers posting on users@ or dev@, please take
extra care to guide them and be nice!
More info:
https://summerofcode.withgoogle.com/
and (READ THIS ONE BEFORE APPLYING)
https://community.apache.org/gsoc.html
Sidney Markowitz
sid...@apache.org
Chair, Apache SpamAssassin Project
I opened https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596 and want to
make sure it is noticed in time for our next release. We are required to use
SHA-256 or SHA-512 checksums for our distribution downloads, and to not use
SHA-1. I don't see any reason to use SHA-512 instead of or in
Hi everyone,
This week's announcement of the new Members elected during the annual ASF
Members' Meeting includes one from our very own SpamAssassin PMC, Karsten
Braeckelmann!
https://s.apache.org/D6iz
Please join us in congratulating Karsten on becoming an ASF member!
Thanks,
Sidney Markowitz
[Forwarded by the PMC on request of the Travel Assistance Committee]
Reminder that travel assistance applications for ApacheCon NA 2018 are still
open but only for another 2 weeks!
Please get your applications in NOW.
We will be supporting ApacheCon NA Montréal, Canada on 24th - 29th September
Hi everyone,
The Travel Assistance Committee has asked the various Apache Project
Management Committees to forward the following announcement to the user and
dev mailing lists:
---
The Travel Assistance Committee (TAC) are pleased to announce that travel
assistance
Bill Cole wrote on 3/02/18 6:33 AM:
> username: BillCole
>
> Why: I keep finding wrongness/staleness that I want to fix.
>
> If there's a way for committers to enable this for ourselves, I'm too
> clueless to find it...
I added you to the AdminGroup on the wiki, so now you can fill requests
!
More info:
https://summerofcode.withgoogle.com/
and (READ THIS ONE BEFORE APPLYING)
https://community.apache.org/gsoc.html
Sidney Markowitz
sid...@apache.org
Chair, Apache SpamAssassin Project Management Committee
I'm done with the patches. I verified that I included all the patches you sent
(except the one for Bug 7215 that Kevin G sent, as it looks like we are not
including that in 3.4.2), and checked again that any files that are different
in branch and trunk that I did not port only have the unicode
My apologies to all - I just noticed that I have been using the Version field
in Bugzilla all this weekend when I should have been using Target Milestone.
Now I need to go back to whatever I changed and correct it.
Sidney
Kevin Golding wrote on 15/04/17 8:51 PM:
> Apologies if any overlap
This looks good. I can see from the names of the attachments that most if not
all will be ones I have yet to look at, so the timing is good. I'll grab the
attachments and continue from there for the rest of tonight.
Thanks,
Are any of these relevant for syncing 3.4 with trunk, or are only the files in
trunk used for rule updates? These are the files in the rules directory that
have differences between trunk and the 3.4 branch:
20_dnsbl_tests.cf
20_drugs.cf
20_freemail.cf
20_freemail_domains.cf
20_imageinfo.cf
Kevin, this question is probably for you.
Should I apply thge last four changes to rules/50_scores.cf that were made in
trunk to the 3.4 branch? Only the first of them mentions a bugzilla issue in
the commit message, bug 7282, but I think they are all part of it and that it
makes sense to port.
Kevin A. McGrail wrote on 15/04/17 3:06 PM:
> Plus one here but will note Kevin Golding and I have already been syncing
> trunk and 3.4. I can email you the remaining work tomorrow so we can sync.
I noticed what you have done. So far I'm about to be done with all the non
*.pm files and there are
My task this weekend has been tracking down mismatches between trunk and
branch 3.4 to make sure that anything that has been committed to trunk and is
or should be targeted for the 3.4.2 release has been committed to the branch.
In doing that I'm encountering a number of commits to trunk that do
Kevin A. McGrail wrote on 11/04/17 4:16 PM:
> Any chance you can look at bug 7181 and why sa_compile.t fails?
Fixed.
Kevin A. McGrail wrote on 11/04/17 4:16 PM:
> Any chance you can look at bug 7181 and why sa_compile.t fails? You
> need re2c installed on the machine.
I'll look at.
>
> Also a pass through bugs and blockers in bugzilla would be cool to make
> a list of bugs we want to close in the next 2
Kevin A. McGrail wrote on 10/04/17 1:51 PM:
> Hi,
>
> I'm working on the 3.4.2 RC and I was wondering can step forward and get
> trunk and 3.4 into better sync?
I've got a pretty long weekend coming up, I'll see how much of it I can get
done.
Sidney
We are in the process of migrating off old machines to a new one for the
masschecks and rule update processing.
Unfortunately the required shutdown of the old machines has happened before
everything was complete on the replacement.
The existing data is safe and is being migrated. However
Benny Pedersen wrote on 13/08/16 6:21 AM:
> not all eggs in one basket for me :=)
>
If ASF Infra has properly set everything up they would not have all their eggs
in one basket. To stretch the metaphor way more than it should be... Right now
we have the eggs in a couple of baskets (sonic.net and
Axb wrote on 13/08/16 1:30 AM:
> This dates post-McAfee, pre-Apache days so it goes way back.
Oh, pre-Apache! Now it finally makes sense to me why it is set up like it is.
In any case I have asked Infra for an opinion on whether it is worth
switching. Pro switching - Everything would be in
Axb wrote on 13/08/16 12:26 AM:
> Sidney,
>
> As we don't have the need of donated DNS services anymore I suggest we
> move spamassassin.org to Apache infra (and change @registrar)
>
> Does that make sense?
>
> Axb
>
Good point. I don't know the historical background of the current
[This email is Bcc'd to earlier recipients as I am now moving the discussion
to the public dev@ mailing list]
This thread got started on the private SpamAssassin PMC mailing list when we
were notified there of a required infrastucture update for our DNS. In keeping
with Apache Software Foundation
[This email is Bcc'd to earlier recipients as I am now moving the discussion
to the public dev@ mailing list]
This thread got started on the private SpamAssassin PMC mailing list when we
were notified there of a required infrastucture update for our DNS. In keeping
with Apache Software Foundation
John Hardin wrote on 16/06/16 11:50 PM:
> Anyone who wants to contribute to masscheck should drop Sidney a fresh
> note now, I don't think we should rely on him being forwarded that
> information from KAM.
>
Oh, definitely send a fresh note, as usual to private@ as described on
, patches welcome.
Regards,
Sidney Markowitz
1 - 100 of 439 matches
Mail list logo
