Hi

I apologise in advance for my phone wrapping the quoted parts of my reply
or whatever other formatting problems there may be.

On 14 Dec 2014 9:28 PM, "Steve Holme" <steve_holme_at_hotmail.com> wrote:
>
> On Fri, 12 Dec 2014, Patrick Monnerat wrote:
>
> > My version does:
...
> > - Proper handling of the initial dot.
>
> I'm not aware of that issue. Do you mean after the headers or if there
are no headers present? If when no headers should that initial dot be
stuffed as it isn't proceeded by a CRLF so cannot be interpreted as an end
of data line can it? The section on Data Transparency in the RFC would
indicate that it should - if so then I believe this can be achieved by
setting trailing_crlf to TRUE in smtp_do() and clearing it in
Curl_smtp_escape_eob() with an else at line 2371.
...
> > - An additional empty mail bug (currently transmitted as an empty line)
fixed.
>
> I wasn't aware of an issue here either. Technically I believe this can be
fixed by initially setting smtp->eob to 2 in smtp_do(). However, is it
standard for .CRLF to terminate the data command when there is no message
data? In my mind the RFC is a little ambiguous here especially when you
bear in mind that the standard response to the DATA command is typically
"354 Start mail input; end with <CRLF>.<CRLF>".

Well, there's a <CRLF> after the DATA command :)

As annecdotal evidence, Postfix just mentions "on a line by itself", while
Exim says something like what you refer to as standard/typical.

Postfix:

data
354 Enter message, ending with "." on a line by itself
.
250 OK id=1Y0jzU-0003H1-J7

Exim:

data
354 End data with <CR><LF>.<CR><LF>
.
250 2.0.0 Ok: queued as C557690CDC5

> > What do we do ?

I think that if we were implementing a new feature we should do the
conversion automatically and provide an option for someone to turn it off
if necessarily. Not sure about what to do, given that it's existing
functionality, but I think the chances of problems are quite low unless
someone is trying to talk to a broken server that requires <CR> characters
only or something like that.

Correct automatic conversion would do the right thing whether or not the
user does the conversion before handing the message to libcurl.

So I'm leaning towards fixing the conversion bugs, enabling conversion by
default (therefore making the command-line option redundant, but leaving it
for backwards compatibility) and providing another option to turn off the
conversion.

-- 
Michael Wood <esiotrot_at_gmail.com>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-12-16