better blocking at MTA level (off-topic)

[Koopmann, Jan-Peter]

On Saturday, May 26, 2007 1:07 PM Dhawal Doshy wrote: 

> maybe i didn't explain it well enough..
> 
> When your users connect on the outgoing SMTP server, their MUAs are
> talking to your servers so you have to relax your rules..
> 
> For incoming mails (your MX record), MTAs are talking to you (not
> MUAs) so you ought to expect someone sensible running them and you
> can afford to reject on certain criteria.
> 
> Based on the above assumption, you can for instance use
> zen.spamhaus.org on the incoming MTA (MX) without worrying, you do
> not want it on the outgoing MTA since your senders *will* mostly be
> sending from a DSL like connections.


Obviously I did not explain it well enough. I am aware of all you are
saying and it is missing the point completly, which is due to my faulty
mail. Sorry.

I am running several anti-virus/anti-spam installations for our
customers. They are all using Exchange/Outlook etc. behind those
installations. It is not their users I am worried about. They are all
using SSL VPN or similar to communicate with their server.

It is their customers that are using braindead mail installations. Their
customers (the ones sending them inquiries, purchase orders etc.) tend
to have malconfigured MTAs, send SMTP mail via Outlook from their
dynamic DSL connections, ships via satellites etc. Enforcing all the
common rules would mean that at least some of those inquiries/purchase
orders will not reach them. So they can either not enforce too strict a
ruleset or try to teach/educate their customers. And educating customers
is not a good thing. :-)

So I was talking about the incoming MTA/MX all along and ways to block
stuff at the MTA level without too strict a ruleset. We already do
things like tarpitting dynamic IPs, turn off pipelining, use several RBL
lists for tarpitting and spamhouse for blocking, connection delays etc.
Up to a week ago this combination held off most of the spam. We see a
massive increase of botnet-spam though that seems to get past this first
line of defence. 

Just wanted to make sure I am not missing something obvious before I
tell our customers to either live with it and catch it with SpamAssassin
(which currently works fair enough) or to enforce strict rules.

Thanks for all your suggestions. Besides the hint for the TrendMicro RBL
which I was not aware of I think we are already doing what can be done.


Kind regards

Jan-Peter Koopmann