----- Original Message -----
From: "Keld Jørn Simonsen" <keld(_at_)dkuug(_dot_)dk>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Sent: Thursday, February 12, 2004 1:47 AM
Subject: Re: Best practices to avoid virus and spam
Maybe a need for some
RBL listing virus/spam infected machines, I don't know.
This is actually a good idea it if can be done with a response code.
Not
another RBL look up site :-)
I don't understand what you say here, the RBLs normally work as a lookup
in the DNS. Are you suggesting another way of distributing the list?
No.
DNS has an advntage of rapid dissemination and no specific maintenance
at each client site.
RBL lookups is done via a special zone at a specific DNS site. RBL zones
are not distributed, although they might be shared and in some cases
brought.
I presumed you were suggested for the RBL sites to include virus/spam
infected machines.
Cool, if one of them did it. What I pointing out I would hate to see a new
speciflc RBL site "specialized" only in listing virus infected sites.
I already do three RBL site lookups. I don't wish to add a forth. Thats
all :-)
Arent this what is considered good practice by many MTA administrators?
If it was, we would not such a spam problem :-)
I think checking the sender is a good thing upfront, and that receipient
validation should be done very *late* in the process. The latter is
actually my main point: check everything else first, including the
body for virus and spam, and then check the receipient. This to reduce
the error generation for invalid reciepient, or other problems such as
account closed or mailbox full.
Chicken and Egg? If you are going to reject anyone, why bother with the
overhead?
One thing what was not very clear in your message.
How you are checking for spams/virus? During the DATA state (receive data,
call mail filter process, examine and then return response code) or receive
the message and then do a post analysis?
So my recommendation is a prioritzation of mail validation. First check
the mail for if it is bogus: wrong sender addresses, no PTR (host
unknown), unknown sender, virus in body etc. And then check for the real
errors.
This is a very HIGH overhead mode of operation. To prove this, check our
SMTP statistic for December 2004 and January 2005.
http://www.winserver.com/sslinfo (Frame support browser required)
http://www.winserver.com/public/antispam (no frame support required)
On December 25, we move all our Validation logic TO AFTER the recipient was
checked. The result:
An average session time of 68 secs (December) was reduced to 22 secs
(January).
Now why would I want to go back?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com