At 11:31 AM -0800 1/18/08, Michael Heth wrote:
On Jan 16, 2008, at 7:33 PM, Bill Cole wrote:
At 1:38 PM -0600 1/16/08, billc imposed structure on a stream of
electrons, yielding:
<[EMAIL PROTECTED]> = spamtrap
No.
SIMS 'spamtrap' is not what the word 'spamtrap' has evolved to mean
since the last SIMS update. Routing an address to spamtrap means
that it is accepted at the RCPT stage but the message is rejected
entirely at the DATA stage, preventing delivery to any of the
addresses given in RCPT commands, even the ones that were
legitimate.
<[EMAIL PROTECTED]> = spamtrap
Well, I added the above to the top of my router table in my backup
server and my spam dropped to a trickle and I seem to be getting all
my email just fine at my primary server.
After I blew out my router and rebuilt it I had lost some spamtraps
and my spam went up 10 fold. Now it is lower than it was originally.
I do not have the
<[EMAIL PROTECTED]> = spamtrap
in my primary router table.
What I missed was the fact that you have a primary/backup MX setup.
That's increasingly rare, both because it makes spam control more
complex and because it is hard/expensive to set up a primary/backup
architecture that has much hope of ever providing any positive value,
much less being worth the hassle.
The implication of your experience is that there is something in your
router that was doing something with blacklisted mail other than
rejecting it.
I'm confused.
<[EMAIL PROTECTED]> matches any mail coming from IP addresses in the
local blacklist or in any of the DNSBL's you are using. The only
reason to have ANY router rule matching any @blacklisted pattern is
to exempt specific addresses or address patterns from those
blacklists.
If you have NO such rules, you simply never accept mail from the
blacklisted IP's, and it should never be seen by anything else of
yours, since you never even see the data.
What sort of setup do you run that causes mail rejected by SIMS to
go to some other machine of yours?
The primary server would reject the email and it would be sent to my
secondary which would receive it and then route it to the primary
which would accept it because it came from a client IP. When my
backup server was offline the spam was being routed to my listserver
which did throw it away but the drawback to that is that to the
spammers it looks like it might be an open relay and so it was get
hammered occasionally.
So for what it is worth, it seems to be working fine for my needs.
Bill Cole, do you have a preferred method to do what I enumerated above?
Since you seem to have needs and configuration I am not fully
understanding, I am not eager to suggest that you to do something
differently if you've reached what you deem to be success...
With that said: Generally speaking, the thing that most complicates
spam control in a primary/backup MX setup is that you need to
replicate the spam control tactics between the primary and the backup
to avoid spammers getting spam in via the secondary. Some spammers
have even learned to go to secondaries first to take advantage of the
fact that a lot of people using a secondary MX have weaker spam
filtering on the secondary or don't even control the spam filtering
on the secondary. I usually don't recommend a primary/backup MX model
at all, since the historical pattern of backup MX's being someone
else's mail system is really untenable in the modern world.
--
Bill Cole
[EMAIL PROTECTED]
#############################################################
This message is sent to you because you are subscribed to
the mailing list <SIMS@mail.stalker.com>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
