From: "Rich" 

This is a multi-part message in MIME format.

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

   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_03A1_01C5D5B9.E0ACE360
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








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

  "Geo" <georger{at}nls.net>">mailto:georger{at}nls.net">georger{at}nls.net>
wrote=20
  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 these=20
  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 RFC=20
  was written spam wasn't much of a problem and neither were email virus =
but I=20
  was 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=20
  people writing the email clients anymore, the problem started with the =

  specifications 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=20
  it's all but impossible to filter for that code. It really is a =
security issue=20
  from a blocking point of view, but I see your point wrt the subject =
line, 74=20
  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 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=20
    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_03A1_01C5D5B9.E0ACE360--

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