how to keep procmail functionality?

So I'm being summarily migrated, with very little notice, and am scrambling to deal with this. I heavily use procmail, unfortunately, but only use it for forwarding, filtering and running scripts in response to emails.

The key here is that I do _not_ use procmail to sort mail into custom POP folders, or anything like that that would rely on common filesystem access between mail and web servers... At least I think that's the key saving grace...

If I am understanding correctly, from reading several posts here, it looks like all my procmail filtering will continue to work, _as long as_ I end up forwarding my email to specific_user_account@web_hosting_machine.dreamhost.com, then the .forward for that account will still receive the mail (and since mine pipes to procmail, I can still process it via .procmailrc).

Is this understanding correct?

If so, then all I'll need to know is what my specific web_hosting_machine will be after the migration. I assume dreamhost will let me know this in an, erm, timely manner after the migration, so I don't end up losing email for days on end?

Thanks in advance for any clarification anyone can provide on these points!

Too bad no replies here. I am about to start setting up my own .procmailrc and I think I know what I am going to do, but if anyone here has any DH specific tips, they'd be most appreciated. I've been using procmail with imap for years and years. For instance, what is the file system setup for mail folders here at DH?

It's Maildir.

Also see http://wiki.dreamhost.com/Procmail

It's a bit outdated. To clarify:

1. "Fully-hosted" mailboxes are stored on separate mail servers - you can only access them through the POP and IMAP protocols.

2. Shell/FTP/SFTP users recieve mail at username@machine.dreamhost.com

3. The name of the machine is shown with the list of users in the Web Panel.

4. As if it is not obvious - you can setup a "Forwarding-only" address with the machine address as the destination to avoid disclosing the machine address.

5. Use a .forward.postfix file to get Postfix to pipe the messages to Procmail.




openvein.org -//-

Atropos7,
Thanks for the quick reply. SO it looks like I can't access the file system directly, which is how I am used to writing my rules (especial with maildir). So, how do the delivery rules work?
${DEFAULT} ??? Does this work?
What about other imap folders in my inbox?

Any chance I could get you to post part of your .procmialrc?

Skip

In reply to:

---

Thanks for the quick reply. SO it looks like I can't access the file system directly, which is how I am used to writing my rules (especial with maildir).

---

*shakes head*

OK let me point out one more thing that you apparently didn't catch. There are two mail systems.

The first one is the "fully-hosted" e-mail that you get to use with your domains. Messages sent to these addresses end up being delivered to mailboxes on dedicated mail servers where you can access them only through POP or IMAP. Thus "fully-hosted e-mail" is altogether separate from users.

Thus the second mail system is available to users (ie, FTP/SFTP/shell user accounts). These users are tied to a machine - the machine running the Apache web server - and that machine is configured to use Postfix to deliver messages. The mailbox for those messages is the Maildir in your home directory.

So to point out the obvious you need to get the messages addressed or forwarded to the user so that you can manipulate both delivery and the message store.

And read the Procmail wiki page I linked to - it tells you how to get Postfix to pipe through Procmail and examples of using Procmail.


openvein.org -//-

In http://wiki.dreamhost.com/Talk:Procmail#Workaround
I detail how DreamHost eventually sponsored a Private Server for me.

Edited by jidanni on 06/27/09 02:35 PM (server time).

As of 09/15/2009, my Maildir in my home directory (on the new server after being moved) has vanished and my custom procmail instalation and filters have gone to s**t.

So, this explanation may be of help to people who still have a Maildir, but mine is gone (and probably the people who have one will find that theirs disappears too)

Jacob

I see, http://wiki.dreamhost.com/Talk:Procmail#Workaround will be of little help, as you have already implemented it, and something has deleted your internal files anyway. Hmmm.

Edited by jidanni on 09/17/09 11:13 AM (server time).

Hi,

I've experienced the same issue. I was moved from Hyperion to Nuggets and now I have no Maildir, and my personal spam assassin training scripts no longer work.

Does anyone know where our Maildirs now exist so I can update my scripts appropriately? Or is there a way to get my Maildir back in my local user directory?

Thanks,
Matt

Yes, but no.

The solution proposed by DH is the following:

You set up the filters via the control panel to catch all incoming mail. I've modified them as follows:

i) First, add the header X-MyEmail-Unfiltered: 1 to emails without X-MyEmail-Unfiltered: 1 in the headers and then continue.
ii) Then, move emails with X-MyEmail-Dest: Inbox in the headers to Inbox and then stop.
iii) Then, forward emails that Do not contain X-MyEmail-Dest: in the headers to [SHELL USER]
iv) Finally, move emails with X-MyEmail-Unfiltered: 1 in the headers to Inbox and then stop.

In this situation, [SHELL USER] is a user that you have that still has shell access (Like the one that had a Maildir).

Ok, so the messages come in and since all of them are tagged with the X-MyEmail-Unfiltered: 1 header in the first filter, they are forwarded to the shell user. You then do your filtering using procmail, spam assassin, etc but WITHOUT A MAILDIR and then (at the end), you forward those messages back to your e-mail address (this time with X-MyEmail-Unfiltered set to false and with X-MyEmail-Dest: Inbox) and the messages will be deposited in your inbox of the MAIL user (i.e. not the shell user).

The key conceptual thing to understand is that you may have a mail user and a shell user that share the user name. Huh??? that is, you may have user@example.com to receive mail. That user is on the mail server and can and will receive mail. But, then you also have user@example.com as a SHELL USER which can also receive mail forwarded from the MAIL USER, but cannot deliver that mail to any maildir but *can* forward that mail back to user@example.com (MAIL USER).

So, that's the solution proposed by DH.

Obviously, the moment that you start forwarding mail to the shell user and back, you start the counter counting for your sender quota and you stand a very good chance of getting blocked. That is where I am at. DH says that they can ask the abuse department to give me a larger quota, but they absolutely refuse to allow me to go back to being able to use procmail with a Maildir. And, they don't have any solution to keep me from exceeding the sender quota for what is (for all intents and purposes) internal traffic on their internal network to shuttle messages from one DH server to another.

I have to say that I'm not looking forward to modifying all my filters that I had made and I don't trust DH to not block my incoming mail causing it to be returned to sender as undeliverable.

It's encouraging me to look for another provider.

Jacob