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....