 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
4 messages in net.sourceforge.lists.courier-maildropRe: [maildropl] Feature request| From | Sent On | Attachments |
|---|---|---|
| Ed Wildgoose | Apr 5, 2005 9:26 am | |
| mouss | Apr 9, 2005 4:57 am | |
| Ed W | Apr 9, 2005 5:39 am | |
| Robin Bowes | Apr 19, 2005 10:34 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [maildropl] Feature request | Actions... |
|---|---|---|
| From: | mouss (use...@free.fr) | |
| Date: | Apr 9, 2005 4:57:53 am | |
| List: | net.sourceforge.lists.courier-maildrop | |
Ed Wildgoose wrote:
2 quick feature requests, or can someone suggest better ways to do this in maildrop.
1) I (for example) subscribe to loads of mailing lists and so would like to have a generic rule which reads the Mailing list header and dumps stuff in a subfolder with the same name (maildir). However, maildrop doesn't seem to autocreate folders when using the "to folder/" syntax and so we end up with a bunch of messy and repeated code to check for existence of folder, create of folder, etc. In a complicated script with a whole bunch of subfolders which is supposed to be rolled out to more than one user this gets really messy real quick. It would be nice if maildrop could try to deliver and create missing subfolders (even if this was a compile time feature only).
Is there a "subroutine" kind of syntax I could use to at least not duplicate this bunch of code each time? (I can sort of see a way with a global var and an include script).
I use a perl script to parse a file and create a maildrop filter file (that is included by the "main" maildrop file). if interested, mail me.
having maildrop to create folders automatically will make you vulnerable to a "random folders creation" attack. I mean, if you just look up some header and create a folder automatically, then someone can you send you messages with random values (or even real ones) so you'll get a lot of folders for MLs you never subscribed to (and that may not exist).
Also, for some MLs, I prefer to have a single folder for a group of multiple MLs, while for others (each has too many messages), I prefer to use a folder for each ML.
2) My script is spending a whole bunch of time (like most of it) dropping into a subshell to do tests to see if folders exist. Would it be worth extending the syntax for maildrop to have an inprocess test for folder existence?
That's why I create the folders ahead of time. When I subscribe to a new ML (more precisely after the confirmation or a first message to see what header names/values the ML uses), I add a corresponding line to maildrop.ml and run a script to generate rules and create folders.
I see no reason to add overhead for a thing that rarely happens (I don't spend my day subscribing to MLs!).