-
Notifications
You must be signed in to change notification settings - Fork 122
mail: add Header.MessageID and Header.MsgIDList #70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov Report
@@ Coverage Diff @@
## master #70 +/- ##
==========================================
- Coverage 62.54% 61.85% -0.69%
==========================================
Files 15 15
Lines 865 991 +126
==========================================
+ Hits 541 613 +72
- Misses 279 316 +37
- Partials 45 62 +17
Continue to review full report at Codecov.
|
|
TODO: |
|
For reference, relevant ABNF fragments from RFC 5322. |
|
Added a |
Mostly imported from the standard library's net/mail.addrParser [1], with parseNoFoldLiteral and parseMsgID added. [1]: https://tip.golang.org/src/net/mail/message.go
Those are defined in RFC 5322 section 3.6.4. We need to provide helpers because the fields may contain CFWS. We use headerParser introduced in the previous commit. Message identifiers are returned without the angle brackets, because the RFC says: > Semantically, the angle bracket characters are not part of the > msg-id; the msg-id is what is contained between the two angle bracket > characters. Also, it's easier for the caller to add back the angle brackets if needed rather than stripping them. MsgIDList isn't the best name ever. The RFC defines the message-id token for the Message-ID header field and the msg-id token for message identifiers, hence this name. I wonder if we can come up with something better. Maybe we should add Header.SetMessageID and Header.SetMsgIDList. Maybe we should remove our existing GenerateMessageID function, and add it to Header. [1]: https://tools.ietf.org/html/rfc5322#section-3.6.4 References: #49
foxcpp
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I would add some tests with malformed input, though, but not a big deal.
MsgIDs? MessageIDs? I guess MsgIDList is fine.
Would be a useful "convenience" function indeed. |
Those are defined in RFC 5322 section 3.6.4. We need to provide helpers
because the fields may contain CFWS.
We just use mail.ParseAddress and mail.ParseAddressList to avoidbuilding a msg-id parser. Maybe it's desirable to add a msg-id parser
upstream in net/mail.
Message identifiers are returned without the angle brackets, because the
RFC says:
Also, it's easier for the caller to add back the angle brackets if
needed rather than stripping them.
MsgIDList isn't the best name ever. The RFC defines the message-id token
for the Message-ID header field and the msg-id token for message
identifiers, hence this name. I wonder if we can come up with something
better.
Maybe we should add Header.SetMessageID and Header.SetMsgIDList. Maybe
we should remove our existing GenerateMessageID function, and add it to
Header.
References: #49