1

Topic: post upgrade - 42K records in mysql blacklisting

==== Required information ====
- iRedMail version (check /etc/iredmail-release):
- Linux/BSD distribution name and version:
- Store mail accounts in which backend (LDAP/MySQL/PGSQL):
- Web server (Apache or Nginx):
- Manage mail accounts with iRedAdmin-Pro?
- Related log if you're reporting an issue:
====

0.9.4 with 2.3.1 Pro
CentOS 6.7
MySQL

Looked at the Admin log and discovered large vol. or Blacklist Reject.  Example:
REJECT Blacklisted (bounce-use=m=32267300073=echo3=577ed63ca0cb1b801c52ab662de45437@returnpath.bluehornet.com -> user.name@domain_name.tld, amavisd_wblist)

I do not think that this normal since I've never seen such previously.  Is this normal or problem?  Is it amavisd_wblist or iRedAPD causing issue?

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2

Re: post upgrade - 42K records in mysql blacklisting

You can turn off this in iRedAPD config file (/opt/iredapd/settings.py):

log_action_in_db = False

3 (edited by pbf343 2016-02-04 10:22:37)

Re: post upgrade - 42K records in mysql blacklisting

ZhangHuangbin wrote:

You can turn off this in iRedAPD config file (/opt/iredapd/settings.py):

log_action_in_db = False

Thank you. 
What would be the reason, logic and/or scenario where one would NOT want to turn if off?   
   One possible example:  you've granted users access to the iRedAdmin-Pro control panel but not shell to access logs.

Is this data cleaned out by any of the cron job scripts at some point or persists until when?

Would it be better to log this data under a different reference in the application.  It seems like one would want the "Admin Log" specifically for actions taken by authenticated users of the system for audit/security reasons.

4

Re: post upgrade - 42K records in mysql blacklisting

pbf343 wrote:

Is this data cleaned out by any of the cron job scripts at some point or persists until when?

No.

pbf343 wrote:

Would it be better to log this data under a different reference in the application.  It seems like one would want the "Admin Log" specifically for actions taken by authenticated users of the system for audit/security reasons.

this is a good idea, I will try to implement this in next release. Thanks for the feedback.

5

Re: post upgrade - 42K records in mysql blacklisting

Is the same data actually in the log file or only in the MySQL instance when set to True?

Thinking of your comment about adding... 
It would seem beneficial to have that data accessible by any Web interface admins specific to their appropriate domains when not granting them shell access.   So if Admin1 has access to domain1, domain2, domain3 for example.  The Admin1 would only see such data for those domains (domain1, domain2, domain3) and not others.

6

Re: post upgrade - 42K records in mysql blacklisting

pbf343 wrote:

Is the same data actually in the log file or only in the MySQL instance when set to True?

Both. Logging in SQL database and viewing with iRedAdmin is helpful for admin to view the reject actions without logging to server (via ssh).

pbf343 wrote:

It would seem beneficial to have that data accessible by any Web interface admins specific to their appropriate domains when not granting them shell access.   So if Admin1 has access to domain1, domain2, domain3 for example.  The Admin1 would only see such data for those domains (domain1, domain2, domain3) and not others.

Thanks for the suggestion, i need to think about this.
No promise here, sorry.

7 (edited by pbf343 2016-02-04 20:49:58)

Re: post upgrade - 42K records in mysql blacklisting

ZhangHuangbin wrote:

Both. Logging in SQL database and viewing with iRedAdmin is helpful for admin to view the reject actions without logging to server (via ssh).

Agreed.  Thanks