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

Reply via email to