Ok, Procmail by default “is” installed on Cpanel hosts under /usr/bin/procmail. I’m a huge Procmail user, and I don’t want to ditch it. http://www.redhat.com/docs/manuals/linux/RHL-7.2-Manual/ref-guide/s1-email-procmail.html says that all you have to do is add your .procmailrc file to your home directory for it to work. What’s strange, is they make no mention of the .forward file, which is generally used to divert mail through the Procmail LDA for processing. So, I tried this… Sent mail to me@mydomain.com and it come through as typical. I have the Procmail error log set to verbose, but when I check it, it’s blank. Hmm.. Looks like Procmail did squat. :confused:

Then I tried a .forward file with the following line:

"|IFS=' ' && exec /usr/bin/procmail -f- || exit 75 #myusername"

I again sent mail to me@mydomain.com. This time, my mail did not show up. HEY… This is a good thing! At least something is happening. :D But again however, NO Procmail error log was generated. The only thing I can think of is:

A:
My .forward file is incorrectly setup.

B.
Something in my .procmailrc file is not setup correctly to work, and or to write error messages. Small snippet from my .procmailrc file:
---------------------------------------------------
SENDMAIL=/usr/sbin/sendmail
LOGFILE=$HOME/errors/log.`date +%Y-%m`
VERBOSE=on

# Blocked Users

:0
* ^From: spammer@domain.com
/dev/null

Obviously, I have a ton of additional Procmail recipes, which do a host of various tasks, but there’s no need to display all of those here.

Is there something I need to set in the exim.conf file? I realize that Procmail is not terribly popular on this forum, but I’m hoping that maybe… just maybe… someone has tried this on a Cpanel host. Any insight would be very much appreciated.

Thanks!

I know someone was asking me about this the other day. I'm not sure if they did anything or not. The thing is, I'm not sure how much this would relate to Cpanel or not, as much as it would (as I'm sure you are aware) to Exim. Perhaps check out some information about Exim and procmail, and see what, if anything, you can find. Good luck.

You can make a .procmailrc file your home directory with the filters you want, then you can create a forward in CPanel to forward to /usr/bin/procmail.

Thanks all.

After 7 long hours of hardcore (hacking my way through it), I got it! Well, sort of… I’ve managed to invoke Procmail, but the mails are landing in the wrong place, so I’m still working on directing them to the right location. Um.., Why couldn’t Cpanel based hosts just use Qmail? ARGHHH…. Exim has a few problems, and is totally anti Procmail, or so at least it seems amongst other problems.

While it was thought that Procmail was on its way out, this could not be further from the truth. It’s made a massive come back, and is still aggressively maintained. Most Unix discussion groups can easily qualify that one. Ok, sure, trying to figure it out can be like looking at a plate of spaghetti at times, but it’s mean, lean, and robust!!

Ok, for anyone else about to embark upon the nightmare of Exim and Procmail, here’s the secret. Exim chokes on the .forward file, which is typically constructed like this:

"|IFS=' ' && exec /usr/bin/procmail -f- || exit 75 #yourlogin"

Exim pukes (or at least it appears on the pipe command), so your .forward will never work properly. Upon investigating the exim_mainlog file, I found this:

2002-04-24 17:13:36 170U50-0004cH-00 ** |IFS=' ' && exec /usr/bin/procmail -f- || exit 75 #administrator <me@server.myhost.com> D=userforward T=address_pipe: "IFS='" command not found for address_pipe transport

OUCH!! I’ve never seen this problem before. The fix? Use this instead: "|/usr/bin/procmail" Ahh it works!


First of all, 90% of MTA’s “No Longer” require a .forward file, but Exim does; well actually, you could configure it to use Procmail as a default LDA, but it would appear as if CPanel has decided to use the built in features of Exim for “Its” mail features, and I don’t believe you can include 2 LDA’s in the Exim.conf file. Removing the current settings, and replacing them with Procmail would probably mess up Cpanel’s mail system global wide. I’m still tempted to try it though. I just don’t like this Exim stuff. I’m not bashing it or anything, I just don’t completely understand its philosophy.

More trouble with Exim:

You know all those complaints you here about Cpanel hosts have countless problems with people receiving their email? Well… That happened to me last night. I’m power testing my Procmail config, but where the HELL are my test mails!!! OH MY GOD…. Some of them are showing up 6-hours later. So, here I’m thinking it’s pair’s SMTP server that may be slow (VERY unlikely), so I tried my ISP’s SMTP instead. Same thing… Out of 5 emails sent to my Cpanel host, 3 to 4 would be delayed for 15 minutes, to 3, 4, or 6 hours!! Nasty…

You can imagine how angry this is getting me. I’m trying to test Procmail mail, and every message (may or may not come through right away), so has Procmail crashed, is there a mail loop taking place, has Exim gone down??? I mean, it’s like I’m sitting there like a doorknob waiting for my test message, which should take no more than a few seconds. Sigh…

So, what is the problem?

Well Blow me Away… Exim does a DNS lookup on Every_Incomming_Mail_Message!! YIKES! I checked the Exim’s log, and indeed, there are all my emails from hours ago sitting in the queue. Imagine, if these were urgent tech support requests? I’d be bankrupt by now.

So what’s happening:

I don’t know for sure, but I think that in (some ingenious means) to demote spam, someone has configured Exim to do a FULL DNS lookup on “Every” message that comes in. PHEW!… Talk about a lot of overhead, and MANY MANY deferred messages.

You see, if Exim cannot complete the DNS lookup within a few seconds, BOOM… your incoming messages are now placed on the queue. At this point, Exim will try again in 2, 15, and 30 minute intervals to complete a DNS lookup. If those fail, it will try once every several hours. This means, an incoming message could be deferred for hours or days.

Of course, some “sending” hosts (depending on how busy they are) could take some time to respond, OR maybe Exim is being too strict on the info it’s trying to extract. At any rate, just because the sending mail server does not provide the info Exim was looking for, DOES NOT necessarily mean it’s rogue! I must have sent about 50 messages, and only 20 came through.

Have a look at the Exim log, and what do we see?

How about pages UPON pages of this:

2002-04-23 23:40:02 16ypon-0000NA-00 == root@me.myserver.com T=local_delivery defer (-43): Retry time not yet reached
2002-04-23 23:40:02 16ypon-0000Mp-00 == root@me.myserver.com T=local_delivery defer (-43): Retry time not yet reached
2002-04-23 23:40:02 16yqlp-0000WB-00 == root@me.myserver.com T=local_delivery defer (-43): Retry time not yet reached
2002-04-23 23:40:02 16yuEV-00017i-00 == root@me.myserver.com T=local_delivery defer (-43): Retry time not yet reached
2002-04-23 23:40:02 16yuQj-0001KE-00 == root@me.myserver.com T=local_delivery defer (-43): Retry time not yet reached
2002-04-23 23:40:02 16yyxl-0001vh-00 == root@me.myserver.com T=local_delivery defer (-43): Retry time not yet reached
2002-04-23 23:40:02 16zCtD-0005Px-00 == root@me.myserver.com T=local_delivery defer (-43): Retry time not yet reached
2002-04-23 23:40:02 16zCtD-0005Q1-00 == root@me.myserver.com T=local_delivery defer (-43): Retry time not yet reached
2002-04-23 23:40:02 16zHZR-0006Q5-00 == root@me.myserver.com T=local_delivery defer (-43): Retry time not yet reached
2002-04-23 23:40:02 16zYye-0002fi-00 == root@me.myserver.com T=local_delivery defer (-43): Retry time not yet reached
2002-04-23 23:40:02 16zZug-0003H1-00 == root@me.myserver.com T=local_delivery defer (-43): Retry time not yet reached
2002-04-23 23:40:02 16zdew-0003gg-00 == root@me.myserver.com T=local_delivery defer (-43): Retry time not yet reached
2002-04-23 23:40:02 16ziLG-0005BJ-00 == root@me.myserver.com T=local_delivery defer (-43): Retry time not yet reached
2002-04-23 23:40:02 1700WY-0004ZN-00 == root@me.myserver.com T=local_delivery defer (-43): Retry time not yet reached
2002-04-23 23:40:02 1705Cs-000575-00 == root@me.myserver.com T=local_delivery defer (-43): Retry time not yet reached
2002-04-23 23:40:02 16zvqN-0003Aj-00 == root@me.myserver.com T=local_delivery defer (-43): Retry time not yet reached

I’m not blaming this directly on Exim. Maybe it’s just the way it’s configured, but I suspect this is the culprit responsible for that wonderful Cpanel special… “Hey… My customers are complaining that they can’t receive email” scenario you commonly see posted here, and or on other web host providers discussion forums. Of course, if DNS lookups are unsuccessful after a period of time, then the incoming message is nuked! OUCH!

Again, I can see what the objective is here, which is to block rogue hosts, but I can’t see this method as a terribly viable way to do it. I’m now looking for a way to disable this lovely feature. So far, I commented out a number of things in the Exim configuration file, however no luck… Mail is still being deferred for hours. I’ve tried sending from 5 different servers-- even Yahoo, but still no luck.

Again, I’m not bashing Exim; I’m just having a hard time trying to make sense as to why someone would configure it that way for. There are “Many” ways to block Spam, but doing it this way could have harsh consequence for both end user, as well as the provider supplying the service. Sorry for the long post, but I just had to share this.

Thanks again all. Really appreciate the help!

This just keeps getting more interesting. Procmail is fully functional, BUT here’s yet another mystery of a Cpanel host. Unlike a normal configuration, mail “is not” written to /var/spool/mail or /var/mail. Nope, not here, but yes those two directories and files do exist—they’re just not used.

So, here’s what happens: Procmail will write to wherever I want it to. If I point it to /var/mail/mylogin, pop3 will pick it up as expected. However, nothing goes to Neomail. In fact, I can set Procmail mail to write to mylogin/home/mail, and that works too. But again, nothing is going to Neomail.

Here’s how Neomail is supposed to be configured:

Neomails .db files are simply indexes into the actual flat mail spool files. They are regenerated whenever the spool contents change. BUT not on this configuration… Mail is written to somewhere before both pop and Neomail grab it, but where!!

Sure, I could simply forgo this use of Neomail, and settle for pop access only, however if I could find the place where mail is being written to on this server, “before” pop and Neomail pick it up, I could set Procmail to write to that directory. Does anyone know where this may be?

Thanks, and promise… When I get good at this, I’ll start contributing to the forum, as opposed to asking for lot’s, and giving nothing in return.

Thanks!