This is a multi-part message in MIME format.
--------------040506020107000402050902
Content-Type: text/plain; charset=windows-1250; format=flowed
Content-Transfer-Encoding: 7bit



Thomas Raef wrote:
>> Good morning everyone, i'm in charge of reducing SPAM at a customer
>> site. Already have SPAMASSASSIN, sa-update weeklyexecuted.
>>
>> I'd like to implement a "Bogus MX" for further filtering of SPAM. I
>> don't know if this is the correct name, by "Bogus MX" i mean setting up
>> a low priority MX record which points at a non-smtp server.
>>
>> I'd like to know some first-hand experience about two questions.
>>
>> 1. Has it caused any lost mail issue or client complaints?
>> I know every half decent mail server should try other MX. In real life,
>> have you often received complaints from valid senders?
>>
>> 2. Has it reduced significantly SPAM?
>> I'd like to know if it's worth the (little) trouble of setup and
>> verifying question #1.
>>
>> Thank you for your time.
>>

>
> [Tom Replied With:]
>
> Isn't that what Marc Perkel had been working on?
>
> I'm sorry if I messed up the name. But I think I'm correct. You may want to search the archives for information from Marc Perkel and see if any of that answers your questions.
>
> Marc, if that's not you, please flame me directly. (Sorry)
>
> Thomas J. Raef
> traef@ebasedsecurity.com
>
>


Yes - and you have my name right.

I have a front end spam filtering service currently filtering spam for
2500+ domains. I'm been using bogus MX records for about 2 years now. I
can tell you that I lose NO good email from using bogus high numbered
low priority MX records. You can either leave port 25 closed or you can
return a 421 error in case you want to count hits in your log file. And
you will see a significant reduction in spam bot spam.

Not only do you get rid of a huge amount of spam but you cut your server
load significantly. This is spam that no longer goes through spam
assassin. So it speeds up the processing of your good email.

The way it works is that spambot hit the low priority MX records,
nothing happens, and they move on. Spambots don't retry. So it's 100%
accurate for what it blocks. I have had no false positives at all using
this.

In fact I recommend using several low priority MX records to increase
the effect.

I have taken the idea several steps further. In addition to tracking
hits on low priority MX I also monitor if the connection issues a quit
to close. Spambots don't issue a quit. So if the spambot hits the bogus
MX, gets a 421 error, and doesn't issue a quit, and commits some other
sins they make my blacklist. I am currently tracking over a million
spambot IP addresses that have hit my servers in the last 4 days. As a
result of these tricks I have managed to block 100% of all spambot spam.
What little spam gets through is mostly yahoo, hotmail, and gmail spam.
And spamassassin takes care of most of that.

So - bottom line - do it - it works! It's simple - and no down side.


--------------040506020107000402050902
Content-Type: text/html; charset=windows-1250
Content-Transfer-Encoding: 7bit




http-equiv="Content-Type">






Thomas Raef wrote:
cite="mid:C4A2DDDA4F0A5C46A91AE25DD243546E02BCA3@ebs-2200.ebasedsecurity.local"
type="cite">

Good morning everyone, i'm in charge of reducing SPAM at a customer
site. Already have SPAMASSASSIN, sa-update weeklyexecuted.

I'd like to implement a "Bogus MX" for further filtering of SPAM. I
don't know if this is the correct name, by "Bogus MX" i mean setting up
a low priority MX record which points at a non-smtp server.

I'd like to know some first-hand experience about two questions.

1. Has it caused any lost mail issue or client complaints?
I know every half decent mail server should try other MX. In real life,
have you often received complaints from valid senders?

2. Has it reduced significantly SPAM?
I'd like to know if it's worth the (little) trouble of setup and
verifying question #1.

Thank you for your time.



[Tom Replied With:]

Isn't that what Marc Perkel had been working on?

I'm sorry if I messed up the name. But I think I'm correct. You may want to search the archives for information from Marc Perkel and see if any of that answers your questions.

Marc, if that's not you, please flame me directly. (Sorry)

Thomas J. Raef
traef@ebasedsecurity.com