Bug in validHeaderFieldByte(): characters disallowed in http header field are allowed in email header field

[iredmail]

Dear @jhillyerd

There's a critical bug in validHeaderFieldByte() (and more places).
validHeaderFieldByte() checks valid characters for http header, not for email header field:
https://github.com/jhillyerd/enmime/blob/master/header.go#L257

According to RFC 5322 "Internet Message Format", section "2.2 Header fields":

   A field name MUST be composed of printable US-ASCII characters (i.e.,
   characters that have values between 33 and 126, inclusive), except
   colon.

Here's full list of printable US-ASCII characters:
https://www.ascii-code.com/characters/printable-characters

For example, characters /, *, [, ] are allowed in email header field, but it won't pass current validHeaderFieldByte(). This causes parse error like this:

[E] Malformed Header: Header name "X-AAID/CID: 0/238704" contains invalid character '/'

I believe there're more bugs caused by treating email header field as http header field.

[iredmail]

Reported to upstream too: golang/go#58862

[iredmail]

hi @jhillyerd Any thoughts?

[jhillyerd]

My thought is this is a bummer, I was planning on releasing enmime 1.0 next week. 😭

This isn't the first time something like this has happened, as you noted, Go is only focused on the HTTP use-case. It looks like the team put your issue into the backlog, so I think we will need to maintain an internal fork of the header parsing to insulate enmime from this and future changes. Hopefully we can maintain compatibility with textproto.MIMEHeader, if not, now is the time to break it.

I'll look into it this week, but for now I'd recommend sticking with Go 1.19

[iredmail]

Do you accept an internal "net/textproto" package with this issue fixed? I already worked out a patch and ready to send for your review.

[jhillyerd]

Sure, send a PR!

[iredmail]

hi @jhillyerd

PR is ready, please help review: #283

[iredmail]

There's some issue left: all methods of MIMEHeader (e.g. Add, Set, Get) still uses CanonicalMIMEHeaderKey (for http header) instead of CanonicalEmailMIMEHeaderKey (for email header). is it acceptable to introduce a new type for email header? e.g. type EmailMIMEHeader map[][]string.