How to use procmail to forward mail to a specific IMAP folder?

[tbessie]

Hey there folks...

For years now, I've been using procmail to take incoming mail and place it into specific local folders in my shell account based on specific words in the subject, the sender, the original target email address (I tag my email based on whom I've given it to), etc., which I later read using Pine.

This is fine, but it means that I can't access these folders easily from a mobile app.

What I have been thinking of is to use procmail, instead, to place incoming mail into separate IMAP folders. I can definitely create IMAP folders at will on the mail server, but I can't seen to figure out what to do in procmail to route incoming mail to them. The documentation doesn't talk about this, and I can't find a Linux utility program that can do this. I can forward the mail to another address, but that's not the same thing. What I want is to take an incoming mail and place it in a known, named IMAP folder on Sonic's mail server.

I can't use the free extra mailboxes I have, since each mailing is an entire IMAP tree structure, with a separate login and password, which isn't what I want. I want to use my main email account, but just add extra IMAP inboxes to it, and route incoming mail to them.

I asked regular Sonic support how to do this, and they said they believe it's possible, but they didn't know how.

Anyone have any ideas on how to do this?

- Tim

[kgc]

Tim, something like this. $DEFAULT is your Inbox, so ${DEFAULT}.spam/ would be "INBOX.spam" in IMAP. Since bolt still mounts the mail spools directly you just "cd $MAIL" and take a look around.

Please note the trailing slash which identifies the destination as a Maildir folder. Procmail will make it for you if it doesn't exist.

Code: Select all

#delivers to INBOX.spam
:0
* ^Subject: SPAM
${DEFAULT}.spam/

#delivers to nested folder INBOX.spam.also
:0
* ^Subject: ALSO SPAM
${DEFAULT}.spam.also/

[tbessie]

Kelsey - so does $DEFAULT point to the IMAP server and folder, or does it refer to the mounted source that IMAP accesses? I'd want to do it strictly via the server, not assume that they're available via the filesystem.

- Tim

[kgc]

Kelsey - so does $DEFAULT point to the IMAP server and folder, or does it refer to the mounted source that IMAP accesses? I'd want to do it strictly via the server, not assume that they're available via the filesystem.

Procmail runs with direct access to the mailspool in a way that cooperates with the IMAP servers and cannot deliver messages directly via IMAP.

[tbessie]

Kelsey - so does $DEFAULT point to the IMAP server and folder, or does it refer to the mounted source that IMAP accesses? I'd want to do it strictly via the server, not assume that they're available via the filesystem.

Procmail runs with direct access to the mailspool in a way that cooperates with the IMAP servers and cannot deliver messages directly via IMAP.

Do you suppose it will always remain that way (eg. with the new shell server)? I'm hoping so, as I'd like to be able to depend on that.

- Tim

[kgc]

Kelsey - so does $DEFAULT point to the IMAP server and folder, or does it refer to the mounted source that IMAP accesses? I'd want to do it strictly via the server, not assume that they're available via the filesystem.

Procmail runs with direct access to the mailspool in a way that cooperates with the IMAP servers and cannot deliver messages directly via IMAP.

Do you suppose it will always remain that way (eg. with the new shell server)? I'm hoping so, as I'd like to be able to depend on that.

- Tim

For the foreseeable future, yes. Supporting procmail does cause some challenges for us but is also something we are committed to support.

[tbessie]

Procmail runs with direct access to the mailspool in a way that cooperates with the IMAP servers and cannot deliver messages directly via IMAP.

Do you suppose it will always remain that way (eg. with the new shell server)? I'm hoping so, as I'd like to be able to depend on that.

- Tim

For the foreseeable future, yes. Supporting procmail does cause some challenges for us but is also something we are committed to support.

I can't remember who, either you or Dane, mentioned that procmail can use a lot of resources or something along those lines - is that the issue?

- Tim

[kgc]

I can't remember who, either you or Dane, mentioned that procmail can use a lot of resources or something along those lines - is that the issue?

No, not really. It is more a function of that supporting procmail complicates or limits our ability to make technical decisions on how the mail platform works as a whole. But don't worry about it, we're unlikely to ever completely remove support for procmail.

[tbessie]

I can't remember who, either you or Dane, mentioned that procmail can use a lot of resources or something along those lines - is that the issue?

No, not really. It is more a function of that supporting procmail complicates or limits our ability to make technical decisions on how the mail platform works as a whole. But don't worry about it, we're unlikely to ever completely remove support for procmail.

Good to hear! (about it not going away) - thanks!

- Tim