Feature #87
closedpackage mlmmj from source
0%
Description
mlmmj should be built from source. The current version used still has a few bugs and glitches, like
- http://mlmmj.org/bugs/bug.php?id=48
- http://mlmmj.org/bugs/bug.php?id=43
- http://mlmmj.org/bugs/bug.php?id=52
- http://mlmmj.org/bugs/bug.php?id=25
that might be fixed in a minor release
Updated by Alexander Werner about 10 years ago
- Category set to Mailing lists
- Assignee set to Alexander Werner
Updated by Alexander Werner over 9 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.
Updated by Alexander Werner over 9 years ago
- Status changed from Feedback to New
Updated by Florian Effenberger over 9 years ago
- Priority changed from Normal to Low
Updated by Florian Effenberger about 9 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
Updated by Florian Effenberger almost 8 years 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.
Updated by Florian Effenberger almost 8 years 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
Updated by Florian Effenberger almost 8 years ago
- Target version changed from Pool to Qlater
Shifting to later due to the infra changes
Updated by Florian Effenberger over 7 years 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
Updated by Florian Effenberger about 7 years 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?
Updated by Guilhem Moulin about 7 years 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:<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".
Updated by Guilhem Moulin about 7 years 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
- Workaround for mlmmj not parsing correctly RFC 5322 headers values starting
- with CRLN, cf rdm#87 and <20170124174142.mvpuynk63vkfshcy@localhost.localdomain>
- 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.)
Updated by Florian Effenberger about 7 years 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 ;-)
Updated by Guilhem Moulin about 7 years 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
Updated by Florian Effenberger about 7 years 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.