From: "Rich" 

This is a multi-part message in MIME format.

------=_NextPart_000_03C4_01C5D61C.39F8EB50
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

   End user applications are permissive about this because they have to =
work in the real world.  That isn't the case with your example though =
which is well defined by a 12 year old standard.

Rich

  "Geo"  wrote in message
news:4358bd69{at}w3.nls.net...
  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_03C4_01C5D61C.39F8EB50
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








   End user
applications are =
permissive=20
about this because they have to work in the real world.  That isn't = the=20
case with your example though which is well defined by a 12 year old=20
standard.
 
Rich
 

  "Geo" <georger{at}nls.net>">mailto:georger{at}nls.net">georger{at}nls.net>
wrote=20
  in message news:4358bd69{at}w3.nls.net...
  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=20
    to filter email doesn't support the now 12 year old standard used in =
your=20
    example.
     
       I do
understand your =
concern=20
    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=20
    unhappy when they can't read their email or view web pages.  =
You could=20
    try to find someone to blame for each example of permissiveness but =
it is=20
    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=20
      someone trying to secure a network by say not allowing certain =
attachment=20
      types or certain code snippets or whatever in email, having email =
programs=20
      and html renderers that are so lax in enforcing what is =
acceptable=20
      forms of these things makes it almost impossible to provide the =
security=20
      required.
       
      I can't tell you how many times =
the=20
      attachment filters in NTmail got revised because of all the =
malformed ways=20
      virus send attachments and the email client software happily =
presents the=20
      malformed attachment to the user. I must have reported at =
least 20=20
      bugs that they had to fix for attachment blocking (my homemade =
filters=20
      worked better than theirs for at least the first 18 months because =
I=20
      assumed that virus would break the rules while they assumed things =
would=20
      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=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=20
      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=20
      wrt 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=20
        be more efficient.
         
        Rich
         

------=_NextPart_000_03C4_01C5D61C.39F8EB50--

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