LISTSERV/VM 1.8e

I have a list that's configured to reject all attachments: * Attachments=
No

This works for most mail clients. But I'm finding that attachments sent by
Lotus Notes are not rejected. Has anyone else had this problem? I'm
wondering if the message as sent by Notes is malformed.

My (quite possibly incorrect) interpretation of RFC 2046 says that there
should be a CRLF preceding any boundary delimiter line and that the CRLF
is part of the delimiter. Further, the boundary delimiter line should end
with a CRLF. So there should be at least one blank line separating
boundary delimiters. Is a CRLF also required at the end of the preceding
part? It doesn't appear to be so but maybe I'm not reading the RFC right.

Below is a portion of a message sent by Notes. There is no CRLF after the
last <br> in the text/html part. Then there are two boundary delimiter
lines with one separating CRLF. These are the only significant differences
I can see between nearly identical messages generated by Lotus Notes and
Outlook Express. (OE uses a different character set and has spiffier
html). The message and attachment, as sent by Notes, was not rejected by
LISTSERV. The same message and attachment sent by Outlook Express was
correctly rejected.

Is this message malformed and is that why LISTSERV doesn't recognize the
attachment? Thanks for any insight you can offer.

________


Importance:
Content-Type: multipart/mixed; boundary="=_mixed 007D413588256DEA_="

--=_mixed 007D413588256DEA_=
Content-Type: multipart/alternative; boundary="=_alternative
007D413588256DEA_="


--=_alternative 007D413588256DEA_=
Content-Type: text/plain; charset="US-ASCII"

Attached file



--=_alternative 007D413588256DEA_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Attached file</font>
<br>
<br>
<br>
--=_alternative 007D413588256DEA_=--
--=_mixed 007D413588256DEA_=
Content-Type: image/jpeg; name="2003 HOOTERS Calendar.JPG"
Content-Disposition: attachment; filename="2003 HOOTERS Calendar.JPG"
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkz....