Mark Sapiro writes:

If your clients insist on posting HTML only messages and can't add an actual Approved: header to the message, then you can try patching Mailman/Handlers/Approve.py to recognize "[Approved: password]" in the Subject: header. The attached Approve.patch.txt file contains a patch that might do it.

I'll consider this as a feature for Mailman 2.2

I think this is unwise. The subject header is read by everybody, and you can't just delete it, so you have to munge it. More complexity. It's not so hard to add an Approved pseudo-header.

Brad Knowles wrote:

on 8/6/09 9:14 PM, Stephen J. Turnbull said:

...

...

I'll consider this as a feature for Mailman 2.2

I think this is unwise. The subject header is read by everybody, and you can't just delete it, so you have to munge it. More complexity. It's not so hard to add an Approved pseudo-header.

Some people really, really don't know what their software can do, and can't be taught how to make use of advanced features. Others may be able to learn how to use advanced features, but they are forced to use software that is locked down into a configuration that they can't change.

So, the question becomes this -- at what point do you stop bending over backwards to try to make seriously broken MUAs (or seriously un-savvy MUA users) be able to have some sort of minimal functionality, and at what point do you decide that it's too much work or opens too large of a security hole?

That's not a question I can answer.

But it is a good question, and I'm not sure I know the answer either.

I know from experience with users, that it isn't always easy or obvious how to get MS Outlook/Exchange to even send a multipart/alternative message instead of just text/html. In that case, an Approved: pseudo header won't be found because it is only looked for in the first text/plain part of the message.

Even when it is found, it's removal from other 'fancy' parts of a multipart/alternative part is on a 'best effort' basis and isn't guaranteed.

And then there's the issue of corporate mail environments that wrap messages in disclaimers possibly adding an initial text/plain part preceding the part with the pseudo header, thus hiding it from our search.

Thus, the idea of allowing "[Approved: password]" in the subject header and removing only that text from the subject has appeal because it doesn't depend on any characteristics of the message body.

The idea is to require the square brackets so a mere "approved:" in the subject (such as this message) doesn't trigger a match. We only match if we find "Approve:" or "Approved:" followed by a single "word" inside the square brackets and then we remove the brackets and their contents.

The patch which I attached to my earlier reply does this and also deals with RFC2047 encoded subjects and encodes the result as utf-8 if and only if it contains non-ascii.

I'm not completely comfortable with this approach, but neither am I completely comfortable with the pseudo header in the body of a multipart/alternative message. I always recommend a true Approved: header for this purpose, but I've googled more than once trying to find how to do this with Outlook, and I haven't found a straight forward way to do it.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 8/6/09 9:08 PM, "Mark Sapiro" <mark@msapiro.net> wrote:

Thus, the idea of allowing "[Approved: password]" in the subject header and removing only that text from the subject has appeal because it doesn't depend on any characteristics of the message body.

Won't work in an environment in which the message arrives with a DKIM signature including the Subject: header and when enforces valid DKIM headers inbound. (Or for a list going to "outside" subscribers, if any of them insist on DKIM validation.)

Of course, it's very unlikely that approved header as first line of first text part works in that environment either.

But Mailman already (by common configuration) munges Subject: headers.

When Office 2010 public beta arrives (or before if someone here has earlier access) it would be nice to check whether Outlook 2010 has learned a rational way to add custom headers.

--John

Khalil Abbas wrote:

well I'm sorry I didn't quite understand, what should I do with this file you sent me (approve.patch.txt) ?? where should I put it and what to name it and what to do with its permissions n stuff?

I probably shouldn't tell you because if you don't know how to apply a patch, you probably shouldn't do it, but

1. make a backup copy of Mailman/Handlers/Approve.py

2. give the command

patch /path/to/Mailman/Handlers/Approve.py < approve.patch.txt

3. restart Mailman

4. If any problems result, restore Mailman/Handlers/Approve.py from your backup and restart Mailman

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Mark Sapiro writes:

If your clients insist on posting HTML only messages and can't add an actual Approved: header to the message, then you can try patching Mailman/Handlers/Approve.py to recognize "[Approved: password]" in the Subject: header. The attached Approve.patch.txt file contains a patch that might do it.

I'll consider this as a feature for Mailman 2.2

I think this is unwise. The subject header is read by everybody, and you can't just delete it, so you have to munge it. More complexity. It's not so hard to add an Approved pseudo-header.

Brad Knowles wrote:

on 8/6/09 9:14 PM, Stephen J. Turnbull said:

...

...

I'll consider this as a feature for Mailman 2.2

I think this is unwise. The subject header is read by everybody, and you can't just delete it, so you have to munge it. More complexity. It's not so hard to add an Approved pseudo-header.

Some people really, really don't know what their software can do, and can't be taught how to make use of advanced features. Others may be able to learn how to use advanced features, but they are forced to use software that is locked down into a configuration that they can't change.

So, the question becomes this -- at what point do you stop bending over backwards to try to make seriously broken MUAs (or seriously un-savvy MUA users) be able to have some sort of minimal functionality, and at what point do you decide that it's too much work or opens too large of a security hole?

That's not a question I can answer.

But it is a good question, and I'm not sure I know the answer either.

I know from experience with users, that it isn't always easy or obvious how to get MS Outlook/Exchange to even send a multipart/alternative message instead of just text/html. In that case, an Approved: pseudo header won't be found because it is only looked for in the first text/plain part of the message.

Even when it is found, it's removal from other 'fancy' parts of a multipart/alternative part is on a 'best effort' basis and isn't guaranteed.

And then there's the issue of corporate mail environments that wrap messages in disclaimers possibly adding an initial text/plain part preceding the part with the pseudo header, thus hiding it from our search.

Thus, the idea of allowing "[Approved: password]" in the subject header and removing only that text from the subject has appeal because it doesn't depend on any characteristics of the message body.

The idea is to require the square brackets so a mere "approved:" in the subject (such as this message) doesn't trigger a match. We only match if we find "Approve:" or "Approved:" followed by a single "word" inside the square brackets and then we remove the brackets and their contents.

The patch which I attached to my earlier reply does this and also deals with RFC2047 encoded subjects and encodes the result as utf-8 if and only if it contains non-ascii.

I'm not completely comfortable with this approach, but neither am I completely comfortable with the pseudo header in the body of a multipart/alternative message. I always recommend a true Approved: header for this purpose, but I've googled more than once trying to find how to do this with Outlook, and I haven't found a straight forward way to do it.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 8/6/09 9:08 PM, "Mark Sapiro" <mark@msapiro.net> wrote:

Thus, the idea of allowing "[Approved: password]" in the subject header and removing only that text from the subject has appeal because it doesn't depend on any characteristics of the message body.

Won't work in an environment in which the message arrives with a DKIM signature including the Subject: header and when enforces valid DKIM headers inbound. (Or for a list going to "outside" subscribers, if any of them insist on DKIM validation.)

Of course, it's very unlikely that approved header as first line of first text part works in that environment either.

But Mailman already (by common configuration) munges Subject: headers.

When Office 2010 public beta arrives (or before if someone here has earlier access) it would be nice to check whether Outlook 2010 has learned a rational way to add custom headers.

--John

Khalil Abbas wrote:

well I'm sorry I didn't quite understand, what should I do with this file you sent me (approve.patch.txt) ?? where should I put it and what to name it and what to do with its permissions n stuff?

I probably shouldn't tell you because if you don't know how to apply a patch, you probably shouldn't do it, but

1. make a backup copy of Mailman/Handlers/Approve.py

2. give the command

patch /path/to/Mailman/Handlers/Approve.py < approve.patch.txt

3. restart Mailman

4. If any problems result, restore Mailman/Handlers/Approve.py from your backup and restart Mailman

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan