From: "Geo" 

This is a multi-part message in MIME format.

------=_NextPart_000_009B_01C5D5C1.B30598A0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I understand that point of view but for someone trying to secure a =
network by say not allowing certain attachment types or certain code =
snippets or whatever in email, having email programs and html renderers =
that are so lax in enforcing what is acceptable forms of these things =
makes it almost impossible to provide the security required.

I can't tell you how many times the attachment filters in NTmail got =
revised because of all the malformed ways virus send attachments and the =
email client software happily presents the malformed attachment to the =
user. I must have reported at least 20 bugs that they had to fix for =
attachment blocking (my homemade filters worked better than theirs for = at
least the first 18 months because I assumed that virus would break = the
rules while they assumed things would be properly formed)

Today's example was more of how spammers are exploiting the same laxness =
but it's still obviously something that was created with no forethought =
to security at all. Granted in 1996 when that RFC was written spam = wasn't
much of a problem and neither were email virus but I was already = blocking
email attachments just because it was obviously an unsafe idea = so it
wasn't like nobody saw this coming.

I must admit though, I sure can't blame the people writing the email =
clients anymore, the problem started with the specifications not with = the
programmers. I'd never read that mime rfc before, wow..

As for the security issue, if you allow malformed stuff to still work as =
if it were proper code you create a situation where it's all but =
impossible to filter for that code. It really is a security issue from a =
blocking point of view, but I see your point wrt the subject line, 74 =
characters isn't a lot to work with.

Geo.
  "Rich"  wrote in message news:43583435{at}w3.nls.net...
     Email content is any encoding you want.  The example you give is =
valid even if silly.  It's not a security issue in any case.

     BTW, email is not 7-bit though it is encouraged to be encoded as =
such because that provides better compatibility.  There is a standard = for
checking for 8-bit compatiblity.  See =
http://www.ietf.org/rfc/rfc1652.txt.  It's not necessary since anything =
can be encoded as 7-bit.  It can be more efficient.

  Rich

------=_NextPart_000_009B_01C5D5C1.B30598A0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








I understand that point of
view but for =
someone=20
trying to secure a network by say not allowing certain attachment types = or=20
certain code snippets or whatever in email, having email programs and = html=20
renderers that are so lax in enforcing what is acceptable forms of
= these=20
things makes it almost impossible to provide the security =
required.
 
I can't tell you how many times the =
attachment=20
filters in NTmail got revised because of all the malformed ways virus = send=20
attachments and the email client software happily presents the=20
malformed attachment to the user. I must have reported at least 20
= bugs=20
that they had to fix for attachment blocking (my homemade filters worked = better=20
than theirs for at least the first 18 months because I assumed that = virus would=20
break the rules while they assumed things would be properly =
formed)
 
Today's example was more of how =
spammers are=20
exploiting the same laxness but it's still obviously something that was = created=20
with no forethought to security at all. Granted in 1996 when that RFC = was=20
written spam wasn't much of a problem and neither were email virus but I = was=20
already blocking email attachments just because it was obviously an = unsafe=20
idea so it wasn't like nobody saw this coming.
 
I must admit though, I sure
can't blame =
the people=20
writing the email clients anymore, the problem started with the = specifications=20
not with the programmers. I'd never read that mime rfc before,=20
wow..
 
As for the security issue, if
you allow =
malformed=20
stuff to still work as if it were proper code you create a situation = where it's=20
all but impossible to filter for that code. It really is a security = issue from a=20
blocking point of view, but I see your point wrt the subject line, 74 = characters=20
isn't a lot to work with.
 
Geo.

  "Rich" <{at}> wrote in message news:43583435{at}w3.nls.net...
     Email
content is any =
encoding you=20
  want.  The example you give is valid even if silly.  It's =
not a=20
  security issue in any case.
   
     BTW,
email is not 7-bit =
though it is=20
  encouraged to be encoded as such because that provides better=20
  compatibility.  There is a standard for checking for 8-bit=20
  compatiblity.  See http://www.ietf.org/rfc/rfc1" target="new">http://www.ietf.org/rfc/rfc1=">http://www.ietf.org/rfc/rfc1652.txt">http://www.ietf.org/rfc/rfc1=
652.txt. =20
  It's not necessary since anything can be encoded as 7-bit.  It =
can be=20
  more efficient.
   
  Rich
   

------=_NextPart_000_009B_01C5D5C1.B30598A0--

--- BBBS/NT v4.01 Flag-5