If you look at politicians you will surely see that saying: "you shouldn't ..." wih a straight face is not that hard at all. :-)
Do you have your trusted_networks, internal_networks and all_trusted set up correctly? With these three options you should be able to exclude messages sent from your IP address. BTW, you are sending bulk mail (same mail, many recipients) and bulk mail isn't necessarily spam of course. Ultimately you could even separate outgoing and incoming mail, by using multiple MTA's. Then you can use the outgoing MTA without SA, so it saves you some resources too. -Sietse -----Original Message----- From: Jon Ribbens [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 19, 2006 5:10 PM To: users@spamassassin.apache.org Subject: What to do about False Positives on messages I am sending? I work at a company with an automated on-line system. This system sends emails to people. Spam Assassin appears to be triggering very strongly, and incorrectly, on our messages. FWIW, no we are not spammers, in fact the emails I'm talking about aren't even a mailing list. They're emails generated in response to a (confirmed) registered user performing an action on the system (each email goes to a single recipient, not bulk). A couple of examples of the tests being triggered include: EXTRA_MPART_TYPE This one appears to be penalising people who comply with the RFCs. multipart/related *requires* the 'type' parameter that is being flagged as 'spammy'. TVD_FW_GRAPHIC_NAME_MID This one appears to be penalising people who put images in the email with sensible names. HTML_IMAGE_ONLY_12 HTML_SHORT_LINK_IMG_2 These two appear to be penalising people who send short messages. I have read the AvoidingFpsForSenders page, and I am already doing most of what it says. I'm not encouraged by the first point: "The rules catch spam. If your email isn't spam, you shouldn't be matching the rules." I don't see how you can claim this with a straight face, given the rule examples I've mentioned above. One of the later bits of advice, "If you're using HTML emails, include a text part" is precisely what is triggering your own "spam-detecting" EXTRA_MPART_TYPE rule! I could work around these problems - I could break the RFC rules to avoid EXTRA_MPART_TYPE, I could obfuscate the image filenames to avoid TVD_FW_GRAPHIC_NAME, I could pad the message with invisible junk to avoid HTML_IMAGE_ONLY etc. But that would be ridiculous - that's what spammers do! Am I supposed to disguise my non-spam messages as spam in order to prevent SpamAssassin calling them spam? Any advice would be gratefully received! On the plus side, I should point out that we have recently implemented SpamAssassin on our incoming email and it's cut down the spam on the 'catchall' mailbox from approximately 3,000 a day to more like 10, so it's being very helpful in that respect ;-) Cheers Jon
