Boundary quotes

[liaguh]

Maybe slowpoke but happened to notice the boundaries are not enclose in quotes any more.
RFC 1521 - 7.2.1. : "This is not always necessary, but never hurts."
Content-Type: multipart/mixed;
boundary="gc0p4Jq0M:2Yt08jU534c0p"

[Synchro]

Not slow at all - it was only just pushed and it's not in a tagged release yet. I did that because it was flagged as a warning in the IETF's msglint MIME checker and the way that boundaries are generated means we can be sure they never need quoting. Any value element in a header should be a token or a quoted-string (I think both are subsets of atom), and msglint flags anything not strictly necessary, for example if you mark a message body as 8-bit when it could be 7-bit. A related change is that filenames in content-disposition headers only get quoted if they need it.

RFC 2183 says:

A short (length <= 78 characters) parameter value containing only non-'tspecials' characters SHOULD be represented as a single 'token'. A short parameter value containing only ASCII characters, but including 'tspecials' characters, SHOULD be represented as 'quoted-string'. Parameter values longer than 78 characters, or which contain non-ASCII characters, MUST be encoded as specified in RFC 2184.

It would be better if we had a generic formatter for values in headers as it's a bit random at present.

[Synchro]

I've done some more experiments and looked at how other email creators treat quotes on boundary definitions and decided to restore them. The way I'm treating filenames in content-dispositions is consistent with other mailers, so that will stay.

[Synchro]

Fixed in c11c5af