Explicit Email getting Through SA

[Spam Admin <sa...@harthosp.org>]

I've got a consistent problem with explcit email getting through SA to
two particular users. These emails are textual, have explicit
unobfuscated words, and are always sent to these two specific guys in
the same email. Despite obvious words in the text, they seem to score
zero or very low with SA.

They always arrive from different SMTP servers, always show different
From: and ReplyTo: address, have different subjects (some even with
explicits words). The only common thread I can find is that there are a
lot of extra unrelated words in the text ("reentering furniture
plaintiffs indictment sheaves" and other such garbage), plus the
'server' name is always one of the recipients' names; e.g., Received:
from klett (ppp-67-125-116-67.dialup.irvnca.pacbell.net [67.125.116.67])
where one of the recipients is klett@harthosp.org. In fact, now that I
write this, I realize the sending server seems to ALWAYS be "klett".

For reference, I am using SA on SuSe only as a filtering and relaying
server, there are no email accounts on that box. Further, I have no
exceptions for "spam lovers" or anyone else; all accounts get treated
the same. I'm stumped; any other ideas on where to look? I've increased
the scores for sexually-explicit material and it hasn't seemed to help.
I suspect I'm missing something simple here...

I can post the header and content info on request, but I'd prefer to
forward an email privately; some of this stuff is fairly graphic text.

Thanks,

Greg Amy
Hartford (CT) Hospital

Re: Explicit Email getting Through SA

[Duncan Hill <sa...@nacnud.force9.co.uk>]

On Tuesday 01 June 2004 15:03, Spam Admin might have typed:
> I've got a consistent problem with explcit email getting through SA to
> two particular users. These emails are textual, have explicit
> unobfuscated words, and are always sent to these two specific guys in
> the same email. Despite obvious words in the text, they seem to score
> zero or very low with SA.
>
> They always arrive from different SMTP servers, always show different
> From: and ReplyTo: address, have different subjects (some even with

What score does Bayes assign?

Have you told Bayes that these mails are spam?

What extra rulesets from rulesemporium.com are you using?

Are there any URLs in these mails, and are the URLs constant at the domain 
level?

Re: Explicit Email getting Through SA

[Bob Apthorpe <ap...@cynistar.net>]

On Tue, 1 Jun 2004, Spam Admin wrote:

> I've got a consistent problem with explcit email getting through SA to
> two particular users.
...
> The only common thread I can find is that there are a
> lot of extra unrelated words in the text ("reentering furniture
> plaintiffs indictment sheaves" and other such garbage), plus the
> 'server' name is always one of the recipients' names; e.g., Received:
> from klett (ppp-67-125-116-67.dialup.irvnca.pacbell.net [67.125.116.67])
> where one of the recipients is klett@harthosp.org.

Are you under any policy requirement to accept mail from
dynamically-assigned IP space? If not, I'd suggest greylisting/tempfailing
or rejecting traffic at the MTA level from known dynamic IP space.

According to openrbl.org, (ppp-67-125-116-67.dialup.irvnca.pacbell.net
[67.125.116.67]) is listed by dul.dnsbl.sorbs.net. Your policy may differ;
I see no need to accept direct SMTP traffic from dynamic IP space because
organizations that assign addresses dynamically always provide SMTP
services to their customers. If they want to send to your users, they can
use their organization's mail server to do so; that's what it's there for.

Another spam sign is a system that HELO's with something other than a
FQDN. It's a minor RFC violation and while there are a lot of broken
(Windows?) MTAs out there (FPs) the test hits far more spam than ham.
Depending on how much traffic you get and your available attention span,
you may want to tempfail on broken HELO and missing rDNS. Tempfailing
gives you some time to whitelist broken systems and politely ask their
admins to fix them; at worst, your users will see a delay in getting mail.

There are a very few badly-implemented MTAs out there that won't retry
after a 4xx error but this is a severe RFC violation; any problems losing
mail from these systems are the fault of the sending system, not the
recipient.

hth,

-- Bob