Several MIME implementations, apparently even including Nathaniel's, disobey
the MIME syntax. They fail to reliably quote strings with an embedded dot in
a parameter. Here is an example of the sort of thing that has appeared in
multiple occurances:
Content-Type: message/external-body;
access-type=anon-ftp;
site=etlport.etl.go.jp;
directory=pub/mime/charset;
name="mule.txt"
Once again, I want to argue that the inclusion of dot within tspecials is a
misfeature of MIME. It serves no useful purpose than I can see, and it is not
being properly implemented even by the author of MIME!!!
This gives me the unpleasant choice of joining those who misimplement
tspecials in MIME, or of not being able to properly parse what a lot of sites
are generating. I am getting tired of catching flak because my implementation
cannot parse the buggy MIME that other implementations are generating. I
agree with the other implementors -- the rule is stupid, but I am trying to
have a correct implementation.
RFC-1341 itself violates this rule. On pages 35 and 41 of the PostScript
version. This is therefore a SHOW STOPPER since the specification itself is
broken.
I would like also to remove the foolish restriction on page 27 (and echoed in
the BNF) that requires that an encapsulation boundary begin with a CRLF
instead of merely at the beginning of a line. The sole difference is that the
beginning of the text is the beginning of a line as well as any subsequent
place after a CRLF.
This adds a needless blank line in multipart objects for no apparent reason.
SMTP handles this properly. MIME should too. This is, however, more of an
annoyance than a bug.