Bug #5101


Fix issue with default value for mail_to that leads to incorrect target email for

Added by Jan Mach over 3 years ago. Updated over 3 years ago.

Development - Core
Target version:
Start date:
Due date:
% Done:


Estimated time:
To be discussed:


I was notified about he issue with on our production server. Apparently some organizations were not receiving reports for some time. Investigate and fix it.

Actions #1

Updated by Jan Mach over 3 years ago

I have identified the source of the problem. There are default configurations in core/common.json.conf configuration file for mail related stuff. The important thing is, that there is also a default value root for mail_to setting. The whole thing is designed to prevent Mentat system from accidentally spamming real world abuse contacts and this value takes overrides the values for abuse groups from database. Thanks to this design it is possible to simply set mail_to: "root" as a default setting and you can be "sure" no email will be send to the world after default installation. When you want to enable sending reports in production environment, you have to either disable the default setting in core/common.json.conf, or override it to mail_to: null in file.

I have included this piece of information into all relevant configuration files and documentation pages related to reporting configuration.

I have fixed the reporting configuration on our production server and I am currently waiting for some data to appear to verify, that emails are actually sent to target abuse contacts.

Actions #2

Updated by Jan Mach over 3 years ago

  • Status changed from New to Feedback
  • Assignee changed from Jan Mach to Pavel Kácha
  • Priority changed from Immediate to High
  • % Done changed from 0 to 90

Pavel, this design have caused us some problems. I think that by enhancing the documentation I have resolved them. I still think, that the default configuration should prevent from unwanted spamming. I still think, that a mechanism needs to be in place that enables administrators to override reporting settings coming from database and thus provides the ability to run development/testing instances of the system.

What is your opinion about this design decision (configuration file values take precedence over settings coming from database). Does it make sense to you too, or should it be changed to something else to be more clear and prone to errors?

Relevant documentation is here, does it make sense?

P.S. At the time of this comment there still was no data to be reported, so I was not able to verify yet that the issue on our production system is resolved.

Actions #3

Updated by Jan Mach over 3 years ago

Latest patch adds new features to reporting dashboard and informant emails, that will hopefully enable system administrator to spot problems with reporting more quickly (version >= 2.3.25).

Link to dashboard:

Actions #4

Updated by Jan Mach over 3 years ago

  • % Done changed from 90 to 100

As a result of working on system monitoring I have also reworked existing database sanity checking scripts. Email reports are now better formatted, configurable and integrated. There are also extended email headers for better automated processing. A lot of improvements can still be done, but for now it should be adequate.

There is a link to the documentation for more information:

Actions #5

Updated by Pavel Kácha over 3 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF