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/textproto: DotReader can't determine end of data after empty line #9781

Closed
yosida95 opened this issue Feb 5, 2015 · 9 comments
Closed

Comments

@yosida95
Copy link

yosida95 commented Feb 5, 2015

DotReader handles lines only ends with CRLF in document, but source code seems to handle ends with only LF too and I expected that behavior.

This issue is one that DotReader can't determine end of data after empty line ends with LF not CRLF. I confirmed that this issue still exists in current master ( 08ca401 ).

I am ready to send the patch to fix this issue.

@bradfitz
Copy link
Contributor

bradfitz commented Feb 5, 2015

Before you send a patch, can you post here a play.golang.org snippet showing the problem?

@yosida95
Copy link
Author

yosida95 commented Feb 5, 2015

@mattn
Copy link
Member

mattn commented Feb 5, 2015

AFAICS, DotReader allow only \r\n.

http://golang.org/pkg/net/textproto/#Reader.DotReader

@yosida95
Copy link
Author

yosida95 commented Feb 5, 2015

I see that, but source code of net/textproto seems to treat LF too. For instance

if c == '\n' {
d.state = stateBeginLine
}
, this block should not be needed to support only CRLF.

@yosida95
Copy link
Author

yosida95 commented Feb 5, 2015

Oh, I maybe found the reason of this behavior in RFC5321 SMTP.

The custom of accepting lines ending only in <LF>, as a concession to
non-conforming behavior on the part of some UNIX systems, has proven
to cause more interoperability problems than it solves, and SMTP
server systems MUST NOT do this, even in the name of improved
robustness.  In particular, the sequence "<LF>.<LF>" (bare line
feeds, without carriage returns) MUST NOT be treated as equivalent to
<CRLF>.<CRLF> as the end of mail data indication.

(From Section 4.1.1.4 DATA)

I think that net/textproto follows this spec, isn't it?

@rsc
Copy link
Contributor

rsc commented Apr 10, 2015

Brad, he posted a program.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@bradfitz
Copy link
Contributor

What is this affecting? Are you having interop problems with a certain client or server? And which protocol?

@yosida95
Copy link
Author

Thank you for taking your time.

When I create this issue, I wrote a SMTP (RFC5321) server implementation and try to use DotReader to handle DATA command defined in the RFC.

Please take this new snippet http://play.golang.org/p/fYqeKwUwkT , I indicated about how DotReader doesn't follow its document.

In additional, RFC5321 warns about customizing to accept lines ending only in <LF> in §4.1.1.4.

The custom of accepting lines ending only in , as a concession to
non-conforming behavior on the part of some UNIX systems, has proven
to cause more interoperability problems than it solves, and SMTP
server systems MUST NOT do this, even in the name of improved
robustness.

@bradfitz
Copy link
Contributor

Sorry for the delay here. Yes, it looks like we're following the strict rules from RFC 5321.

I'm going to close this without making any changes. The documentation seems accurate too.

@golang golang locked and limited conversation to collaborators Apr 24, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants