Project

General

Profile

Feature #87

package mlmmj from source

Added by Florian Effenberger almost 4 years ago. Updated 8 months ago.

Status:
Rejected
Priority:
Normal
Category:
Mailing lists
Target version:
Team - Qlater
Start date:
Due date:
% Done:

0%

Estimated time:
Tags:
URL:

Description

mlmmj should be built from source. The current version used still has a few bugs and glitches, like

that might be fixed in a minor release

History

#1 Updated by Florian Effenberger almost 4 years ago

  • Description updated (diff)

#2 Updated by Alexander Werner almost 4 years ago

  • Category set to Mailing lists
  • Assignee set to Alexander Werner

#3 Updated by Alexander Werner about 3 years ago

  • Status changed from New to Feedback

Will have to work into the opensuse build service so that good binary packages can be built for mlmmj as also the Debian 7 packages are still at 1.2.18.0 rather than .1.

#4 Updated by Alexander Werner about 3 years ago

  • Status changed from Feedback to New

#5 Updated by Florian Effenberger almost 3 years ago

  • Priority changed from Normal to Low

#6 Updated by Florian Effenberger over 2 years ago

  • Status changed from New to Rejected

mlmmj seems to work these days
Rejecting this ticket, as newer distributons that we will use have the updated package in the default repo anyways

#7 Updated by Florian Effenberger over 1 year ago

  • Status changed from Rejected to New
  • Priority changed from Low to Normal
  • Target version set to Pool

Re-opening this one, as it turns out PyMIME is not the culprit, and the subscription bug is still in place, e.g. with Google Mail or Evolution, when moderating mails or confirming the subscription.

#8 Updated by Florian Effenberger over 1 year ago

  • Description updated (diff)

#9 Updated by Florian Effenberger over 1 year ago

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

#10 Updated by Florian Effenberger over 1 year ago

  • Target version changed from Pool to Qlater

Shifting to later due to the infra changes

#11 Updated by Florian Effenberger about 1 year ago

  • Assignee changed from Alexander Werner to Guilhem Moulin

re-assigning to Guilhem in order to clean up Redmine queues
nothing concrete to do at the moment

#12 Updated by Florian Effenberger 8 months ago

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?

#13 Updated by Guilhem Moulin 8 months ago

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:<>
S: 250 2.1.0 Ok
C: RCPT TO:<>
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: <>
C: From: <>
C: To:
x
<>
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: &lt;&gt;
From: &lt;&gt;
To: x
&lt;&gt;

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".

#14 Updated by Guilhem Moulin 8 months ago

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
[…]
$ cat /etc/postfix/mlmmj-fix.pcre
  1. Workaround for mlmmj not parsing correctly RFC 5322 headers values starting
  2. with CRLN, cf rdm#87 and <>
  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.)

#15 Updated by Florian Effenberger 8 months ago

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 ;-)

#16 Updated by Guilhem Moulin 8 months ago

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

#17 Updated by Florian Effenberger 8 months ago

  • Status changed from New to Rejected

Rejecting this one now, as rebuilding mlmmj from source will likely not cure the issue; Guilhem tested the latest build. We might have a workaround in place that helps. If not, let's recreate a proper ticket.

Also available in: Atom PDF