ietf-smtp
[Top] [All Lists]

Re: MyDoom, Sorbig - Actions taken?

2004-02-05 00:29:01


----- Original Message ----- 
From: <Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Sent: Thursday, February 05, 2004 1:42 AM
Subject: Re: MyDoom, Sorbig - Actions taken?

On Thu, 05 Feb 2004 01:29:37 EST, Hector Santos said:

Rather to being so condescending, why don't you explain how layering when
adhered by the MUA will solve the problem of abusive transportation of
viruses.   You are bent of this being an USER/MUA problem maybe that's
because you are currently focus on "User needs."   Well,  I disagree.
You
still have not address the question when MIME is not used for attachment
transportation via SMTP.

First off, the 'begin 644 foo.tar' went out of style a decade ago.

It has nothing to do whether you believe it went out of style or not.   That
isn't your option.  However, the OPTION is still available at the MUA level
in many applications and there are MANY legacy applications (which seem to
apply better with the mindset of people in IETF) that still suffer from
using the "out of styte" method.

Secondly, even when it was in use, there were MUAs that would
automatically
extract a uuencode - but none that I know of was ever silly enough to
extract-and-run.

This has nothing to do with Extract and Run.   Nothing.  That applies to ALL
malicious virus that reach users. Give a baby a lolly pop and without you
doing anything or teaching it, he will eventually lick it!   The problem is
giving to him in the first place.  How can you prevent all the lolly pops
being thrown in his face?

Yes, it is too bad that many designers of today have not taken ethical
engineering courses like I was required.   Yes, it too bad  there was alot
of pressure to have "automation" to be more important over security
concerns.   But this has NOTHING to do with how the SOBIG-generation virus
are exploiting everything that is weak about SMTP.

And you know what?  If the MUAs aren't supporting extract-and-run,
either MIME, or UUENCODE, or even encoded as a Lisp S-expr, then it
*doesn't matter* what the SMTP layer is doing.

Well, I guess this explains why we will continue to have problems with SMTP
being abused.

Go back and ponder.  Firestone. Speed limits.  That's what you're asking
for.

No am I not.  In your (naive) UNDERSTANDING of the problem, you are.  Not
me.

When you realize that tire problems have to be fixed *at the tire*,
then maybe you'll be able to contribute.

Valdis,  it was a ridiculous analogy in your last message as it still is
now.  I could easily blew this analogy away.

While one can question of the quality assurance of the tire design, one can
also question the quality assurance of the materials,  the manufacting,  the
testing and the risk assessment analysis used to suggest that "risk" is a
"user problem"  not a "vendor"  problem.     The fact is the WORLD did not
consider to lower speed limits because it would be a RIDICULOUS suggestion
conflictive with all other industries - car racing/chasing for one.   It is
so dumb, it is not even worth any more further thought.

What I am reading instead is both embarassing and insulting and frankly, I
have contributed to solving the problem and it was not putting the burden
entirely on the user.  What have you done with your SMTP product offerings
to customers?

If you would like to explain how your smtp product (if you have one) or your
employer/company has addressed the SORBIG generation viruses in terms on how
it handles bounces it generates further burdening downlinks,  I will be
interested to hear you share this.   If this is proprietary information,
then say so, I can perfectily understand this too.

I bet your employer SMTP servers are stripping attachments and/or delaying
deliver until analyzed automatically or manually by some IS support staff.
This is a process that begins SMTP, not at the MUA.

Oh what's the point.  The status quo remains.

Thanks for your comment.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com