Hi Keld,
----- Original Message -----
From: "Keld Jørn Simonsen" <keld(_at_)dkuug(_dot_)dk>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Cc: "Keld Jørn Simonsen" <keld(_at_)dkuug(_dot_)dk>;
<ietf-smtp(_at_)imc(_dot_)org>
Sent: Thursday, February 12, 2004 4:22 AM
Subject: Re: Best practices to avoid virus and spam
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.
True, and when done with a good learning performance algorythm, it works
really well. :-)
I think the idea for RBL site admins warrants some consideration. However,
the problem I see in regards to SORBIG generation like email viruses, the
potential exist to "deflect" blame somewhere else. i.e., some of users are
infected, should your ISP site be blacklisted?
Of course, this can happen with any RBL or even without a RBL report. A
site can detect that your site is sending an unsual amount of bounces with
spoofed addresses and automatically block you. So whether it is RBL or
system related, it is still something that can happen. But with the MyDOOM
type emails creating so many bounces, it can happen more greater when
paranoia is high.
Not speaking for Keith, but I think this is the "bad practice" aspect often
attributed to RBL systems. Its true, but its gotten better and the systems
that are more reputable do a better job of screening "IP reports."
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.
I'm interested in understanding your idea or suggestion better. So please
correct me if I am wrong. Your goal is to basically be able:
Purge "malicious mail"
from the distribution process regardless of who is being sent to, thus you
feel there is no need to do a recipient check at RCPT?
In other words, you want to be able to make some sense of the mail first
before you decide if the user (or sender) is legitimate or is allowed to
receive it and in this way, you believe that error reporting will be alot
cleaner and more specific to the real every day operations without that
crappy mess created by MyDoom, etc?
Ok, I see this and I agree with the premise that "SMTP" or the system
implementation should take a responsibility in helping to clean up malicious
distribution to its users.
But what I don't understand is why you can't do this now?
Are you saying that your smtp software does not have an option to turn off
RCPT validation?
I am thinking the effect on my customers who turn off "Local User
Validation." We still have ISPs that host or hub for slip systems. In this
case, they have no choice but to just accept the mail. These are also
autheticated or trusted sessions. But an infected user is also
authenticated so he has the power to relay mail as well.
In this mode of operation (local user validation turned off), if they don't
trap the malicious mail at the DATA state point mail filter process with
their 3rd party AVS software, then it contributes to the MYDOOM bounce
distribution logic.
So what is really important is that your reliance is now heavily weighted on
making sure the AVS is highly effective. This mode of operation still makes
you prone to new viruses that are yet to be detected or learned by AVS yet.
No doubt, from a scalability and performance standpoint, checking of Local
User Validation first before all the extra overhead checking is much better.
Solves many issues. I personally don't like this type of operation. It
helps spammers, not restricts them.
But I do see your point.
I guess what I learned here is maybe is it feasible to explore an provide an
option to delay the RCPT validation until the DATA stage is reached. We
are not in the Mail Interpretation business, but we provide examples of mail
filter scripts that can be used at DATA. Maybe an example script where it
checks for everything else before the user validation would be worth the
effort.
By the way, YAHOO validates RCPT at the DATA stage. I don't know if they do
AVS checking first, but they accept all RCPT and then delay the checking
until DATA is reached. However, it would naturally make sense to me that
they won't want to exert AVS checking until the basic SMTP related stuff
pass the test first. It is just too much overhead potential.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com