Infrastructure

Feedback from Ben Schmidt, mlmmj author, on this:

Thanks for confirming that, Florian.

I tried Mlmmj 1.2.18.0 compiled from source on a Debian VM and was still
unable to reproduce the issue using the mails from Kendy.

If you're able to get a test list up and running using Mlmmj compiled
from source, that would definitely open up some possibilities for
additional investigation (e.g. we could patch Mlmmj to do some
additional logging and hopefully find out what's going on).

Just let me know when you/your team have been able to sort something out
and I'll be happy to continue investigating.

Contact is possible via Florian

Can we dry-run the prepackaged version from Debian 8 on the new bilbo2 and see if this bug is fixed upstream, so we can avoid packaging from source?

The sub/unsub bug is not fixed as of 1.2.18.1 (and checking find_email_adr.c, I doubt it's fixed as of 1.2.19.0 either)

$ nc -C localhost 25
    S: 220 vm194.documentfoundation.org ESMTP Postfix
    C: EHLO x.y
    S: 250-vm194.documentfoundation.org
    S: 250-PIPELINING
    S: 250-SIZE 41943040
    S: 250-ETRN
    S: 250-STARTTLS
    S: 250-ENHANCEDSTATUSCODES
    S: 250 8BITMIME
    C: MAIL FROM:<noreply@example.com>
    S: 250 2.1.0 Ok
    C: RCPT TO:<test+subscribe@mlmmj-mx2.documentfoundation.org>
    S: 250 2.1.5 Ok
    C: DATA
    S: 354 End data with <CR><LF>.<CR><LF>
    C: Date: Thu, 20 Apr 2017 14:33:38 +0200
    C: Subject: subscribe
    C: Message-ID: <4Mszed5mqZFk5pDFSQGH6nAjC_uG-pD5@localhost.localdomain>
    C: From: <noreply@example.com>
    C: To:
     x
     <test+subscribe@documentfoundation.org>
    C:
    C: .
    C: 250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 021EA13F640

confuses mlmmj into thinking the mail is to be posted to the list. In comparison, avoiding starting the To: header value with <CR><LF> yields a subscription.

Date: Thu, 20 Apr 2017 14:40:50 +0200
    Subject: subscribe
    Message-ID: <ky2JttMwIAg3Zu4c5e3IRTH1UZSoIxik@localhost.localdomain>
    From: <noreply@example.com>
    To: x
     <test+subscribe@documentfoundation.org>

Problem is really with the <CR><LF> immediately after the colon. "To:<SP><CR><LF>…" is fine.

So a quick and dirty fix would be to use postfix's header_checks option with a regex/pcre table to massage the RFC 5322 headers "s/To:\r\n/To: \r\n/x".

So a quick and dirty fix would be to use postfix's header_checks option with a regex/pcre table to massage the RFC 5322 headers "s/To:\r\n/To: \r\n/x".

And that works

$ cat /etc/postfix/master.cf
    […]
    cleanup   unix  n       -       n       -       0       cleanup
    cleanup2  unix  n       -       n       -       0       cleanup
        -o header_checks=pcre:$config_directory/mlmmj-fix.pcre
    […]
    127.0.0.1:10025 inet    n   -   n   -   -   smtpd
        […]
        -o cleanup_service_name=cleanup2
    […]

1. Workaround for mlmmj not parsing correctly RFC 5322 headers values starting
2. with CRLN, cf rdm#87 and <20170124174142.mvpuynk63vkfshcy@localhost.localdomain>
3. on the tdf-admin list

/^(From|To|Cc):\r?\n(.*)/ REPLACE $1: $2

(Header rewrite should be applied after DKIM signature verification, but before handing the RFC 5322 mail over to mlmmj.)

Can we try with a couple of mail clients of things work?
Because if so, we could deploy your workaround on vm194

Alternatively, if you have the skills, an upstream patch is of course
also always welcome ;-)

Florian Effenberger wrote:

Can we try with a couple of mail clients of things work?
Because if so, we could deploy your workaround on vm194

I already deployed the workaround to vm194 last week :-P (And mlmmj was
migrated last night.) It should solve the problem with outlook at least
(I know how they wrap the headers as I debugged that last January), and
wrapping headers doesn't hurt as long as it's done after DKIM verification.

Alternatively, if you have the skills, an upstream patch is of course
also always welcome ;-)

Looking at upstream's src/find_email_adr.c I don't understand where the problem is, so
I'll leave the fix to them :-P