-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
Comments
Before you send a patch, can you post here a play.golang.org snippet showing the problem? |
AFAICS, DotReader allow only |
I see that, but source code of net/textproto seems to treat LF too. For instance go/src/net/textproto/reader.go Lines 369 to 371 in 08ca401
|
Oh, I maybe found the reason of this behavior in RFC5321 SMTP.
(From Section 4.1.1.4 DATA) I think that net/textproto follows this spec, isn't it? |
Brad, he posted a program. |
What is this affecting? Are you having interop problems with a certain client or server? And which protocol? |
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.
|
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. |
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.
The text was updated successfully, but these errors were encountered: