wasm-demo/demo/ermis-f/imap-protocol/cur/1600094983.22548.mbox:2,S

46 lines
1.9 KiB
Plaintext

MBOX-Line: From gilles.lamiral at laposte.net Wed Mar 8 11:01:21 2017
To: imap-protocol@u.washington.edu
From: Gilles LAMIRAL <gilles.lamiral@laposte.net>
Date: Fri Jun 8 12:34:55 2018
Subject: [Imap-protocol] Gmail - OAUTH2 - failures since Feb 23
In-Reply-To: <CABa8R6tF-pTrGrs_oisvsxq8ewnwarA5fmaZGum2T2EO7AFgqw@mail.gmail.com>
References: <CAN7dqjB3uUeos7hEA0A5Kiad1VZT4JY=8y2t_ig_L+YzGXu5ug@mail.gmail.com>
<alpine.DEB.2.11.1702241225170.23062@grey.csi.cam.ac.uk>
<CABa8R6tF-pTrGrs_oisvsxq8ewnwarA5fmaZGum2T2EO7AFgqw@mail.gmail.com>
Message-ID: <5a39008c-b64b-5a0e-bffb-1163d76aa6cc@laposte.net>
Hi all,
Isn't it the last Apache patch that now disallow "broken" (not strict RFC7230 compliant)
http clients that still use \n instead of \r\n as end of lines?
Using only \n now generates an Apache (2.2) 400 HTTP error, it looks like some
sort of error code mapping with what described Kostya Vasilyev:
"using this token to log into Gmail would get "status code 400,
bad request" from Gmail's IMAP and SMTP servers."
I saw this happening in Debian last apache 2.2 patch:
https://tracker.debian.org/news/839792
* Security: CVE-2016-8743:
Enforce HTTP request grammar corresponding to RFC7230 for request lines
and request headers, to prevent response splitting and cache pollution by
malicious clients or downstream proxies.
* The stricter HTTP enforcement may cause compatibility problems with
non-conforming clients. Fine-tuning is possible with the new
HttpProtocolOptions directive.
It's not strictly imap related but it shows again that http is almost everywhere now.
Le 24/02/2017 ? 17:55, Brandon Long a ?crit :
> https://twitter.com/Google/status/834993667911737345
>
> We had some issues with account login yesterday for oauth, it should all be resolved now.
>
--
Au revoir,
Gilles Lamiral. France, Baulon (35580)
mob 06 19 22 03 54
tel 09 51 84 42 42