In bug 635078, mozilla.support.other was configured so that everything is channelled through the mailing list and SpamAssassin. Anything making it past SpamAssassin would be auto-approved. So far, SpamAssassin is not catching all the spam, and it looks like spam score isn't entirely dependable. See bug 598060 comment 121
Dumitru, do you want me not to remove any posts in mozilla.support.other?
Dumitru? See comment 1.
I have no ideas what to do about this. SpamAssassin can presumably be tuned, but I don't really know how to tune it. If someone offers suggestions I'd be happy to implement.
I'm told we have the Debian SpamAssassin maintainer on staff here. :) /me bows in respect Can you help us out pretty please? :)
Assignee: justdave → nmeyerhans
(In reply to Chris Ilias [:cilias] from comment #0) > So far, SpamAssassin is not catching all the spam, and it looks like spam > score isn't entirely dependable. See bug 598060 comment 121 Spammers are always working on new obfuscation techniques in their efforts to bypass spamassassin and similar systems, so it's not at all surprising that some spam gets through. It's also not surprising to see some legit mail get higher spam scores, for various reasons. SA works primarily by checking various attributes of a message against a set of rules. Some of these rules might take message traits into account, while others might take metadata into account. The metadata includes things like originating network, blacklist membership and other stuff that's not necessarily under the control of the sender. If there's a specific pattern of messages (e.g. viagra spams, or whatever) coming through, it'd be helpful to see a couple of samples, including the complete message headers. It's entirely possible that we can tweak existing rules or define some custom ones to address a recurring problem.
They can all be found at <http://groups.google.com/group/mozilla.support.other>.
(In reply to Chris Ilias [:cilias] from comment #6) > They can all be found at > <http://groups.google.com/group/mozilla.support.other>. The messages that show up in google groups have already been passed of from email (SMTP) to netnews (NNTP on at least 3 different NNTP infrastructures), and many of the original SMTP headers have been lost. This makes things more difficult for spam fighting, since we need to look for interesting traits in the SMTP headers. I'll keep working on it, but the task is difficult enough as it is...
Has someone been changing https://lists.mozilla.org/admin/support-other/?VARHELP=privacy/sender/generic_nonmember_action to "Hold"? It's supposed to be set to "Accept".
At the beginning of December, I created a filter to discard messages that match the following headers: Content-Type: .*octet Content-Type: .*oda Content-Type: .*audio Content-Type: .*image Content-Type: .*alternative Content-Type: .*digest Content-Type: .*mixed Content-Type: .*related Content-Type: .*rich Content-Type: .*video The ones that made it through are still in the moderation que. I'll copy the message headers from those messages into a TXT attachment for this bug.
I was hoping to get the support newsgroups converted last year. We chose this solution under the assumption that we could rely on SpamAssassin to block the spam. At this point, it doesn't look like improving SpamAssassin is something anyone is able to help with. Should I just give up on this solution and re-open the discussion among the support newsgroups community about alternative solutions?
I thought of something else: In addition to the filter above, I set support-other to auto-accept nonmember messages, and put a filter to hold messages with the header "To: firstname.lastname@example.org". I think most spam is coming via email.
It's been three weeks, and the config in comment 13 seems to have worked. The only caveat is that I have to add list members to a whitelist, but that actually fixes another problem we have with non-members thinking the list address is a private support address (sending questions to the list without subscribing).
Assignee: nmeyerhans → bmo2010
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.