Tony,
We got around this problem by calling spamassassin again during local
delivery. As far as I know this is the only way to do this. The filtering
must be applied during a process that identifies the intended recipient.
Messages that are processed by the default user have these options applied
from the default users .spamassassin/user_prefs file.
all_spam_to address@hidden
clear_headers
remove_header all Status
add_header all Status _YESNO_, user=default score=_SCORE_ required=_REQD_ on
_HOSTNAME_ tests=_TESTS_ autolearn=_AUTOLEARN_ version=_VERSION_
This changes the header from "X-Spam-Status: Yes, score=-121.8, etc, etc."
to "X-Spam-Status: Yes, user=default score=-121.8, etc, etc.".
Once this change takes place local delivery is done via procmail.
We have a global procmail rule that says,
##########################################################################
#Drop Priveleges and run as user.
DROPPRIVS=yes
# If message is less than 512K process this rule.
# If message matches default header reprocess by calling spamc.
:0
* < 512000
* ^X-Spam-Status: (Yes|No), user=root
{
# Run Spamassassin on message.
:0fw
| /usr/local/bin/spamc -t 150 -H -d
spam1.domain.com,spam2.domain.com,spam3.domain.com
}
##########################################################################
This has the effect of running spamassassin on each message twice only when
the message has multiple recipients (read processed as the default user).
Depending on your local delivery agent this might work for you.
Hope this helps.
Ted Hatfield
On Tue, 18 May 2010, Tony Shadwick wrote:
I'm going to state upfront that this is not a failure of spamass-milter as
designed. It is more of a pressure upon me at work.
So I'm catching a whole lot of flack because person user whitelists do not
get applied to users with multiple recipients. I try to explain what the
problem is, but to be honest even as a mail administrator I didn't get the
problem until years after it first presented itself. For those who still
don't understand, if you telnet on port 25 to a mail server, a typical
transaction will look something like this:
EHLO
MAIL FROM: <>
RCPT TO: <>
DATA
HEADER: blah
HEADER: blah
Subject: blah
body
.
The thing to keep in mind is that what you see in the To: Cc:, and Bcc:
fields are actually headers *after* the DATA command is sent. You could
fill those with bogus info or nothing at all. The issue is when you get
this:
EHLO
MAIL FROM: <>
RCPT TO: <>
RCPT TO: <>
RCPT TO: <>
DATA
HEADER: blah
HEADER: blah
Subject: blah
body
.
That's how you get multiple people to receive the same message - the To:,
Cc:, and Bcc: fields, as I understand them, are functionally identical in
the sense that they're just headers - in order for them to actually *get*
the message, they need to be on an RCPT TO: <> stanza. The problem is, as
a milter you only get to filter the message once, not twice, not 3 times -
so you have to pick someone's ruleset to apply - and way back in like 2003
it was decided to have a default user, usually with lessened restrictions,
so that once we have more than one RCPT TO: <>, we use the default user
instead.
Fast forward to today. Somehow even though I have that default user with
more_spam_to set, people are *still* getting bounces. I the real solution
is that these people need to look their signatures over and stop making
themselves look like spam. I don't want to go to all_spam_to on that
default user, but I might wind up having to. The pressure being put upon
me is that those in charge want individual whitelists to apply even when
there are multiple RCPT TO: <>. That, as things stand today, is pretty
much imposible.
I've considered multiple times re-implementing spamass-milter in pure perl,
just for the sake of doing it, and in fact have my own custom milter I use
to apply various pre-queue restrictions of my own. I could probably
reimplment the majority of what's in there, but then it leaves me with the
same conundrum - how do I work this?
The only thing I can think of is this - and I'm presuming that
Sendmail::Pmilter uses a similar structure to the pure C miltering library,
if not, feel free to correct me:
So we have our set of milter callbacks, and for me it looks something like
this right now:
my $milter_callbacks = {
'helo' => \&helo_callback,
'envfrom' => \&envfrom_callback,
'envrcpt' => \&envrcpt_callback,
'header' => \&header_callback,
'eom' => \&eom_callback,
};
So each time we get an RCPT_TO, my envfrom_callback() gets executed. As of
right now, I do in fact in my own milter, counter how many times this
callback gets called along with the contents of the RCPT_TO. My first
thought was to somehow get to the eom_callback(), and instead of passing
SMFIS_CONTINUE, somehow accept the message so the sender doesn't get a
rejection right away, but don't queue it either. Instead, break the
message apart, and create a separate new message with identical structure,
including the To:, Cc:, and Bcc: headers, but with only one RCPT_TO each.
Then pass *that* message to spamd. The upshot is that if the message was
so spammy that it got bounced by all recipients DESPITE the individual
whitelists being applied, the sender would get not just one bounce, but one
per individual recipient.
Of course, I'm pretty sure that this is impossible - I can only send
SMFIS_CONTINUE or SMFIS_REJECT - I can't have it both ways.
The other way I could think to do it would be to count recipients, and once
we have more than 1, don't pass it to spamd *at all*, but add a custom
header, say X-SAMILT-POSTPROCESS: Y, then pass the message with
SMFIS_CONTINUE. What would need to happen then (I think) is to have a
separate post-processing daemon running, that either using a feature of the
MTA or procmail, search for that custom header. When found, do what I
described above - filter using individual rules.
Now, before you respond with what I believe you inevitably will: "But Tony,
why bother? Then the users could run SpamAssassin normally!"
The answer is that in just about every environment I've ever worked in, the
users rarely have SpamAssassin on the endpoint mail server. They have it
somehow relayed through the box running SpamAssassin+Milter, and then it
gets passed on. As it is, I have a custom web application that users
control various aspects of their spam filtering, but the users themselves
are all over the country on various different windows domains/exchange
servers (BLEH!).
The custom header signals the VERY SAME SERVER, or perhaps a different
server, if you chose, that SpamAssassin has not yet been run on this
message. Then you have 2 choices - break it apart like I suggested before,
or if it does in fact get handed off to the endpoint server, the individual
users could have rules that basically say if(/X-SAMILT-POSTPROCESS:
Y/){pass_to_spamassassin()}.
I'm open to ideas. Regardless of whether I go back and do a pure-perl
reimplement of the whole milter or not, the problem for me is the same -
the users are crying out for a way to have their own rules apply 100% of
the time, and I still want to stop most everything pre-queue. Allowing
only multiple RCPT_TO messages to get filtered post-queue is an option I
suppose. There are still aspects of this I have not yet researched. For
example, if the message was send to address@hidden and
address@hidden, each on different relays, do we get both users on
RCPT_TO calls at BOTH relays? Or just the user that the MTA knows is at
that relay? I'm pretty sure it's just the user known to be at that relay,
but I've honestly never checked.
Feel free to chime in. Or have your eyes glaze over in disgust. Whichever.
:)
Tony Shadwick
_______________________________________________
Spamass-milt-list mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/spamass-milt-list