Support

My understanding is that if we disable this email (blank it out), we don't get a critical notification, such as a new superuser being added (typically a compromise indicator).

Correct, you are not going to receive an email, but the request has been blocked anyway. The idea is that you let Admin Tools handle security instead of constantly nannying your site. In this example, the whole point of the "Monitor Super User accounts" feature is to prevent a new Super User from being created outside of Joomla's Users page. This neutralizes the kind of critical vulnerability you have in mind and which we've seen (quite a few years ago, to be fair) in high profile components like VirtueMart and AcyMailing. Being notified that the Super User creation was blocked does not add anything to your security. You will still not know how this came to pass; you will only know that Admin Tools prevented this from happening, as configured. So, really, is there a point in the email? I doubt it.

However, there are other valid use cases where some emails are desirable, e.g. "Monitor Critical Files", "Monitor Global Configuration" etc. These don't block anything, they just email you. For these, you can enter an email in "Email this address on blocked request" and add all reasons you do NOT want to be notified about in "Do not send email notifications for these reasons". When you see the notification, click on "Hide this message".

It would probably make a lot more sense to have separate email addresses for features depending on whether they are blocking requests, or informative. The problem is that some features can be either. One way to handle that would be setting up a different email address per email type, which is probably how this is going to be implemented in the future.

Maybe we are misunderstanding, but if we hit the "Disable emails" button on the warning, it clears the "Email this address on blocked request," and thus, we won't get these notifications.

This is strange. The setting does persist, and your use case is why it exists, as I explained above.

If for any reason it appears to not save your preference (maybe Joomla's cache is not wanting to reset properly?), edit the System - Admin Tools plugin and set "Notice about the Email on Blocked Request" to No.

If you still see the message, you have a caching setup which is not working right. It could be either the Joomla cache not clearing properly, or having a CDN, caching system, or reverse proxy in front of your site. In the latter case, please make sure that the entire /administrator of your site is set up to never be cached by the CDN, caching system, or reverse proxy.

This is really strange, indeed. When you click that button we do a request to the Admin Tools component which sets the option to the plugin's settings, and clears the Joomla plugins cache. Or, at least, it asks Joomla to clear the plugins cache.

Can you please tell me your caching options? I am interested in Progressive vs Conservative caching, and which cache handler you are using. These are the two options which have an effect on what Joomla does when you ask it to clear parts of the cache. Maybe there's a combination I've missed?

Thank you, this helps. It looks like the cache group that needs to be cleared was com_plugins, not just _system. I will add this change for the next release which will come pretty shortly.

I spent some time after closing time looking at the email situation. We have the following email types we send out (the mail template slug is in parentheses):

• Troubleshooting email (com_admintools.troubleshooting)
• Configuration Monitoring (com_admintools.configmonitor)
• User re-activation (com_admintools.userreactivate)
• Failed administrator login (com_admintools.adminloginfail)
• Successful administrator login (com_admintools.adminloginsuccess)
• Automatic IP blocking (com_admintools.ipautoban)
• Critical file modified (com_admintools.criticalfiles)
• Monitored file changed (com_admintools.criticalfiles_global)
• Super Users added (com_admintools.superuserslist)
• Rescue URL (com_admintools.rescueurl)
• Blocked request (com_admintools.blockedrequest)
• Lots of blocked requests (com_admintools.delugerequests)
• PHP Exception (no template) 

The three crossed out items are sent to specific users based on runtime parameters, so they are irrelevant to what we were discussing.

Out of the ten remaining items, six already have a specific email recipient address configurable in the configuration:

• Automatic IP blocking (com_admintools.ipautoban)
• PHP Exception (no template)
• Blocked request (com_admintools.blockedrequest)
• Successful administrator login (com_admintools.adminloginsuccess)
• Failed administrator login (com_admintools.adminloginfail)
• Lots of blocked requests (com_admintools.delugerequests)

This leaves us with exactly four items which are currently dependent on the blocked request email address:

• Configuration Monitoring (com_admintools.configmonitor)
• Critical file modified (com_admintools.criticalfiles)
• Monitored file changed (com_admintools.criticalfiles_global)
• Super Users added (com_admintools.superuserslist)

I will add a configurable email recipient for each one of them. If it's left empty, it will reuse the blocked request email address as was the situation up until now. Otherwise, the specific email address you use will be used.

This will happen in the next version, allowing you to completely disable the blocked request emails without missing the email notifications for these features. All but the one you mentioned (super users added) do need to send an email to make sense. Thank you for prompting this investigation!