On Thu, Dec 10, 2020 at 10:38:47PM +, Eric Wong wrote:
> Konstantin Ryabitsev wrote:
>
>
> > That said, should public-inbox consider this case when generating the
> > /raw and /t.mbox.gz messages? If the Archived-At and List-Archive
> > headers are listed in the DKIM-Signature header, skip
Konstantin Ryabitsev wrote:
> That said, should public-inbox consider this case when generating the
> /raw and /t.mbox.gz messages? If the Archived-At and List-Archive
> headers are listed in the DKIM-Signature header, skip inserting them
> into the generated message?
Fwiw, I've been wonderi
On Thu, 10 Dec 2020 at 16:43, Konstantin Ryabitsev
wrote:
> This is what causes DKIM verification to fail, and NOT the newline:
for the record, the DKIM RFC specifically deals with extra trailing newlines:
The "simple" body canonicalization algorithm ignores all empty lines
at the end of t
On Thu, Dec 10, 2020 at 08:55:40PM +, Eric Wong wrote:
> Konstantin Ryabitsev wrote:
> > Hello:
> >
> > While investigating why some of the messages retrieved via
> > lore.kernel.org were failing DKIM checks, I realized that
> > public-inbox-httpd appends an extra newline to message bodies.
Konstantin Ryabitsev wrote:
> Hello:
>
> While investigating why some of the messages retrieved via
> lore.kernel.org were failing DKIM checks, I realized that
> public-inbox-httpd appends an extra newline to message bodies. This
> newline isn't present in git backends, just in messages retrie
Hello:
While investigating why some of the messages retrieved via
lore.kernel.org were failing DKIM checks, I realized that
public-inbox-httpd appends an extra newline to message bodies. This
newline isn't present in git backends, just in messages retrieved via
(at least) public-inbox-httpd.
