I’m sorry to have to inform you that your message could not
be delivered to one or more recipients. It’s attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
ps3@madshaun1984.dyndns.org (expanded from webmaster@ps3fanatics.co.uk):
Command died with status 127: “mailbox_command = /usr/bin/procmail-wrapper
-o -a $DOMAIN -d $LOGNAME”. Command output: sh: mailbox_command: not found
It sounds like something went awry with the installer… normally, I’d suggest that it sounds like you’re not using a supported distro, but you showed that you were using 8.04… which should work just fine
What happens if you manually install the procmail-wrapper program:
apt-get install procmail-wrapper
That should get that installed for you, and email should start working at that point
I’ve had procmail-wrapper installed since the beginning, its just it doesnt seem to want to work, I just resent another test email though, with the changes made for the mail_command to use procmail-wrapper, and the log didnt show an error, but at the same time the forwarded mail ahsnt appeared in my inbox (procmail.log didnt actually show anything was forwarded though)
Update, ok I really dont know whats going on now, procmail-wrpaper is now working for sending and receiving mail from and to the server, forwarding is still not happening,
^ that seems to be the cause of the mail not being forwarded, and Idea what I need to change/edit to fix it?
I say its that, as its appearing in the /var/log/procmail.log for every email that is supposed to be forwarded, but not for emails that are for other accounts that arent set to be forwarded. (if that makes sense)
I cant see anything wrong with the setup at all now, yet forwarding still isnt working,
(the email addy in the lines above was changed just to protect my inbox from spam, but in the file it is an actual email addy)
Sorry, this will be my last update to this problem, I have email forwarding working on other domains,
all I did for those domains was set the email forward up, and then sent a mail to webmaster@testdomain.com it was delivered to my server and to the forward address succesfully.
I then tried to send another test email to the original domain on my server, but it still fails with the .procmailrc cant be read,
Any idea how I can manually reset the domains email so that I can add the forwarder again. without losing any info stored in that domains files?
Eit:- I mean give it a completely clean .procmailrc as deleting the old (corrupted one) and resetting up the email forward doesnt solve the issue.
You could always try deleting the .procmailrc file it says it doesn’t like – perhaps when you recreate the forwarding, it’ll correct the problem it has with it.
Yep tried that, unfortunatly it seems to be holding some info on the file, so when a new file is created it gets corrupted again.
Oh and thanks for your help with this again, at least I now (thanks to your help) have procmail-wrapper set up and working
Edit:- another 1:30 spent on this, I have deleted all files that are created when adding a forwarding address, and then rechecked virtualmin config, stopped and started postfix, and then reset up the forwarding email address, yet I still get the error, luckily it wasnt to big a problem for that domain, and forwarding is working perfectly from the domain I needed it to, so alls god in the end.
It would seem that there is a bug in there somewhere that wont allow you to delete the .procmailrc file without the server holding data and then corrupting the new settings when re adding a forwarding address.
As careful reading of the"Suspicious rcfile" error message note in the DIAGNOSTICS section of the man-page, the directory which contains the .procmailrc file cannot be either group or other writable. Presumably this is to prevent someone other than the user from changing the .procmailrc file and redirecting the mail.
It was the “not group writable” problem that tripped me up as I think at some point in time procmail may have worked with $HOME being group writable.
Of course it would be nicer if the procmail error made it clear which procmailrc permissions constraint was being violated rather than leaving it up to the user to figure it out…
