Copyright 2007 Edward Speyer. All rights reserved.

Delivers a message from $stdin into a maildir.

  usage: deliver-to-maildir <action> <directory>

The script itself should be available from www.tropic.org.uk/~edward/homepage/deliver-to-maildir/deliver-to-maildir

Depending on <action>, the message is delivered into either "new"; or into "cur" with some message flags appended

  action: new  -> new/foo
  action: old  -> cur/foo:2,
  action: seen -> cur/foo:2,S

(where "foo" is actually an appropriate unique name like "1172660944.M85895P32715_0.zubin").

This script can be used in a procmailrc as follows:

  :0w
  * ^From:.*me@example.com
  | deliver-to-maildir seen $DEFAULT

It is particularly useful if you save copies of your outgoing mail by Bcc-ing yourself, but don’t want to be notified of new mail whenever such a Bcc mail arrives in your inbox.

Marking messages as "seen" is actually achievable in a pure procmail way as described on this page:

ilovett.com/blog/programming/procmail-mark-as-read

…which references this procmail thread:

www.mhonarc.org/archive/html/procmail/2005-08/msg00176.html

The procmail code looks a bit like this:

  :0
  * conditions
  {
    foldername=whatever

    :0c
    .$foldername/ # stores in .$foldername/new/

    :0
    * LASTFOLDER ?? /\/[^/]+$
    { tail=$MATCH }

    TRAP="mv $LASTFOLDER .$foldername/cur/$tail:2,S"

    HOST
  }

However, that’s quite messy if you have 10 different types of message that you variously want to mark as seen or old.

Maildir flags information taken from cr.yp.to/proto/maildir.html

  What can I put in info?

  When you move a file from new to cur, you have to change its name from uniq
  to uniq:info. Make sure to preserve the uniq string, so that separate
  messages can't bump into each other.

  info is morally equivalent to the Status field used by mbox readers. It'd
  be useful to have MUAs agree on the meaning of info, so I'm keeping a list
  of info semantics. Here it is.

  ...

  info starting with "2,": Each character after the comma is an independent flag.

       * Flag "P" (passed): the user has resent/forwarded/bounced this
       message to someone else.

       * Flag "R" (replied): the user has replied to this message.

       * Flag "S" (seen): the user has viewed this message, though perhaps he
       didn't read all the way through it.

       * Flag "T" (trashed): the user has moved this message to the trash;
       the trash will be emptied by a later user action.

       * Flag "D" (draft): the user considers this message a draft; toggled
       at user discretion.

       * Flag "F" (flagged): user-defined flag; toggled at user discretion.

The code for writing to a maildir safely was adapted from Matt Armstrong’s RubyFilter code, found here:

www.lickey.com/rubyfilter/rubyfilter/doc/

and requires this notice to be present:

  Copyright © 2003 Matt Armstrong. All rights reserved.

  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions are met:

     1. Redistributions of source code must retain the above copyright
     notice, this list of conditions and the following disclaimer.
     2. Redistributions in binary form must reproduce the above copyright
     notice, this list of conditions and the following disclaimer in the
     documentation and/or other materials provided with the distribution.
     3. The name of the author may not be used to endorse or promote products
     derived from this software without specific prior written permission.

  THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS’’ AND ANY EXPRESS OR
  IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
  OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
  NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
  TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
  PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
  LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
  NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
  SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.