ietf-smtp
[Top] [All Lists]

Re: Best practices to avoid virus and spam

2004-02-12 02:22:12

On Thu, Feb 12, 2004 at 03:51:28AM -0500, Hector Santos wrote:

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.

Yes, I was.

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 :-)

I am not sure if some of them would add this service. I think best chances are
that a specialized, or group of specialized RBL sites would come up with
this service.  Anyway another DNS lookup is IMHO not much to do, compared to
all the other checks done.

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?

Because of the improtance of the message sent out. One message is: this
is bogus mail, the other is: the user is not found. The latter is a
serious message for the original sender, the former is already known to the
offender.

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?

The first, via diverse filters, eg Milter or postfix' filters.

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?

Yes it adds overhead but I have CPU cycles enough of my cheap 2 year old
1 GHz noname intel box. Load 0,1 with 100.000 mails a day and about
6 Mbit/s average ftp and http traffic. Runs Mandrake 9.2 and postfix
with some filters, and then spamd. Pretty vanilla setup.

best regards
Keld