post icon [news] [activity] Projects Activities
[2018-11-14 02:26 +0100] WIP Bip> Revision aa35b372 (bip): Add unit tests.
[2018-11-14 02:26 +0100] WIP Bip> Revision 34711f76 (bip): Move automake file in src subdir, isolate main.
[2018-11-03 05:28 +0100] WIP DuckCorp Infrastructure> Revision e7091a7a (duckcorp-infra): supervision: enable db config local backup
[2018-11-03 04:09 +0100] DONE DuckCorp Infrastructure> Bug #631 (Resolved): dovecot: dict locking problems
[2018-11-03 04:09 +0100] WIP DuckCorp Infrastructure> Revision 61d0a329 (duckcorp-infra): dc-dovecot: split SQL databases
[2018-11-03 04:06 +0100] WIP DuckCorp Infrastructure> Revision ae87a1a7 (duckcorp-infra): add/remove email addresses for 'arnau' user account.
[2018-11-02 06:54 +0100] WIP DuckCorp Infrastructure> Enhancement #638 (New): maybe replace Passenger with uWSGI?
[2018-11-02 06:20 +0100] WIP DuckCorp Infrastructure> Revision 356ead29 (duckcorp-infra): updated required Ansible version
[2018-11-02 00:07 +0100] WIP DuckCorp Infrastructure> Revision 4531e3f8 (duckcorp-infra): add email address for 'arnau' user account.
[2018-10-31 15:05 +0100] WIP Bip> Bug #637: Segfault linked to NICK handling
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