From: "Geo" 

This is a multi-part message in MIME format.

------=_NextPart_000_00A4_01C5D605.76E69290
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Laxness in the client, no, laxness in the specification the client was =
written to meet, yes.

Malformed mime is not an end user issue, it's got nothing to do with = what
the user types in to the email.

Geo.
  "Rich"  wrote in message news:43586865{at}w3.nls.net...
     There is no laxness here in the client.  The problem you appear to =
be having is whatever you are using to filter email doesn't support the =
now 12 year old standard used in your example.

     I do understand your concern though but I don't think you are =
thinking it through.  End user applications tend to be permissive on = what
they accept because users get unhappy when they can't read their = email or
view web pages.  You could try to find someone to blame for = each example
of permissiveness but it is pointless.

  Rich

    "Geo"  wrote in message =
news:43584c0f$1{at}w3.nls.net...
    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_00A4_01C5D605.76E69290
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








Laxness in the client, no, laxness in =
the=20
specification the client was written to meet, yes.
 
Malformed mime is not an end user =
issue, it's got=20
nothing to do with what the user types in to the email.
 
Geo.

  "Rich" <{at}> wrote in message news:43586865{at}w3.nls.net...
     There
is no laxness here =
in the=20
  client.  The problem you appear to be having is whatever you are =
using to=20
  filter email doesn't support the now 12 year old standard used in your =

  example.
   
     I do
understand your =
concern though=20
  but I don't think you are thinking it through.  End user =
applications=20
  tend to be permissive on what they accept because users get unhappy =
when they=20
  can't read their email or view web pages.  You could try to find =
someone=20
  to blame for each example of permissiveness but it is =
pointless.
   
  Rich
   
  

    "Geo" <georger{at}nls.net>=20">mailto:georger{at}nls.net">georger{at}nls.net>=20
    wrote in message news:43584c0f$1{at}w3.nls.net...
    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=20
    these things makes it almost impossible to provide the security=20
    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=20
    better than theirs for at least the first 18 months because I =
assumed that=20
    virus would break the rules while they assumed things would be =
properly=20
    formed)
     
    Today's example was more of how =
spammers are=20
    exploiting the same laxness but it's still obviously something that =
was=20
    created with no forethought to security at all. Granted in 1996 when =
that=20
    RFC was written spam wasn't much of a problem and neither were email =
virus=20
    but I was already blocking email attachments just because it was =
obviously=20
    an unsafe idea so it wasn't like nobody saw this =
coming.
     
    I must admit though, I sure can't =
blame the=20
    people writing the email clients anymore, the problem started with =
the=20
    specifications not with the programmers. I'd never read that mime =
rfc=20
    before, wow..
     
    As for the security issue, if you =
allow=20
    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=20
    is a security issue from a blocking point of view, but I see your =
point wrt=20
    the subject line, 74 characters isn't a lot to work =
with.
     
    Geo.
    

      "Rich" <{at}> wrote in message news:43583435{at}w3.nls.net...
        
Email content is any =
encoding=20
      you want.  The example you give is valid even if silly.  =
It's=20
      not a security issue in any case.
       
        
BTW, email is not =
7-bit though=20
      it is 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_00A4_01C5D605.76E69290--

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