net/textproto: DotReader can't determine end of data after empty line

[yosida95]

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]

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

[yosida95]

here http://play.golang.org/p/5K_Qu2zhJ-

[mattn]

AFAICS, DotReader allow only \r\n.

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

[yosida95]

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

	if c == '\n' {
	d.state = stateBeginLine
	}

, this block should not be needed to support only CRLF.

[yosida95]

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]

Brad, he posted a program.

[bradfitz]

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

[yosida95]

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]

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.