Comments on a time-dependent email forwarding system

Posted 22 Dec 2000 at 14:43 UTC by Rhys Share This

If you combine cron and procmail, what might you end up with? Hopefully something that hasn't been done before, but what would the end result be? This is really a request for comments before any lines of code are hacked.

And this is also a first article, by the way. Please be gentle with a poor Apprentice.

Before I commit myself to hacking the code (if I ever do manage to pull my finger out and actually code it), I'd like some thoughts on this.

Whilst working for people who firewall most incoming TCP/IP ports (i.e. who don't let you check your work-address email from outside, and who don't run handy web-based email systems like SquirrelMail), I've wondered how easy it would be to set up an email forwarding system that would work on the time of day and the day of the week.

In other words: could forward to me at uni between 0900-1700 Mon-Fri, apart from the times when I'm at paid work, when it could forward there, and it could forward to me at home at other times.

How would this work? Probably, if there isn't a better way, through a mixture of cron and procmail code. Cron reloads tables every minute, which is a fine enough grain for this sort of thing (I've yet to meet somebody who wants email in a different place during consecutive seconds :)

It might be more worthwhile to look at the user interface on this one, possibly through an easily configurable web frontend or something. Those of you who have experience on procmail might know what I mean.

I sort-of expect replies to be along the lines of 'locking problems.' And all of this might not be a new idea; if it isn't, sorry for wasting your time. I would welcome comments though.

Rhys Jones, Swansea

Simple, posted 22 Dec 2000 at 18:27 UTC by matt » (Journeyer)

$ crontab -e
0 9 * * * echo > ~/.forward
0 17 * * * echo > ~/.forward

You don't even need procmail. Welcome to UNIX, where not every new bit of functionality requires you to write or buy a new piece of software. :-)

Personally, though, I'd be looking at IMAP+SSL with webmail+SSL instead. Otherwise, you end up with e-mail scattered all over the place that you can't get to again.

Simple, posted 22 Dec 2000 at 18:27 UTC by matt » (Journeyer)

$ crontab -e
0 9 * * * echo > ~/.forward
0 17 * * * echo > ~/.forward

You don't even need procmail. Welcome to UNIX, where not every new bit of functionality requires you to write or buy a new piece of software. :-)

Personally, though, I'd be looking at IMAP+SSL with webmail+SSL instead. Otherwise, you end up with e-mail scattered all over the place that you can't get to again.

Simple, posted 22 Dec 2000 at 18:27 UTC by matt » (Journeyer)

$ crontab -e
0 9 * * * echo > ~/.forward
0 17 * * * echo > ~/.forward

You don't even need procmail. Welcome to UNIX, where not every new bit of functionality requires you to write or buy a new piece of software. :-)

Personally, though, I'd be looking at IMAP+SSL with webmail+SSL instead. Otherwise, you end up with e-mail scattered all over the place that you can't get to again.

Darn proxy server, posted 22 Dec 2000 at 18:30 UTC by matt » (Journeyer)

Umm, sorry about the multiple posts. My proxy server at work is rather idiotic.

eh, ... ?!, posted 22 Dec 2000 at 20:09 UTC by ask » (Master)

Rhys, you are just changing to problem from "sometimes never being able to access any mail" to "sometimes never being able to access some mail".

As Matt pointed out, imap+SSL would work better. Everyone I know just use ssh to access the box(es) where they keep the mail and run mutt, pine, whatever there.

- ask

Atomicity and the UNIX way, posted 22 Dec 2000 at 23:22 UTC by Tv » (Journeyer)

UNIX just gave you enough rope to shoot yourself in the foot.

$ crontab -e
0 9 * * * echo > ~/.forward
0 17 * * * echo > ~/.forward

Now your .forward might momentarily contain "uni@f". In real life, that happens as one write so that won't happen, but that doesn't mean you can be as sloppy as you want; nobody guaranteed echo doesn't do 1-char writes. Try

echo >~/.forward.$$.tmp && mv ~/.forward.$$.tmp ~/.forward

qmail rocks., posted 23 Dec 2000 at 01:55 UTC by ask » (Master)

qmail rocks. (duh), posted 23 Dec 2000 at 01:57 UTC by ask » (Master)

[ duh, I pressed enter at the wrong time. Clever. ]

With qmail you'll of course just set

chmod +t $HOME

and edit your .qmail (.forward for qmail) files safely (incoming mail will stay in the local queue).

- ask

Sorry that you've... misunderstood, posted 23 Dec 2000 at 07:40 UTC by Rhys » (Journeyer)

Oops. Eight replies, some of which are unique :) Maybe more explanation is needed here?

First, the story so far. I've been using Unixes of various flavo(u)rs and with various UIs for over eight years now: Solaris, NextStep, HP-UX 9 (urgh!), OSF and, yes, Linux. I'm well aware of what can be done with cron, and the ridiculous flexibility of Unix. One thing I regret in my early days is trying to advocate Internet Explorer (version 2, though, before it got bloated) on the bulletin board of a certain Computer Society. But they learned me, quickly enough.

Anyway, I think I need to make things simpler (always a good *nix philosophy). To summarise in bullet point form, then, and to explain that this is designed, at least in my brain, as a server-side email application, for people without easy access to things like SquirrelMail (or IMP, or any other funky IMAP thing) over SSH. I do use that regularly for my email, thanks, again, to SUCS. But then, if I wasn't at uni, I wouldn't have that privilege. And I'm guessing that it's a rare employer of non-techies that would allow such a thing on their servers.

So let's see. In no particular order, I need:

  1. a web UI to procmail, with as much functionality as is a sensible cut-off point
  2. a means of updating the tables every minute through this UI
  3. either: at or cron (or, actually, self-hacked code) to update the procmail files every minute.

I had already thought of the cron/.forward combination (albeit with a sensible UI), until featuritis took hold thanks to a friend of mine. He said things along the lines of: 'But I'd want to keep my mailing lists at home, always. And anything from Norway would have to stay in the uni.' While he is Unix-literate, I'm thinking of a more mass market here.

But I'll save you from the UML. Until I cobble it together :)

Incidentally, a member of Advogato replied to me by email, and gave me pointers to a muttrc web interface and a dotfile generator, both of which are apparently 'rather simplistic' (I haven't followed up those leads yet). I'd like to thank that member publicly for not misunderstanding me. Though that particular member does know me personally, which I guess does help.

Anyway, that's it for now: I'm logging off for Christmas. Have fun.

Rhys, thinking possibly about setting up a profile.

Remote Mailbox Management Made Easy, posted 23 Dec 2000 at 13:53 UTC by moshez » (Master)

Assuming you have a home computer connected 24/7 (which isn't a pipe-dream nowadays), I'd recommend just forwarding all e-mail there, and then use a protocol likw PMEP or IMAP to read it. Suppose you're on vacation one day, or you like to go to the university a bit sooner: are you sure you'll remember to configure your procmail, even if it is as easy as pressing a button?

Even better...?!, posted 24 Dec 2000 at 22:30 UTC by bodo » (Master)

If you don't have your home PC online 24/7, you could just use some free Web mail account. This however doesn't give you the flexibility of a *nix shell account and all the tools you can apply to your email in this setup.
But try WorkSpot. There you get free email and a free Linux (KDE) desktop account, accessable with every Web browser. This should give you all the flexibility you need.

Why use cron at all, posted 27 Dec 2000 at 05:23 UTC by lgerbarg » (Master)

procmail is a very powerful package. You can execute arbitrary scripts from it. Why not simply set up a recipe like.

:0 ic
where is something like:

$addr="myaddress@home" $date=`date`; $date =~ /(\d\d)\:(\d\d)\:(\d\d)/; $hours=$1; $minutes=$2; $seconds=$3;

if($hours >= 17 || $hours <= 9) { open(MAIL "|mail $addr") while(<STDIN>) { print MAIL $_; } close(MAIL); }

You could even just insert the code in the recipe if you did it as a shell script. I just did that real quick (basicly it came out as fast as I type), so it probably as a typo, or something else wrong, but I think it delivers the point. There is really no need to get cron involved at all, you can check the time at arrival with procmail.


I've been doing this for years., posted 27 Dec 2000 at 18:35 UTC by bbense » (Journeyer)

- I have a highly personalized email filter that is based on deliver ( look in souceforge ) and a perl script. The UI is non-existant, but it forwards and auto-replies based on time of day, phase of the moon and last time I pressed a key.

- Forwarding to my home machine was useful in the days of dialup, in effect the mail would be queued and then delivered roughly 15mins or so after I dialed up. But I haven't used that set-up since I got a 28k modem and interactive programs over dial-up IP became speedy. Now with DSL it's really kind of pointless.

- If you want a hack for your own use, procmail and a perl script should be enough. I can't imagine that building a UI with enough hand-holding to generally deploy it would be very useful. IMAP seems a much better solution for that crowd.

Thanks, posted 28 Dec 2000 at 13:01 UTC by Rhys » (Journeyer)

Thanks for your help. I honestly hadn't considered perl as a piping solution from procmail.

I guess though I really do need to read up on IMAP and find out some of its flexibility. And I think I also heard (being geographically lucky enough to live in a UK cabled area) that my local cable company had reduced the rental on its 512k cablemodems, and also possibly introduced 64k ones as well.

But that's a financial pipe-dream right now.


don't bother with procmail..., posted 28 Dec 2000 at 17:48 UTC by jmelesky » (Apprentice)

If you're going to just use procmail to invoke a script, then you don't need procmail. Especially since Mail::Audit is now on CPAN.

I do my mail filtering with a pipe command in my .forward to a perl script which uses Mail::Audit. It's worth looking at. TPJ had an article on it in their summer 200 issue.

One size does not fit all, posted 28 Dec 2000 at 22:04 UTC by lgerbarg » (Master)

My example invoked a perl script from procmail. Normally I would never do that, I would use shell commands directly in my .procmailrc, I just did not want to deal with the fact that different people use different shells, etc, so I piped it to perl.

Admittedly if you do a lot of processing on all of your mail that requires complex stuff you may want to just bypass procmail. I would not want to though.

Part of it is that my .procmail started almost a decade ago, and has a lot of things in it I take for granted. Part of it is that I have lots of ready constructed recipes that I can insert if I need them. And part of it is that I can depend on my procmail file to work on almost any Unix system... I have already had several experiences where my perl 5.001 code broke under perl 5.004, and that breaks under perl 5.6. I really don't want my mail processing to break because an admin upgrades the perl installation.

To each their own.


Indeed. TMTOWTDI., posted 29 Dec 2000 at 01:42 UTC by jmelesky » (Apprentice)

Sorry -- i wasn't intending to say that using procmail was bad, just that the derivative case you cited could be replaced without use of procmail at all. Also that someone starting from a blank slate might be better served by hacking some Perl than by learning the procmail syntax.

Of course my view is somewhat slanted, as, when i first came to the mail-filtering problem, i was already familiar with Perl but not with procmail. And Mail::Audit is a simple, yet powerful tool for such things.

What it comes down to is: use the tools you're most comfortable using.

OT: Email to database?, posted 1 Jan 2001 at 01:57 UTC by robhudson » (Journeyer)

This is off topic, but I've been thinking of setting up something for myself and a website I'm working on where I can send an email to a certain user account and a perl script (most likely) parses/processes the email and inserts the body into a database.

Would it be better to create a separate user and use a procmail filter to send the mail to the script?

What other options are available for doing something like this?

Thanks, Rob.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page