From: Joel Aelwyn <joel@lightbearer.com>
To: mlmmj@mlmmj.org
Subject: Re: [PATCH] chomp to remove '\r' as well
Date: Mon, 11 Sep 2006 13:25:11 +0000 [thread overview]
Message-ID: <200609110725.12703.joel@lightbearer.com> (raw)
In-Reply-To: <20060911123559.GK1815@mmj.dk>
[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]
On Mon September 11 2006 07:18, Mads Martin Joergensen Mads Martin
Joergensen <mmj@mmj.dk> wrote:
> * Joel Aelwyn <joel@lightbearer.com> [Sep 11. 2006 15:12]:
> > > Anyone object to this behaviour? Just heard on irc someone got
> > > bitten by this:
> > >
> > > --- chomp.c 20 Feb 2006 05:00:09 -0000 1.4
> > > +++ chomp.c 11 Sep 2006 12:34:28 -0000
> > > @@ -38,7 +38,7 @@
> > >
> > > i = strlen(str) - 1;
> > >
> > > - while(str[i] == '\n') {
> > > + while(str[i] == '\n' || str[i] == '\r') {
> > > str[i] = 0;
> > > i--;
> > > }
> >
> > As far as I recall, getting anything with \r\n as an EOL pretty
> > much grossly violates the SMTP RFCs, so I'll make two suggestions
> > about this:
> >
> > 1) Limit it *strictly* to a single \r\n, not any random combination
> > of the two characters. You'll drastically reduce your chances of
> > subtle and nasty misbehaviours being introduced when (not if) some
> > software comes along and relies on things obeying the RFCs.
> >
> > 2) Make it a configurable option. Call it 'broken-CRLF-support' or
> > somesuch, because it most assuredly is.
> >
> > Outlook is one of the primary offenders in this arena, for what
> > it's worth; DJB had -- probably has -- a rant up about it and why
> > qmail does/did not support a similar feature (it's been years since
> > I used qmail, but the combination of the two provided no end of
> > headaches back when I had to deal with them both at my workplace...
> > and, to a one, they were caused by Outlook blatantly violating the
> > protocol specifications.
>
> Ah, this has nothing to do with the smtp layer. SMTP always have to
> have \r\n, and that's handled in send.
>
> Problem is that when I for instance read a subscriber from a
> subscribers file with the old behaviour and match
>
> "mmj@mmj.dk" with "mmj@mmj.dk^M", they're different.
>
> Same thing when reading control files.
Ah, ick. But, in that case, being fancy is probably not warranted...
anyone who would get bitten by the broader behaviour is already doing
something they need to be smacked for. Comments withdrawn, or at least
deferred into the 'nice idea, maybe, but then again maybe not'
bucket. :)
--
Joel Aelwyn <joel@lightbearer.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
next prev parent reply other threads:[~2006-09-11 13:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-11 12:35 [PATCH] chomp to remove '\r' as well Mads Martin Joergensen
2006-09-11 13:11 ` Joel Aelwyn
2006-09-11 13:18 ` Mads Martin Joergensen
2006-09-11 13:25 ` Joel Aelwyn [this message]
2006-09-11 18:14 ` Morten K. Poulsen
2006-09-11 23:25 ` Mads Martin Joergensen
2006-09-12 15:50 ` Morten K. Poulsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200609110725.12703.joel@lightbearer.com \
--to=joel@lightbearer.com \
--cc=mlmmj@mlmmj.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.