post icon [news] [activity] Projects Activities
[2018-09-30 07:04 +0200] WIP DuckCorp Infrastructure> Revision 6a6e1853 (duckcorp-infra): Merge branch 'duckland_new_isp'
[2018-09-30 07:04 +0200] WIP DuckCorp Infrastructure> Revision 1a13ada2 (duckcorp-infra): add Elwing L2TP config
[2018-09-30 06:40 +0200] WIP DuckCorp Infrastructure> Revision a96ee758 (duckcorp-infra): add Elwing PPP config
[2018-09-30 05:32 +0200] WIP DuckCorp Infrastructure> Revision 923d57af (duckcorp-infra): add new Elwing network config
[2018-09-22 03:37 +0200] WIP DuckCorp Infrastructure> Revision 839ddca2 (duckcorp-infra): Improve multihoming script
[2018-09-21 03:47 +0200] WIP DuckCorp Infrastructure> Revision fd806bc1 (duckcorp-infra): updated logcheck rules #5
[2018-09-20 17:54 +0200] WIP DuckCorp Infrastructure> Revision bee22da5 (duckcorp-infra): updated logcheck rules #4
[2018-09-20 10:59 +0200] WIP DuckCorp Infrastructure> Revision b5823ada (ansible-role-zabbix): add mailman3 service
[2018-09-20 09:25 +0200] WIP DuckCorp Infrastructure> Revision 5eb4ca9b (duckcorp-infra): remove user laura
[2018-09-19 21:23 +0200] WIP Bip> Bug #636 (New): Build fails with GCC 8 due to format truncation errors
Word from the Admin Team
[archives] « Mail Revamping #2 »


Mail System Redundancy

Our old antispam system has been shutdown and Toushirou has been promoted to full MX1/MDA/MAA. This means we now have two machine receiving mails, filtering spam and synchronizing with each-other (SIEVE rules and antispam learning are synced too).

I just updated the DNS records so that {smtp,mail,imap,pop,sieve} now balance between the two. So if one machine is down, you should be able to retry to reach your mail on the second machine.

The webmail is currently not redundant but we’re working on it.

The mailing-lists will stay on Orfeo as there is currently no way to make this service redundant.

Note about the Antispam

We had some user questions so I wanted to clarify a few things.

The new learning system is very similar to the previous one. The big change is: from now on all learning is shared between users. This means you benefits from SPAM caught by other users but it makes the learning less personalized. It is difficult to evaluate what’s best but per-user learning made the system very complex and was very resource intensive so we decided to try the shared method. Many well known big companies also use shared training, so that new users don’t start with a blank system which would need weeks or months to be well trained and it seems to work quite well.

Another important point is how to train the system. We simplified the old system and the new one does not have a web interface for users anyway. The ‘Junk’ folder (your mail client may translate the name) is used to collect discovered SPAM. If you move mails into it you inform the system it is a spam it should have caught. If you move a mail out of it then you inform the system it made a mistake and this is not a spam.

To get detected SPAM automatically put into the ‘Junk’ folder there is a default SIEVE filter. But if you added your own filters, then you need to include the default rule into your configuration as explained here:

This was done to allow users to override the default rule if they wanted another workflow. We’re wondering if this has any real application and thinking about making this rule compulsory (processed before any user filters). Your input on this matter is welcome.



  • Not f'd — you won't find me on Facebook

Special Support

  • FSF Member Logo
  • DUC Logo


  • Hivane
  • Nerim