On Fri, Oct 04, 2019 at 10:09:06AM +0200, Martijn van Duren wrote:
> On 10/4/19 10:03 AM, gil...@poolp.org wrote:
> > October 4, 2019 9:55 AM, "Martijn van Duren"
> > wrote:
> >>
> >> This is similar to the diff I send a few months ago, but still doesn't
> >> fix the case when someone sends a
On 10/4/19 10:03 AM, gil...@poolp.org wrote:
> October 4, 2019 9:55 AM, "Martijn van Duren"
> wrote:
>>
>> This is similar to the diff I send a few months ago, but still doesn't
>> fix the case when someone sends a standalone '\n' as line-ending.
>>
>
> Unsure I understand that, can you
October 4, 2019 9:55 AM, "Martijn van Duren"
wrote:
>
> This is similar to the diff I send a few months ago, but still doesn't
> fix the case when someone sends a standalone '\n' as line-ending.
>
Unsure I understand that, can you elaborate ?
> I'd prefer if we go with reverting (=my
On 10/4/19 9:36 AM, Gilles Chehade wrote:
> On Fri, Oct 04, 2019 at 08:43:28AM +0200, Martijn van Duren wrote:
annoying bumps will just be moved around. If we *really* want to fix
this we need to make it fit within the specifications:
[...]
This means stop
On Fri, Oct 04, 2019 at 08:43:28AM +0200, Martijn van Duren wrote:
> >> annoying bumps will just be moved around. If we *really* want to fix
> >> this we need to make it fit within the specifications:
> >>
> >> [...]
> >>
> >> This means stop opportunistic scanning for '\r' in iobuf!
> >>
> >
> >
On 10/4/19 8:23 AM, Gilles Chehade wrote:
> On Fri, Oct 04, 2019 at 07:35:39AM +0200, Martijn van Duren wrote:
>> On 10/3/19 9:05 PM, Eric Faurot wrote:
>>> On Thu, Sep 19, 2019 at 05:48:17PM +, gil...@poolp.org wrote:
>>>
> To me, the only real problem with '\r' is at the end of lines.
On Fri, Oct 04, 2019 at 07:35:39AM +0200, Martijn van Duren wrote:
> On 10/3/19 9:05 PM, Eric Faurot wrote:
> > On Thu, Sep 19, 2019 at 05:48:17PM +, gil...@poolp.org wrote:
> >
> >>> To me, the only real problem with '\r' is at the end of lines. It's
> >>> confusing
> >>> since you never
On 10/3/19 9:05 PM, Eric Faurot wrote:
> On Thu, Sep 19, 2019 at 05:48:17PM +, gil...@poolp.org wrote:
>
>>> To me, the only real problem with '\r' is at the end of lines. It's
>>> confusing
>>> since you never really know whether it's part of the content or the
>>> protocol.
>>>
>>> So I
On Thu, Sep 19, 2019 at 05:48:17PM +, gil...@poolp.org wrote:
> > To me, the only real problem with '\r' is at the end of lines. It's
> > confusing
> > since you never really know whether it's part of the content or the
> > protocol.
> >
> > So I suggest that we strip all '\r' found at the
On 9/19/19 5:46 PM, Gilles Chehade wrote:
> Hello,
>
> The RFC for SMTP states the following (section 2.3.8):
>
> In addition, the appearance of "bare" "CR" or "LF" characters in text
> (i.e., either without the other) has a long history of causing
> problems in mail implementations
September 19, 2019 7:26 PM, "Eric Faurot" wrote:
> On Thu, Sep 19, 2019 at 05:46:47PM +0200, Gilles Chehade wrote:
>
>> Hello,
>>
>> The RFC for SMTP states the following (section 2.3.8):
>>
>> In addition, the appearance of "bare" "CR" or "LF" characters in text
>> (i.e., either without the
On Thu, Sep 19, 2019 at 05:46:47PM +0200, Gilles Chehade wrote:
> Hello,
>
> The RFC for SMTP states the following (section 2.3.8):
>
> In addition, the appearance of "bare" "CR" or "LF" characters in text
> (i.e., either without the other) has a long history of causing
> problems in
Hello,
The RFC for SMTP states the following (section 2.3.8):
In addition, the appearance of "bare" "CR" or "LF" characters in text
(i.e., either without the other) has a long history of causing
problems in mail implementations and applications that use the mail
system as a tool.
13 matches
Mail list logo
