Skip to content
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

net/mail: ReadMessage fails on header-only messages #33823

Closed
pam4 opened this issue Aug 25, 2019 · 5 comments
Closed

net/mail: ReadMessage fails on header-only messages #33823

pam4 opened this issue Aug 25, 2019 · 5 comments
Labels
ExpertNeeded FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@pam4
Copy link

pam4 commented Aug 25, 2019

Sorry to open this again (see #15632, #24256).
Postfix just landed one such message on my Maildir mailbox, and my Go tools choked on it.
(I receive messages one per file, in raw format, with LF line endings from Postfix.)

The message has no body and only one LF at the end. The X-Mailer header field says MIME-tools 5.503 (Entity 5.501). It was sent by a person.

You can see it here (slightly altered).
Isn't it standard compliant?
According to RFC 5322 it seems that the body is optional and the empty line is required only if the body is present:

message = (fields / obs-fields)
          [CRLF body]

And such message is what mail.ReadMessage should be able to parse.

Postfix can send header-only messages, and it preserves the absence of the empty line.
To reproduce it, setup Postfix to deliver to a Maildir mailbox, then send yourself a header-only message using the sendmail command.
(If you use an mbox mailbox you get multiple messages per file, and an empty line is added as a separator, in addition to the "From_ line", but an mbox is not a message.)

I agree that header-only messages are rare and not very useful and this is a minor issue, but not completely worthless.

The simplest solution would be to filter out EOF in mail.ReadMessage here. But that would make it succeed even in case of incomplete last line (possibly truncated message).

@bcmills bcmills added ExpertNeeded NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Aug 26, 2019
@bcmills bcmills added this to the Unplanned milestone Aug 26, 2019
@bcmills
Copy link
Contributor

bcmills commented Aug 26, 2019

CC @bradfitz (on leave)

@emersion
Copy link

Can confirm header-only messages are valid messages. (For reference, here's a similar patch for go-message: https://lists.sr.ht/~emersion/public-inbox/patches/9396)

@pam4
Copy link
Author

pam4 commented Mar 14, 2020

Fixing textproto seems a little more complex than just turning io.EOF into nil here.
That would make it succeed even if the last line doesn't end in newline (which is not standard compliant).

(Unfortunately readContinuedLineSlice behaves exactly the same for either "x"EOF or "x\n"EOF.)

Anyway, io.EOF doesn't make much sense for mail.ReadMessage; it should be turned into io.ErrUnexpectedEOF (or nil if the last line is complete).

@pam4 pam4 changed the title net/mail: ReadMessage fails on header-only messages (round 3) net/mail: ReadMessage fails on header-only messages Mar 14, 2020
@kayrus
Copy link

kayrus commented Jul 14, 2022

I also experience this issue. See also some related issue in #53858

@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Nov 21, 2022
@gopherbot
Copy link

Change https://go.dev/cl/344269 mentions this issue: net/mail: fix EOF error while reading header-only message

@dmitshur dmitshur modified the milestones: Unplanned, Go1.21 Mar 24, 2023
@golang golang locked and limited conversation to collaborators Mar 23, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
ExpertNeeded FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants