>> The mere presence of an unsubscribe link does not indicate legitimacy. And >> the sender's definition of "opt-in" may not align with how most people would >> define it. >> >> The company is probably real, ISTR using Acton back when I was monking at >> $DAYJOB--, but that doesn't mean the *contact* is legit.
>Yes, this I understand. I should have qualified my question and asked >if it was a *legit* opt-in, and more generally, what part of this >message makes it unsolicited junk. I realize now it's the >techproductupdates.com domain that's taken advantage of the >actonsoftware bulk mailer. >> The only way I'd consider it legit is if someone reported that they had, at >> some time, subscribed to that newsletter. >Ah, true. Not true. There are legit senders out there that can be trusted to properly handle unsubscribe and abuse reports. If you analyze your email (hint check for email that is consistently scoring low and they are in Internet whitelists) you will see patterns that can be turned into SHORTCIRCUIT ham rules. When I found this, it completely opened up my eyes on how to filter spam. I was constantly trying to create meta rules to combat spam which took a lot of time and was not getting better. If you train your Bayes on these types of emails then you are essentially poisoning your own database because there are legit emails with this same information. You have to define spam as unwanted/unsolicited email from untrustworthy senders that do not allow the end user to safely unsubscribe. Then the users can take back control of their Inbox by unsubscribing to things that they signed up for a year ago and now no longer want. If they flag it as spam to block it, then they just poisoned the Bayes database for everyone. >> If you're seeing a large portion of your userbase receiving them, and it's >> not a well-known website, then it is probably safe to consider it spam. What >> proportion of your user base would be technical enough to be interested in >> security audit software? >We've just had another vendor scan some of our mail, and they did a >much better job at bulk-mail detection. >> It looks to me like Acton made a bad marketing decision. >Yes, I think what I've realized today is that SA doesn't really have >any rules or processes for detecting bulk mail and giving the user the >option of tightening down on how it's managed. That's a problem. Not true. Whitelist (SHORTCIRCUIT) safe senders so SA only has to process a very small percentage of the email then use DCC, RAZOR, PYZOR, KAM, and other rules to detect bulk senders and add points. The legit senders (have SPF/DKIM setup and not on RBLs) should score very low so the DCC, RAZOR, PYZOR, KAM rules won't push them over the threshold to block. Setup RBLs properly at the MTA level to knock down 95 percent of the crap. Legit senders will use proper envelope-from so they will see the bounce and handle their own issue of poor reputation.
