How to keep procmail functionality?


#1

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!


#2

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?


#3

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.

:cool: openvein.org -//-


#4

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


#5

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.

:cool: openvein.org -//-


#6

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


#7

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


#8

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.


#9

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


#10

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


#11

This is leading me to search for another provider.
Has anyone tried another hosting provider for this reason? and if so where did you go?


#12

I spent quite a bit of time trying to work around DH’s restrictions and make what they had changed work for me.

That was untenable and I ended up transitioning directly to Google Apps for e-mail as a temporary measure. For hosting, I am currently transitioning to Rackspace Cloud Servers as my long-term contract with DH was up and their response to this problem left me with a bad taste in my mouth.

It bears mentioning that in moving some clients off DH, I switched the DNS servers for the hosting to a 3rd party provider and then pointed the websites to the new provider.

The minute that DH’s systems saw that they were no longer hosting the DNS, they broke the e-mail setup and my client started to lose mail (as I hadn’t gotten around to setting up the mail server to receive my client’s mail). This is a bit excessive as I still am a DH client and I HAD NOT DELETED THE E-MAIL HOSTING ON DREAMHOST.

It’s been 2 weeks now carving out the time to fix this and calm down my client.

They’re pissed and it’s going to take a while to recover from this. In the meantime, I will be completely leaving DH and won’t be coming back. It’s a shame, because up to this point I was pretty pleased with them.


#13

> It bears mentioning that in moving some clients off DH, I switched the DNS servers for the hosting to a 3rd party provider and then pointed the websites to the new provider. The minute that DH’s systems saw that they were no longer hosting the DNS, they broke the e-mail…

Sounds like a bloody nightmare. Was the change to the nameservers performed using the DH Panel under each domain here, or was DNS management being handled at a 3rd party place already?

Maximum Cash Discount on any plan with MAXCASH

How To Install PHP.INI / ionCube on DreamHost


#14

[quote]Was the change to the nameservers performed using the DH Panel
under each domain here, or was DNS management being handled at a
3rd party place already?

[/quote]

First I added other nameservers to the domain (with the registrar) as failovers and to start propagating changes for the new server. I added entries for services being hosted at DH, and then (after propagation) I deleted the DH nameservers from the domain record (all this done EXTERNAL to DH)

DH changed the status of the domain to “not with us” and everything went wacky.


#15

I’m really surprised this apparent glitch hasn’t been mentioned in the forum before. Surely you can’t be the first user to have website files located elsewhere while retaining MX records pointing to your DreamHost account…

I’d be seriously ALL CAPS’ing all over the board.

Maximum Cash Discount on any plan with MAXCASH

How To Install PHP.INI / ionCube on DreamHost


#16

The damage is done, it’s no longer important to me nor productive to complain to Dreamhost.

I spent part of my time figuring out another way to get at the e-mail that was still on DH’s servers and the rest of my time getting my client’s e-mail back up, working, and not being “returned to sender”.

The issue is obscure enough that it’s possible that nobody has run into it before. Dreamhost made a business decision that they don’t want to use server resources that people don’t use and one of those indicators seems to be if you don’t have them as the primary DNS. They have their reasons, I’m sure, but they seem like they just want to bill customers for services they don’t provide when they tighten the strings this tight.