Subject: [Asrg] [RENAMED] Dangerous Attachments from Email Path Verification (has hcash benchmarks)

From: "Sauer, Damon" <[email-masked]>
Date: Mon, 15 Sep 2003 10:47:04 -0500

Our mail systems do not allow 36 directly executable attachment types and
it has not hindered our business one flea speck. We have not been infected
by a single email virus since Melissa that can be traced back through our
email gateways. 

 The magic words that were used was "directly executable", to me meaning
that there is no user action that has to take place for the code to be
executed. 

<rant>
I remember the good ol' days when I could say with my head held high, "No,
just opening an email message will not give you a virus- it is just text."
Thanks to the "Evil Empire", creator of non-RFC compliant, buggy, unsecured,
U-do-it-like-we-tell-U2- lookOut or express lookOut. I have to hang my head
low and nod, when some poor client has his preview pane on and gets infected
with the latest hourly exploit. Want to blame someone?
</rant>

 We therefore do not allow any directly executable code without it being
zipped, gzipped, tar's, stuffed, extension renamed, or any other action that
will "safe" it and not allow it to run unopposed.

 As long as a sender knows this, there is no issue with doing a little prep
work before sending. Not only that, it is less expensive to the mailing
systems.

Regards, 
Damon Sauer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Eric
S. Johansson
Sent: Monday, September 15, 2003 8:33 AM
To: Jonathan Morton
Cc: Brad Knowles; [email-masked]
Subject: Re: [Asrg] 6. Email Path Verification (hashcash benchmarks)

Jonathan Morton explained:

> I did the same with SpamAssassin when Sobig.F started hitting me with 
> hundreds per day (bounces and infections alike).  I manually set the 
> MICROSOFT_EXECUTABLE score to 10.0 (the default score is only 0.3) and 
> set up Procmail to dump messages above 8.0.  I'm pretty sure that dealt 
> with over 99% of the problem.
> 
> I personally think that nearly all ISPs, especially those with a large 
> proportion of newbies, should delete directly-executable attachments 
> without question.

while there is an autocratic part of me that agrees most heavily with what
you 
say, I also fear the hubris inherent in the situation.  This is what I think
in 
isolation place or spamtrap equivalent is what is called for.  That way the
user 
can determine whether or not they really want that piece of e-mail.  On the 
gripping hand however I have rarely received an executable by e-mail from
anyone 
except someone I have had long conversations with (i.e. OEM technical
support)

the nice thing about a spamtrap (at least the way I have
designed/implemented) 
is that I can get an audit trail of messages and who approved them.  So in
the 
case of a virus, you can know which employee is a FWM and started the
infection 
process.

---eric

*****
"The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material.  Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.  If you received
this in error, please contact the sender and delete the material from all
computers."

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 15 Sep 2003 13:44:40 -0400

First of all, please keep in mind the posting guidelines at 
(http://www.irtf.org/asrg/asrg_mailing_list_information.htm). I changed 
the subject since it belongs in the BCP area.

Second, take a look at the archive - we had a similar discussion a while 
back with Gordon Peterson about blocking HTML and attachements.

Third, what about HTML content that executes in the preview pane of a 
certain UNNAMED email client?

Yakov

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 15 Sep 2003 12:13:47 -0400

> by a single email virus since Melissa that can be traced back through our

  i.e. It's really not that hard to figure out.

> that there is no user action that has to take place for the code to be

  RFC 2183, Section 5 "Security Considerations"

   ...
   In general, the receiving MUA should not name or place the file
   such that it will get interpreted or executed without the user
   explicitly initiating the action.
   ...

  August, 1997.  They were warned.  They still did it wrong.

> will "safe" it and not allow it to run unopposed.

  All of these are hacks to get around broken MUA's, which have
explictly chosen to ignore the "Security Considerations" sections of
the relevant RFC's.

  I'm expecting that any new method of fighting problems related to
email will have similar horrid implementations, which will make the
problem worse.

  Alan DeKok.