So, I got sick of messing around with procmail every time I signed up
for some email based service that didn't helpfully identify itself with
some sensible header. I think I have a partial solution. Well, if you
happen to own your own domain and use Courier and procmail then it's a
partial solution. First of all, the rule (which is no doubt exposing my
computer to all manner of exploits, but it's a COOL RULE):

# handle the zany aliases I hand out to people.
:0
* ^TO_.*\/[EMAIL PROTECTED]
{
    ADDR=$MATCH

    :0ci:
    * ADDR ?? ^\/[EMAIL PROTECTED]
    | ([ -d /home/james/Maildir/.misc.$MATCH ] || echo INBOX.misc.$MATCH
>> /home/james/Maildir/courierimapsubscribed)

    :0:
    * ADDR ?? ^\/[EMAIL PROTECTED]
    $MAILDIR.misc.$MATCH/
}

So, what it does: It will file mail to any of the addresses in my
james.id.au domain into separate folders. So, for example, Fairfax
Group's f2 service, which I signed up to as '[EMAIL PROTECTED]' will go
into a misc/f2 folder. In addition though, if this is the first email
that has been placed in that folder, it will automatically subscribe me
to that folder. Now, I'm yet to find out how to ask courier to re-scan
the subscriptions file, so for now I only see these new folders when
courier gets restarted (which ends up being when I restart my laptop, so
once or twice a day).

Now, the nice thing about examining the filesystem to determine when to
add a subscription is that it will respect it when I tell evolution to
unsubscribe from a given folder -- it won't go re-adding it every time
(as my first attempt at this did).

Just in case anyone's interested in how it works, the \/ token tells
procmail to dump whatever matches after that character into the variable
$MATCH. The rules with '* ADDR' then perform a second regex match on the
result of the first one. That lets me strip off the @domainname part.
The :0ci: rule does the subscription. I'm abusing the | operator to
start some shell code and the "[ ] || echo" construction is my very lazy
way of writing if statements in shell. The second part in there (the
part that starts with :0:) actually files the email away into its final
destination.

I think there's a race-condition in there since the 'c' modifier tells
procmail to fork. That probably means I need to do lockfile stuff a
little more rigorously but for now everything seems to work.

Hope someone finds this helpful,

James.

-- 
James Gregory <[EMAIL PROTECTED]>

Attachment: signature.asc
Description: This is a digitally signed message part

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Reply via email to