Mailing List Max Triggers per Day

[EKjellquist]

We upgraded directly from 2.xx to 4.1.2 (using the upgrade tools) so I may have missed a change somewhere in past years in functionality, but we had mailing lists set up (since '06, most of them) as department emails, some of them able to be triggered by anyone, some with a trigger phrase or some only by senders on the list itself. However, at one time, I could put in 0 for the 'Max Triggers per day' variable and it would allow for unlimited triggers (effectively an 'off' flag). Largely this was the default we used back then if we didn't want to have a maximum, and I haven't updated these variables since then.

Yesterday I had someone show me some odd behavior in email, turns out at least in 4.1.2 that a 'Max triggers per day' of 0 effectively allows 0 triggers! I also had to increase the maximums for most other lists we have, but that's understandable with traffic scaling up over time; the issue was that in the logs I had no real way of knowing that this was the cause of undelivered mail - I couldn't find any entries along the lines of, say [Delivery Failed: Mailing List Maximum Triggers Reached] or similar.

There appears to be no log entry (maybe in debug logging?) for a mailing list hitting its maximum # of triggers; does the option near the bottom of the Mailing List setup page "Notify on delivery triggers fail" fire off when the max is reached, or is this option primarily for delivery problems for individual recipients on the list? On one hand this would help me troubleshoot, on the other hand, I don't want a ton of notifications when antispam rules prevent delivery of bad mail that goes through the list(s)...

Increasing the maximum #'s is fine for the time being, but I guess I'm asking if it's feasible that a checkbox be added in to enable / disable the "Max Triggers Per Day" variable, or restore the old behavior of 0 triggers being "unlimited"? Also, I'm assuming AMS treats a 'day' as 12:00 AM to the next 12:00 AM, but could there be a read-only field on the mailing list management page, or perhaps a static variable available so we can check how many times a list has been 'fired'? Afaik there's no specific mailing list log at present, only the SMTP history of someone sending to the list itself; could we have an optional mailing list log option?

[Code Crafters]

Using zero should probably not be allowed for this setting; we will add a range validator to this setting to prevent this. We may consider adding a checkbox to this option to remove the limit. For now you can just set this to a really high number (up to 2,417,483,647).

Notify on Trigger Fail will inform whoever is in the To of the notification in the settings of any failed triggers including exceeding Max Triggers.

We don't generally recommend having mailing lists with no security of who can send to them though. If these are internal mailing lists for your Ability Mail Server users then you should consider Shared Address Book Groups as an easier way to send to groups of your users without the risk of non-Ability users being able to SPAM the group.

We are not planning to add a counter or mailing list log of triggers at this time.

[EKjellquist]

In a number of cases I do need lists that are accessible by non-AMS users because we need a way for external users to be able to copy or send directly to a group of recipients for notifications (some lists that are purely internal, yes we do enforce the available limitations). Part of the reason for this is I am not currently allowed to update our website's 'contact us' page (it needs captcha and an overhaul of anti-bot mechanisms) in order to close that hole. We've traditionally left sales@domain.com as the only email address posted out on the web statically that people can get to (with obvious consequences). A checkbox to disable the max is all we really need at a minimum. I forget what 2.xx version it specifically worked in, but you could enter a blank or 0 to disable the max, the web admin interface does seem to have a validator in it, as I can't seem to save a blank in 4.1.2.

Incidentally, should only a successful delivery to a mailing list via SMTP increment the counter? it appears possible that even when spam gets sent to sales@domain.com and gets blocked by one filter or another it could still be triggering the counter (which may be how this situation began). However, afaik there is no way for us to 'see' the variable count value as it changes, can you test or verify this on your end?

Also, we used mailing lists for department emails in the beginning because they're very simple to set up and easy to use (we used to have major issues trying to get our mail clients at the time to connect via LDAP to the address books, in addition to the fact that afaik AMS is not currently able to handle secure LDAP yet). Would it be possible to update the option "Only Trigger When SMTP Sender is on the delivery list" so it'd be possible to allow that OR the ability for anyone with an account w/i that AMS domain to also be able to send to the mailing list? We COULD do that with trigger phrases, but it would be a lot simpler with an option like this at the mailing list level...

[Code Crafters]

It does seem possible to enter 0 for the Max Triggers in the latest update (currently 4.2.1). We'll fix this to not allow this in the next update. We may also add the optional Max Triggers in the next update too if we can.

Any successful trigger of the mailing list increases the trigger count. All filters other than user filters are applied before attempted delivery so any filters blocking the email wouldn't trigger or increase the trigger count.

We would love to add lots of status information into the settings. However, the only real-time status information is currently on the status page of the admin interfaces. Real-time statistics in other areas would be a lot of work to add so we won't be adding these in any near future updates I'm afraid. You can create custom logs with Content Filtering though if you want to track any traffic to your mailing lists.

Secure LDAP isn't as straight forward because this is a binary protocol and not text based like other protocols. We have no plans to add secure LDAP in the near future but we'll add it to our feature request list.

As for your "anyone from that domain" authentication, email addresses are easily spoofed so you'd really need something more like "users with relaying access (via SMTP authentication)" but then that wouldn't be specific to that domain. We'll consider other options but can only add ones that are easily identifiable and secure. You can of course use content filtering to further control the security of mailing lists for almost any custom scenario.

[EKjellquist]

Users with relaying access would work for us (since currently this is a single-domain installation of AMS), but I see your point. It should work in our case as we require secure logins for all local users, and those are the only users with relaying access on this server, which is the only server for this domain, so while I suppose it's not impossible to spoof user email addresses, that's one of the things we never see..

[Code Crafters]

For now, you'll have to add those users to the mailing list for them to be able to trigger it.

[Code Crafters]

We've released Ability Mail Server 4.2.2 (http://www.codecrafters.com/AbilityMail ... ateHistory) which includes the fix to not allowing 0 Max Triggers Per Day. However, we didn't add the optional checkbox for no limit at this time as you can simply add a high number to achieve the same result for now. We may consider adding this in a future update though.

[EKjellquist]

Installed that update the other day, appreciate the openSSL update also

My next question relates to one of my other posts, but it's more about Mailing Lists; We frequently use sales@domain.com as one of the big ones for our sales folks, and they often use it as a cc method to communicate (they haven't accepted other ways to accomplish this, e.g. Slack or other team-based messaging or CRM / CMS). I adjusted our main Bayesian filtering rule for sending addresses ending in .us to be moved to quarantine, because most of the spam that makes it through the filters comes from rogue .us domains that have valid SPF records etc, and we have very little legit .us traffic.

What seems to occur is that any mail from a *.us sender to a local account (or gets caught w/i my Bayesian range) does indeed get filtered according to the rule I set, but when a mailing list is a recipient, the rule doesn't seem to apply correctly (or perhaps the mailing list mechanics fire off after content filtering?). The mailing list doesn't, of course, have its own set of account folders so it's not like it has its own Quarantine folder, but I expected that since the mailing lists just trigger a delivery to whatever addresses (which may or may not be local to the server), that those triggered mails that ARE local would then be subject to the content filtering rules.

So what happens appears to be this: I have a Content Filtering rule that moves all incoming email with a Bayesian score between 65% and 85% probability (or ends in .us) to the account's quarantine folder. I can see in the SMTP logs that the rule does indeed trigger, and both emails to user@domain.com as well as the mailing list of sales@domain,com (of which that user is a member) are processed. in the Content filtering log, I also see that both emails of the same timestamp trigger the rule. However, while the triggered spam that was sent to user@domain.com does get moved into the Quarantine folder correctly, the spam addressed to sales@domain.com still gets delivered to the user's inbox.

I'm guessing what's happening here is either that the delivery mechanism of the mailing list is triggering AFTER content filtering is processed, and/or that the translation of mailing list address into individual addressees loses that Content Filtering action somewhere.

[Code Crafters]

You're right that mailing list delivery is done after Content Filtering.

We'll have a look if there is a way for the Account Folder information to be transferred when this happens.

For now, you can use User Filtering to filter based on ".us" email addresses.