At 21:00 2002-05-21 -0400, Humberto Rodriguez did say:
I had my system running perfectly with Redhat Linux 7.1 and Procmail
3.14. I then suffered a hard disk failure and afterwards discovered that
the last set of backups were corrupted.
Thank goodness for frequent and fully rotated backups, eh?
I had to restore an old backup,
How old is old? A week usually isn't critical for a server config, and the
server journal you should keep which lists all the config changes should
make it easy to bring a system back to snuff.
but, since I had to reinstall anyway, I updated to Redhat Linux 7.2, which
brought Procmail 3.21.
As long as you're starting anew, you should upgrade that to 3.22 while it
is all fresh in your mind. Some annoying bugs were fixed.
seemed to be working, but now I discoverred that none of my recipes work.
Invoke procmail manually with a message piped to it. Do the recipes work now?
When I went to check the logfile, nothing appears on it, even after
turning verbose to "yes" and logabstract to "all." Obviously, Sendmail is
not handling it over to my .procmailrc file.
sendmail doesn't hand anything over to .procmailrc - it invokes your LDA
which is either procmail (preferrable), or something else which might
hopefully pay attention to a .forward file (which if you previously had
procmail as LDA, and now do not, the necessary .forward probably isn't
hanging around) which you'd have written to invoke procmail.
The documentation in 'man procmail', even through 3.22 is a bit simplistic
WRT .forward complexities. It is valid, and it works, but see my
disclaimer page where you can find an enhanced .forward syntax to use.
From the error you show below, you're apparently trying to invoke
.procmailrc as if it were an executable shell script, which it is
not. Refer to the manpage.
I checked the permissions and only the owner has write
permission. Messages still get delivered to defined users somehow.
My wild guess - because procmail isn't being invoked?
Here is the error message I received:
"This message could not be delivered to the following
recipients:
<test(_at_)usa-hosts(_dot_)com>:
No mail exchanger or IP address. (#5.4.4)"
Uh, this has _NOTHING_ whatsoever to do with procmail.
It sounded like a DNS problem. However, nothing has changed
Other than your *COMPLETE* host configuration. I suggest you finish
setting up and testing the newly configured host. This error doesn't
require that your DNS zone itself have an error - it could be your resolver
config.
Here are the corresponding entry for my main domain and Ip in my
[snip]
Which is NOT what the procmail list is about. Heck, procmail doesn't even
do TCP/IP, so it REALLY doesn't care if your DNS works or not. Procmail
would run just fine on a machine totally unplugged from the internet and
having no named running on it - say, doing local delivery, which
coincidentally, is what procmail does...
If you have an error that is causing email to not work, I'd start with
hunting down that error.
Use 'host -t MX hostname' and see what you get.
From out in the big wide world, that results in:
usa-hosts.com. mail is handled by 10 64.131.176.121.usa-hosts.com.
Now, resolve your MX host. What do you get? From out here, it doesn't
resolve, which sure seems to agree with the error you're getting.
A ping to that host fails miserably. So, start with your DNS config and
reconcile the zone among your various nameservers. Dig is a useful tool
for this.
FTR, your domain registration record shows your DNS servers in this order:
DNS1.USA-HOSTS.COM
NS.VENTURE-1.COM
NS1.TERRACOM.NET
We can start with the fact that:
dig -t SOA usa-hosts.com DNS1.USA-HOSTS.COM
and
dig -t SOA usa-hosts.com @NS.VENTURE-1.COM
don't properly correlate.
nslint is a useful tool for checking named zones (I wish it were updated
for newer syntaxes though). dlint it a nifty tool which utilizes dig to
reconcile live zones (across multiple nameservers). You should check it out:
;; Now linting usa-hosts.com
WARNING: only 1 nameserver found for zone usa-hosts.com
Every zone should have 2 or more nameservers at all times.
;; Now caching whole zone (this could take a minute)
;; trying nameserver 64.131.176.121.usa-hosts.com.
WARNING: nameserver 64.131.176.121.usa-hosts.com. is not responding
properly to queries; skipping.
ERROR: could not find any working nameservers for usa-hosts.com
If you paid money for the RedHat distro, then you should have a support
contract of some sort. AFAICT, that's the only reason people buy into
RH. Seems like a good idea to use the support you paid for, otherwise, it
was wasted money.
I noticed than in my var/named/ directory there is another
file called named.usa-hosts.com.txt which reads as follows:
Time to do some housecleaning and eliminate files which have no bearing on
your actual configuration. Your previous named.conf used which file? Use
that, get the other OUT OF THERE.
Although not referenced by the config you've got, the .txt named one has a
friendlier configuration approach however. Dated serials are more useful
for instance.
Now, I don't know much about DNS and Named, but I checked
That's okay, neither does procmail.
smrsh: .procmailrc not available for sendmail programs
554 5.0.0 Service unavailable
HUH, how are you invoking it? It looks as if you're trying to RUN
.procmailrc as if it were executable. It isn't. Please refer to the
procmail manpage for how to invoke it from a .forward.
It seems that the problem lies within Sendmail, about which
I do not know much. I do know however, that Redhat uses
Procmail as LDA and the appropiate entries seem to be in the
sendmail.cf file.
You know this how? You're positive?
echo =M | sendmail -bt | grep \(local\)
I have not changed the default sendmail.cf.
Excepting swapping it with another version, and hopefully swapping it back,
etc. Have you been RESTARTING the sendmail daemon in between config file
swaps? Have you RESTARTED it since the last one? Have you been changing
the *ACTUAL* sendmail.cf ? IIRC, RH likes to put it in /etc/ which isn't
where sendmail has been putting it for quite a while, in /etc/mail/
Here is my Procmail version:
[snip]
The version alone would be more than sufficient, but hey, at least it is
procmail content. Now, update to 3.22.
Default rcfile: $HOME/.procmailrc
It may be writable by your primary group
... which means that procmail was compiled with the group-as-user option,
which probably has no significant meaning to you, but keep it in the back
of your head for later some day.
Now, I know that I should know what is going on, but I don't
and I am pressed for time. So, if one of you kind souls
could graciously point it out to me, without too much
scolding, I would greatly appreciate it.
1. check if named is running
2. check if /etc/resolv.conf is set properly
3. check that named actually resolves for the zone you provided.
4. check your system and mail logs - see what errors may have been emitted
there by named and sendmail.
Have fun.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail