go-message
go-message copied to clipboard
emersion
✉️ A streaming Go library for the Internet Message Format and mail messages
Hi! I've noticed that if Message-ID (or any other header using msg-id) has more than one "@" character than parsing via `parseMsgID()` from `header.go` fails with: `missing '>' in msg-id`...
Usually the hostname of the local machine tends to be not unique nor a FQDN. This brings multiple problems with it when sending messages using such Message-ID. First of all...
Previously, creating a message with encoding set to 7bit or 8bit would incorrectly insert extraneous line breaks even if the input data already contained some. It would also not convert...
Hello, with the current implementation, interface `PartHeader` is [implemented](https://github.com/emersion/go-message/blob/87d83aac2f695c202fbb6acc422e3f04b27a9f96/mail/reader.go#L104) as either `InlineHeader` or `AttachmentHeader` that both embed `message.Header`. ~~And although it's not documented by the package, the [wiki example](https://github.com/emersion/go-imap/wiki/Fetching-messages) implies...
When dealing with spam you find lots of malformed messages like some missing the final boundary in multipart messages. In cases like this the parser returns an encapsulated EOF error...
Quoted-printable lines must have a length limit according to the RFC but some software doesn't do that. This ends up error'ing out in the stdlib's parser. Tentiative fix in https://github.com/emersion/go-message/pull/120...
This package performs operations on buffered MIME messages. Reading a message with this package and writing it back as-is should produce the exact same bytes. Closes: https://github.com/emersion/go-message/issues/79 * * *...
go-message seems to suffer an issue which was previously discovered in perl `Mail::Header` module. https://rt.cpan.org/Public/Bug/Display.html?id=113464 The issue involves crafted messages that are usually used to transmit malware bypassing content scanners....
There exist messages in the wild (notably, some originating from mailbox.org's automated mailer e.g. due to payments) in which the `content-transfer-encoding` presents as an RFC2047 encoded-word. For instance, here is...
