Three years is a long time to wait.

I suggest configuring a SmarterMail inbound gateway to do your spam filtering.  The gateway will not know if the address is a user or a list, so your scoring formula will be applied uniformly.  Whatever rules are implemented successfully in the outbound gateway should be easily replicated in the inbound gateway.   

I expect any post to a mailing list to be a "personal" message, where the SMTP MAILFROM address should be the same as the Message's "From" address.    If this is applicable to your list posts, it can be enforced in Declude with a filter file like the one shown below.  This example assumes that you have no more than 50 lists.   The concept is to ensure that the weight given to FROMNOMATCH is greater than the number of mailing lists, so that the filter cannot fire unless FROMNOMATCH is true, but the message also must be to a mailing list for the filter to fire.

MINWEIGHTTTOAIL 51

TESTFAILED 50 CONTAINS FROMNOMATCH

ALLRECIPS 1 CONTAINS LIST1@DOMAIN1

ALLRECIPS 1 CONTAINS LIST2@DOMAIN2

ALLRECIPS 1 CONTAINS LIST3@DOMAIN3

This filter file defines an unacceptable post.  Declude separates test results from dispositioin actions, which is part of what makes it such as wonderful tool.   When you are happy that this filter file does what you want, you would add an action  rule for DELETE or BOUNCEONLYIFYOUMUST when the filter file tests TRUE.

It would also be desirable to require SPF PASS or equivalent on all posts to a list, but this more easily said than done well.   My implementation uses custom code rather than either SmarterMail nor Declude implementations of SPF checking.   If anyone wants the gory details of why I made this decision or how my solution works, feel free to send me a private message.

Hello Douglas,

As far as I know, how the SmarterMail in inbound gateway mode operates, it does the work of scoring the mail and then pass it along with the spam score to the backend SmarterMail server.

It's the backend server that decides then what to do with the mail, according to the score and the system/domain/user spam rules (delete, move to junk, tag, etc).

The issue is that when it is a mailing list target, no blocking action is applied on spammy incoming mails. It's processed and forwarded to the list subscribers.

So any mailing list (especiall those allowing anyone to post) is quickly becoming a source of SPAM.

To avoid this, a mailing list target address should be considered like a mailbox receiving a mail and take into account the spam score, then decide wether to forward the mail to the mailing list (if clean), generate a bounce or delete it.

external mail -> mailing list -> spam evaluation (good yeah!-> forward to subscribers

external mail -> mailing list -> spam evaluation (crap) -> bounce

or

external mail -> mailing list -> spam evaluation (crap) -> delete

This could be configurable per mailing list as we can do it per normail mailbox:

Looks to me(I can be wrong of course)  everything is already existing in the product to apply such a SPAM processing on mailing lists.

Also the lack of SPAM processing on the mailing list brings to front another huge problem: List subscribers being unsubscribed due to bounces.

When a SPAM is relayed by the mailing and forwarded to subscribers (external), the remote servers will probably bounce them right on SMTP session (after DATA) as they will be detected as SPAM by the remote end.

This then increases the bounce count for almost EVERY subscribers of the list and by default this setting is set to 2 (I think it's a value only configurable per domain and I didn't find a default value to set and propagate to existing domains)

So by default when a list relays spam that is rejected by most destination servers, after 2, a mailing list can be entirely wiped due to these bounces.

What is even more fun, is that when this happens, there is no way as far as I know, in the mailing list management panels, to know which subscribers has been unsubscribed due to bouces. They just disappear from the lists.

Here there should be a panel in the mailing list admin, where you can review the unsubscribed members along with the date it was removed and the reason (unsubscribed manually or bounces) and optimally in case of bounce, the ability to view the received bounce (but that's the cherry on the cake).

Also you could select some of the unsubscribed members in that list and press a button to re-subscribe them.

In the current state, the lack of SPAM handling and a view on who was removed and why, the mailing list feature is a pain to administrate.

I guess without that much effort it could be enhanced, at least on the SPAM handling side.

Of course the "Allow anyone to post" is worst situation for a mailing list for getting SPAMMED, but we also saw "Allow only subscribers to post" and "Allow only moderators to post" mailing list getting abused only with spoofed "From" address mails sent to the mailing list.

As a side information, we already have front filters (not based on SmarterMail), that scores the mails and populate an header that is then used to evaluate custom spam rules in SM, it works very well for mailboxes but is ignored for mailing lists.

We directly reject mails on the front filters, when they hit relatively high scores. But still for low to med scoring, we allow the mail and forward it to SmarterMail with the scoring so it's up to the end user to decide what to do with them (if they don't follow the defaults we set).

The mailing list admins should also be able to decide what to do with mails adressed to their mailing list depending on how they scored in the spam checks. Keeping in mind that letting too much spam going  through their list will see their members being kicked due to bounces.

We also use an outgoing gateway, where we added some logic like, is it an outgoing mail from SM mailing list, or a forward, or an alias that points to external recipients and evaluate if it looks like an outgoing spam and bounce/drop them silently depending on the scoring.

This to keep an high deliverability score (90-100 on senderscore, avoid getting our IPs on blacklist etc).

All this is tricky though :)

By the way, we attempted to prevent our customers from creating an "Allow anyone to post" mailing list. They can only create new mailing lists from our control panel (and we do the required API calls in background) and they can only chose allow Moderators to post / Allow subscribers to post. 

We also define the mailing list moderator/admin account for administrating the mailing list. Once the customer logs in with this account, he can then change the mailing list to "Allow anyone to post":

It would be really great if we can disallow system and/or domain wide, mailing list admins to turn on this as most of the mailing list + SPAM problems come from this.

Inbound gateways can run with or without "SmarterMail Gateway" mode enabled.   I have found the documentation to be unacceptably vague about the differences.   It appears that "SmarterMail Gateway" mode does log into the backend server, so you are probably right that the login allows it to know the difference between a list and a user.   

With SmarterMail Gateway mode disabled, which is my configuration, the gateway is just an MTA which knows very little about the remote machine.

I found the SmarterMail spam filtering to be too limiting, so I have not done much with it.   Instead, essentially all of my filtering is done by Declude.   

Processing Flow and Sender Notifications

As best I have been able to tell, SmarterMail filtering has three stages:

1) Initial screening during the SMTP session, including sender authentication.  Unwanted messages get rejected with an SMTP result code

2) Callouts to Declude, Spam Assassin, etc.

3) SmarterMail spam filtering rules.

If a message becomes unacceptable or undeliverable in phases 2 and 3, the SMTP session is already closed, so the only notification option is a non-delivery report (NDR).   My experience is that NDRs are ignored by most legitimate senders and are inappropriate for hostile senders, so I don't send them.   

Similarly, I don't do recipient verification.  I briefly tried enabling Recipient Verification, and it went badly because my configuration, it required using LDAP.   I discovered that LDAP did not detect all users and did not detect users consistently.  An important manager was being dropped from critical alarm notices, and she was not happy.   So it had to be turned off.  But I also decided it was inappropriate, because the volume of directory harvesting was much higher than the volume of legitimate but misaddressed mail.