Dear friends,
On Tue, 16 Dec 2014, Steve Holme wrote:
The ideas I've had so far involve extending the existing --crlf
option but I hope to be able to post more on my ideas when
I have a little bit more time towards the end of the week.
I've not forgotten about this...
As the release of
On Mon, 15 Dec 2014, Patrick Monnerat wrote:
What do we do ?
As there are only two weeks until release I think we should:
* Hold off on automatic conversion until after the release of 7.40.0 -
this gives others time to contribute and assist in the debate about
whether this should or
Steve Holme wrote:
What do we do ?
As there are only two weeks until release I think we should:
* Hold off on automatic conversion until after the release of 7.40.0 -
this gives others time to contribute and assist in the debate about
whether this should or shouldn't be done
An
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_ho...@hotmail.com wrote:
On Fri, 12 Dec 2014, Patrick Monnerat wrote:
My version does:
...
- Proper handling of the
On Tue, 16 Dec 2014, Michael Wood wrote:
- An additional empty mail bug (currently transmitted as an empty line)
fixed.
I wasn't aware of an issue here either.
Well, there's a CRLF after the DATA command :)
I hadn't thought of it like that ;-)
What do we do ?
I think that if
On Fri, 12 Dec 2014, Patrick Monnerat wrote:
However, I think that the topic of whether non CRLF line ending
conversion should be performed automatically by curl or not for
certain protocols whilst related to the bug report is a different
conversation and one that I think should be
On Fri, 12 Dec 2014, Patrick Monnerat wrote:
I have worked on my side too for a much global solution, but I
have a clash now you've committed :-/
I'm guessing from what you've just said about the clash and from your previous
email that you've performed this in smtp.c. I think we should take a
Steve Holme wrote:
Please note there are two bugs listed in this bug report:
a) That curl doesn't handle LF to CRLF conversion
b) That dot stuffing doesn't work
Yes, I know: I've read all comments :-) I started for a fix for b) but tests
lead me to situations where a compliant server did
On Fri, 12 Dec 2014, Patrick Monnerat wrote:
A very quick comment as I'm quite busy this afternoon and just saw your
email:
I haven't been able to reproduce any other problems around b) now
that the fixes for a) are present, but the user has, and for that reason
I re-opened the bug report
Steve Holme wrote:
I've reproduced it: please find the mail data in attachment.
However I don't believe that was the user's issue - I understand he
was using my fix and specifying --crlf / CURLOPT_CRLF but was still
getting problems :(
Got it: the state is not saved properly between two data
On Fri, 12 Dec 2014, Patrick Monnerat wrote:
I've reproduced it: please find the mail data in attachment.
However I don't believe that was the user's issue - I understand he
was using my fix and specifying --crlf / CURLOPT_CRLF but was still
getting problems :(
Got it: the state is not
Steve Holme wrote:
As such, I have pushed commit f0ecdd04d3cd3c8814a296c3a9d2211086b7abd8
which hopefully addresses this.
I have worked on my side too for a much global solution, but I have a
clash now you've committed :-/
My version does:
- Proper mapping of LF, CR, CRLF to CRLF.
- Proper
I'm about to commit a fix for SF bug 1456, but first, I request your
opinion.
Forgive me Steve: you introduced CURLOPT_CRLF handling for the SMTP
protocol, but I think the standards make this conversion mandatory (RFC
5321, 2.3.8).
Thus the fix also reverts this handling and forces the LF
On Thu, 11 Dec 2014, Patrick Monnerat wrote:
I'm about to commit a fix for SF bug 1456, but first, I request your
opinion.
Please note there are two bugs listed in this bug report:
a) That curl doesn't handle LF to CRLF conversion
b) That dot stuffing doesn't work
The fixes I pushed for a)
On Thu, Dec 11, 2014 at 07:39:54PM +, Steve Holme wrote:
My only objection is that we are then taking away the ability to allow the
user to purposely send LF characters to the mail server for whatever reason
- they may have a non RFC compliant mail server that requires the line
ending to
15 matches
Mail list logo
