go-smtp
go-smtp copied to clipboard
emersion
RFC 3030 (CHUNKING, BINARYMIME) support
CHUNKING (BDAT) support
Client support: Prefer over DATA if available (avoids the overhead of dot-encoding), require if BODY=BINARYMIME is used (as required by spec). Server support: Transparent support, io.Reader passed to Session.Data reads multiple chunks. Error returned by Data early consumes the current chunk and returns an error without consuming the whole message.
BINARYMIME support
Support BODY=BINARYMIME argument for MAIL command, no other actions required.
Specification: https://tools.ietf.org/html/rfc3030
Server part has been merged in https://github.com/emersion/go-smtp/pull/106. Keeping this issue opened for client support.
I'm test BINARYMIME and get error. What i do. Send mail with attachment (10mb size) like this
BDAT 1048576
...
some binary data
....
554 5.0.0 Error: transaction failed, blame it on the weather: smtp: too longer line in input stream
I checked source and found this error generated LimitReader when readLine is got limit. But when we used BDAT and BINARYMIME content not split by lines
From RFC3030
When the receiver-SMTP accepts a
MAIL command with the BINARYMIME body-value, it agrees to preserve
all bits in each octet passed using the BDAT command. Once a
receiver-SMTP supporting the BINARYMIME service extension accepts a
message containing binary material, the receiver-SMTP MUST deliver or
relay the message in such a way as to preserve all bits in each
octet.
I can set bigger MaxLineLength but think this not really right solution
Oh well, this is a problem. Perhaps we could disable lineLimitReader while reading a BDAT chunk? Can you make a PR?
Oh well, this is a problem. Perhaps we could disable lineLimitReader while reading a BDAT chunk? Can you make a PR?
Yes. I investigate problem and send PR
What would be a good chunk size for BDAT? Should we only use BDAT when PIPELINING is also available (to avoid having to wait for the server ACK'ing each chunk)?