test: Fix malformed multipart message
authorAustin Clements <amdragon@MIT.EDU>
Tue, 6 Mar 2012 18:48:38 +0000 (18:48 +0000)
committerDavid Bremner <bremner@debian.org>
Sun, 18 Mar 2012 12:14:21 +0000 (09:14 -0300)
Previously, there was only one CRLF between the terminating boundary
of the embedded multipart/alternative and the boundary of the
containing multipart.  However, according the RFC 1341, 7.2.1:

  The boundary must be followed immediately either by another CRLF and
  the header fields for the next part, or by two CRLFs, in which case
  there are no header fields for the next part

and

  The CRLF preceding the encapsulation line is considered part of the
  boundary so that it is possible to have a part that does not end
  with a CRLF (line break).

Thus, there must be *two* CRLFs between these boundaries: one that
ends the terminating boundary and one that begins the enclosing
boundary.

While GMime accepted the message we had before, it could not produce
such a message.

test/multipart

index 0ac96d52870b9b463d9bd2ff750aa0894921b48a..e73cd8b8c48b638a38d5ef2363631c5326a8f543 100755 (executable)
@@ -46,6 +46,7 @@ Content-Disposition: inline
 EOF
 cat embedded_message >> ${MAIL_DIR}/multipart
 cat <<EOF >> ${MAIL_DIR}/multipart
+
 --=-=-=
 Content-Disposition: attachment; filename=attachment