Christoph Thiel | 4 Dec 15:52 2007

Moderation request to include complete to-be-moderated mail?

Hey folks,

I was wondering, if it's possible to have the moderation requestion for
moderated list include the complete to-be-moderated mail (+ attachments)?
MMJ mentioned a patch that would be floating around somewhere, but I
couldn't find anything yet :(

Best,
Christoph
--

-- 
Christoph Thiel
Ressort IT Infrastruktur 2007/08 | Rotaract Deutschland Komitee

T: +49 911 2373317
M: +49 160 3435634
E: christoph.thiel@...
W: www.rotaract.de/rdk
Tetzelgasse 19 | 90403 Nürnberg | Germany

Rotaract Club Nürnberg | www.rotaract.de/nuernberg

Christian Laursen | 4 Dec 17:03 2007
Picon

Re: Moderation request to include complete to-be-moderated mail?

Christoph Thiel <ct@...> writes:

> I was wondering, if it's possible to have the moderation requestion for
> moderated list include the complete to-be-moderated mail (+ attachments)?
> MMJ mentioned a patch that would be floating around somewhere, but I
> couldn't find anything yet :(

Having it included as a mime part has been on my wish list for a while
but I haven't had the time to code it yet.

--

-- 
Christian Laursen

Peter Volkov | 13 Dec 11:07 2007
Picon

MIME encodings when dealing with adding the footer

Hello, list.

There is a problem in the current version of mlmmj in handling footer
which in combination of gmail effectively makes impossible usage of this
feature. In short if you have mail mime encoded (which happens very
often this days) footer like this:

[footer]
-- 
gentoo-doc-ru@... mailing list
[/footer]

will be displayed in evolution as 

&#0;│ИМ╒▀╛z╨Н│ИМ╒┼+┌f╒√)Ю√+-

But the worst thing is that our Russian users reported that it
completely impossible to read such messages in gmail. See bug
bugs.gentoo.org/173159 for additional details. And quoting Robin Johnson
for the mentioned bug:

============================================================
The best fix would be, if the body has a non-plaintext type, add the
footer in another MIME block, rather than trying to add it to the
existing block.
============================================================

This is still the issue with net-mail/mlmmj-1.2.14, but I do not see any
flag in ChangeLog that this is fixed in 1.2.15. So the question is are
there any plans to fix this issue?
(Continue reading)

Morten K. Poulsen | 13 Dec 11:31 2007
Picon

Re: MIME encodings when dealing with adding the footer

On Thu, 2007-12-13 at 13:07 +0300, Peter Volkov wrote:
> There is a problem in the current version of mlmmj in handling footer
> which in combination of gmail effectively makes impossible usage of this
> feature. In short if you have mail mime encoded
...
> The best fix would be, if the body has a non-plaintext type, add the
> footer in another MIME block, rather than trying to add it to the
> existing block.
...
> are there any plans to fix this issue?

Short answer: no.

Long answer: MIME parsing has been a source of vulnerabilities in almost
every single piece of software which attempts to parse MIME encoded
messages. Mlmmj can - in any normal installation - be triggered
remotely. It's a trade-off. I have made the decision to leave out MIME
parsing. I do not plan to add it, nor do I plan to accept patches which
add it.

However, Sascha Sommer has contributed a version of mlmmj-recieve [sic]
which can strip unwanted mime parts. It might be possible to extend it
to also add MIME encoded footers.

Morten

Peter Volkov | 13 Dec 12:18 2007
Picon

Re: MIME encodings when dealing with adding the footer

В Чтв, 13/12/2007 в 11:31 +0100, Morten K. Poulsen пишет:
> Long answer: MIME parsing has been a source of vulnerabilities in almost
> every single piece of software which attempts to parse MIME encoded
> messages. Mlmmj can - in any normal installation - be triggered
> remotely. It's a trade-off. I have made the decision to leave out MIME
> parsing. I do not plan to add it, nor do I plan to accept patches which
> add it.

Morten, but then footer feature should be dropped from mlmmj as it does
not work and breaks mails. Or at least big red notice should be added...
What do you think about this?

--

-- 
Peter.
Morten K. Poulsen | 13 Dec 12:49 2007
Picon

Re: MIME encodings when dealing with adding the footer


On Thu, 2007-12-13 at 14:18 +0300, Peter Volkov wrote:
> В Чтв, 13/12/2007 в 11:31 +0100, Morten K. Poulsen пишет:
> > Long answer: MIME parsing has been a source of vulnerabilities in almost
> > every single piece of software which attempts to parse MIME encoded
> > messages. Mlmmj can - in any normal installation - be triggered
> > remotely. It's a trade-off. I have made the decision to leave out MIME
> > parsing. I do not plan to add it, nor do I plan to accept patches which
> > add it.
> 
> Morten, but then footer feature should be dropped from mlmmj as it does
> not work and breaks mails. Or at least big red notice should be added...
> What do you think about this?

Yes, a word of warning in the readme might be a good idea.

Morten

Robin H. Johnson | 13 Dec 13:02 2007
Picon

Re: MIME encodings when dealing with adding the footer

On Thu, Dec 13, 2007 at 12:49:14PM +0100, Morten K. Poulsen wrote:
> On Thu, 2007-12-13 at 14:18 +0300, Peter Volkov wrote:
> > ?? ??????, 13/12/2007 ?? 11:31 +0100, Morten K. Poulsen ??????????:
> > > Long answer: MIME parsing has been a source of vulnerabilities in almost
> > > every single piece of software which attempts to parse MIME encoded
> > > messages. Mlmmj can - in any normal installation - be triggered
> > > remotely. It's a trade-off. I have made the decision to leave out MIME
> > > parsing. I do not plan to add it, nor do I plan to accept patches which
> > > add it.
> > Morten, but then footer feature should be dropped from mlmmj as it does
> > not work and breaks mails. Or at least big red notice should be added...
> > What do you think about this?
> Yes, a word of warning in the readme might be a good idea.
Could we have a limited feature then:
- If we think it is NOT safe to add the footer, then do not add it.

Cases where it is not safe:
1. The mail has more than one MIME part (not parse, just read the mail
headers).
2. The mail is not MIME, but is not safe encoding to muck with.

#2 was Peter's original case that he reported to me for the Gentoo lists,
a mail having the following headers:
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline

Should NOT get a plaintext footer added, because it would cause the
base64 to not decode.

(Continue reading)

Morten K. Poulsen | 13 Dec 14:00 2007
Picon

Re: MIME encodings when dealing with adding the footer

On Thu, 2007-12-13 at 04:02 -0800, Robin H. Johnson wrote:
...
> > > ?? ??????, 13/12/2007 ?? 11:31 +0100, Morten K. Poulsen ??????????:
...
> > > > I have made the decision to leave out MIME parsing. I do
> > > > not plan to add it, nor do I plan to accept patches which
> > > > add it.
...
> Could we have a limited feature then:
> - If we think it is NOT safe to add the footer, then do not add it.

Yes, that would be possible to implement. And it is a good idea.

> Cases where it is not safe:
> 1. The mail has more than one MIME part (not parse, just read the mail
> headers).

Technically it *is* safe to add text in the MIME epilogue.

> 2. The mail is not MIME, but is not safe encoding to muck with.
> 
> #2 was Peter's original case that he reported to me for the Gentoo lists,
> a mail having the following headers:
> Content-Transfer-Encoding: base64
> Content-Type: text/plain; charset="utf-8"
> Content-Disposition: inline
> 
> Should NOT get a plaintext footer added, because it would cause the
> base64 to not decode.

(Continue reading)

Jakob Hirsch | 13 Dec 14:09 2007
Picon

Re: MIME encodings when dealing with adding the footer

Hi,

> There is a problem in the current version of mlmmj in handling footer

This is a known issue, see this thread following
http://mlmmj.mmj.dk/archives/mlmmj/2005-07/0357.html

A while ago, I wrote a patch to fix this, but unfortunately it was
rejected and there was obviously no interest to discuss this (or even
write a warning that the footer feature is broken):
http://mlmmj.mmj.dk/archives/mlmmj/2006-09/0794.html

So, the official solution seems to be: Use some external wrapper
program. How, which? Your problem.

Oliver Gading | 20 Dec 15:48 2007
Picon

php-admin based on perl-admin


Hi

I have converted the perl-admin source to php.
It's based on the version from Franky Van Liederkerke which I found in
following posting:
http://mlmmj.mmj.dk/archives/mlmmj/2007-08/1122.html

Unfortunately I am to busy to write a README.
It works for me without problems.

For optimizing security I would need some help:
In my server environment I needed to set "SuexecUserGroup nobody nogroup"
(on Debian Etch postfix delivers as user nobody). I did not work it out how
to share the mlmmj list directory with a different group. Even when I setgid
the list directory (and the directories below) to the shared group.
Everytime (while subscribing/unsubscribing etc.) mlmmj tries to use files
which it is not the owner of, mlmmj writes a permission problem to the mail
log.

Oliver

--

-- 
Ich verwende die kostenlose Version von SPAMfighter fur private Anwender,
die bei mir bis jetzt 6213 Spammails entfernt hat.
Bezahlende Anwender haben diesen Hinweis nicht in ihren E-Mails.
Laden Sie SPAMfighter kostenlos herunter: http://www.spamfighter.com/lde
Attachment (php-admin-2007-12-20.tgz): application/octet-stream, 17 KiB

Gmane