feature request: DIR/mimereject

feature request: DIR/mimereject

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

I didn't see this feature listed on the mlmmj page -- apologies if it
already exists.

That said, one thing we *really* need is the DIR/mimereject feature of
ezmlm. (might be an ezmlm-idx specific feature, come to think of it) This
feature scans list messages prior to sending them and rejects messages with
pre-defined attachment types.  "application/octet-stream" is the one we
block on most of our lists as those attachments are generally
worms/viruses.

I'd *like* to have a global option that allowed me to say, "for any/all
lists on this machine, reject messages with the following MIME types".  IF
that's more difficult, then I'm content with at least being able to do it
on a list-by-list basis.  Another option would be some sort of /etc/skel
type functionality, but that's a separate feature request, so I'm going to
send that in a separate email.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: feature request: DIR/mimereject

[Mads Martin Joergensen]

* Kurt Lieber <klieber@gentoo.org> [Nov 04. 2004 18:05]:
> I didn't see this feature listed on the mlmmj page -- apologies if it
> already exists.
> 
> That said, one thing we *really* need is the DIR/mimereject feature of
> ezmlm. (might be an ezmlm-idx specific feature, come to think of it) This
> feature scans list messages prior to sending them and rejects messages with
> pre-defined attachment types.  "application/octet-stream" is the one we
> block on most of our lists as those attachments are generally
> worms/viruses.
> 
> I'd *like* to have a global option that allowed me to say, "for any/all
> lists on this machine, reject messages with the following MIME types".  IF
> that's more difficult, then I'm content with at least being able to do it
> on a list-by-list basis.  Another option would be some sort of /etc/skel
> type functionality, but that's a separate feature request, so I'm going to
> send that in a separate email.

How about using the functionality already there? Here's a snippet from
README.access (tar-ball and http://mlmmj.mmj.dk/files/README.access):

 A third example. Deny any mails with "discount", "weightloss", or
 "bonus" in the subject. Allow PGP signed and plain text mails. Anything
 else is denied:

 deny ^Subject:.*discount
 deny ^Subject:.*weightloss
 deny ^Subject:.*bonus
 allow ^Content-Type: multipart/signed
 allow ^Content-Type: text/plain

That should make it possible to do what you want no? And for the global
reject file, just make one access file in a central place and symlink it
everywhere.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: feature request: DIR/mimereject

[Mads Martin Joergensen]

* Kurt Lieber <klieber@gentoo.org> [Nov 04. 2004 18:05]:
> I didn't see this feature listed on the mlmmj page -- apologies if it
> already exists.

Sure, no problem. It's a bit hidden.

> That said, one thing we *really* need is the DIR/mimereject feature of
> ezmlm. (might be an ezmlm-idx specific feature, come to think of it) This
> feature scans list messages prior to sending them and rejects messages with
> pre-defined attachment types.  "application/octet-stream" is the one we
> block on most of our lists as those attachments are generally
> worms/viruses.

In DIR/control/access:

 deny Content-Type:.*application/octet-stream
 allow

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: feature request: DIR/mimereject

[Morten K. Poulsen]

On Thu, Nov 04, 2004 at 07:53:36PM +0100, Mads Martin Joergensen wrote:
> > That said, one thing we *really* need is the DIR/mimereject feature of
> > ezmlm. (might be an ezmlm-idx specific feature, come to think of it) This
> > feature scans list messages prior to sending them and rejects messages with
> > pre-defined attachment types.  "application/octet-stream" is the one we
> > block on most of our lists as those attachments are generally
> > worms/viruses.
> 
> In DIR/control/access:
> 
>  deny Content-Type:.*application/octet-stream
>  allow

I don't think that's what Kurt want. Our access check only checks the mail's
headers. He probably wants to check the headers of each MIME part in the mail
body. That would require parsing the body, and checking the headers of each
part - not an easy task. And definitely not an easy thing to do correctly.

Morten

-- 
Morten K. Poulsen <morten@afdelingp.dk>
http://www.afdelingp.dk/

Re: feature request: DIR/mimereject

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 889 bytes --]

On Fri, Nov 05, 2004 at 10:17:04AM +0100 or thereabouts, Morten K. Poulsen wrote:
> I don't think that's what Kurt want. Our access check only checks the mail's
> headers. He probably wants to check the headers of each MIME part in the mail
> body. That would require parsing the body, and checking the headers of each
> part - not an easy task. And definitely not an easy thing to do correctly.

Correct.  This request comes from the all the worms that exist out there
which spoof both the From: and the To: address.  We've had a number of
occasions where a virus got through to the list because it appeared to come
from a valid subscriber.

An argument can certainly be made that the MTA should handle this instead
of the ML manager and, if you make that argument, I'll accept it. :)
However, it is a feature of ezmlm(-idx) so I figured I'd at least ask for
it.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: feature request: DIR/mimereject

[Morten K. Poulsen]

On Fri, Nov 05, 2004 at 11:35:49AM +0000, Kurt Lieber wrote:
> > He probably wants to check the headers of each MIME part in the mail body.
> > That would require parsing the body, and checking the headers of each part
> > - not an easy task. And definitely not an easy thing to do correctly.
> 
> Correct.
[snip]
> An argument can certainly be made that the MTA should handle this instead of
> the ML manager and, if you make that argument, I'll accept it. :)
> However, it is a feature of ezmlm(-idx) so I figured I'd at least ask for it.

It would be a very nice feature to have, no doubt. In out LUG we just disallow
multipart messages (unless they are multipart/signed) but that is probably a
bit to BOFH'ish for most lists :-) It would indeed make sense to allow - for
instance - multipart/related if each part was text/plain, application/x-patch
or image.

It would require that we recursively parsed the body and its parts. mmj and I
have planed a coding session later today, so maybe we should look a bit more
into it. The more I think about it, the nicer it sounds.

Morten

-- 
Morten K. Poulsen <morten@afdelingp.dk>
http://www.afdelingp.dk/

Re: feature request: DIR/mimereject

[Mads Martin Joergensen]

* Morten K. Poulsen <morten@afdelingp.dk> [Nov 05. 2004 13:25]:
> It would require that we recursively parsed the body and its parts.
> mmj and I have planed a coding session later today, so maybe we should
> look a bit more into it. The more I think about it, the nicer it
> sounds.

Indeed, but it's post 1.1 :-)

Hopefully we'll see 1.1-RC1 this weekend.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: feature request: DIR/mimereject

[morten]

Quoting Mads Martin Joergensen <mmj@mmj.dk>:
> Hopefully we'll see 1.1-RC1 this weekend.

Right ;-)

--
Morten K. Poulsen <morten@afdelingp.dk>
http://www.afdelingp.dk/

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.