Can't receive mail - ISPConfig / Postfix

[stormalx]

I have installed CentOS, LAMP, ISPConfig, etc. All seems OK, SMTP working fine. However... I can't receive any mail. According to ISPConfig the POP3 server is running fine. When I send an email to either wwwX_user@domain.com or user@domain.com I get the below error emailed straight back... what am I doing wrong!?

This is the mail system at host localhost.localdomain.

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

<web3_test@localhost.localdomain> (expanded from <test@adrianwestaway.com>):
critical OS file missing. Command output: procmail: Error while writing to
"/dev/null"

Final-Recipient: rfc822; web3_test@localhost.localdomain
Original-Recipient: rfc822;test@adrianwestaway.com
Action: failed
Status: 5.3.0
Diagnostic-Code: x-unix; procmail: Error while writing to "/dev/null"

[stormalx]

OK I figured it out. I assumed that there wasn't actually a "critical OS file missing", so if it couldn't write to /dev/null it was probably permissions. So I changed permissions to 666 for /dev/null and it works fine now.

So my question now is, what are implications of setting /dev/null to 666? It's basically a black hole yes? So doing this won't affect security? Excuse my ignorance, but I'm newish to Linux...

[falko]

It's 666 on my system as well, so it seems to be ok now.

[fredj]

Hi there,

sorry for reviving an old thread, but my question fits here best:

Ive had the same problem as indicated above after a faulty update. /dev/null got replaced by a single file chowned by root.root and 744

After deleting the file and replacing it with a correct character dev everything returned to normal.

My question is: What happened to the mail that was not delivered? Does anyone have insights on this? I ask because locally sent mail would NOT give any error messages as the one suggested in this thread by "external" mailer daemons.

Also: Some mail got delivered (mail to non virtual users afaik) while other mail didn't get delivered. Is it correct to assume that only virtual users were affected or those with specific procmail filter entries?

Thanks!
FredJ

[falko]

Originally Posted by fredj

My question is: What happened to the mail that was not delivered?

Maybe it is still in your mail queue. Take a look at

postqueue -p

[fredj]

hello falco

Thank you for taking the time to help!

I should have specified that before, sorry. Checking the postqueue and flushing any messages inside of it was the thing I did right after fixing /dev/null.. But the missing mails weren't there.

In addition, the weird thing is, I'm using maildrop as mailbox_command in postfix/main.cf instead of procmail, however, two users are using .procmailrc filters. So the errors reported by procmail via mail.err could be related to those users only and I probably must look into maildrop mail handling/ error handling for more insights... The only other error I get is the (probably inoffensive?) "imapd-ssl: /etc/courier/shared/index: No such file or directory"

From the procmail manpage I understand that when encountering issues, procmail should store the mail in the default system mailbox. I'm not so sure about maildrop and I remember maildrop debugging being a pita..

Also, it looks as though only non-virtual users were affected by the problem while all virtual users weren't... And that is weird. Not knowing enough about postfix/ clamsmtp/ spamd/ master/ etc interaction, I'm a bit on the defensive side atm.

What surprises me most, is that while debugging the error, NO log-information whatsoever was written to the logfiles upon sending from a "bugged" account. From a user perspective it looked as if the message was delivered (no mailer daemon errors) though it never got to the intended recipient (local or remote afaik).

I might just wait until next maintenance cycle, reintroduce the bug and debug further to find out what was going on. Atm, I'm quite lost and think the mails got lost just as well...

I'm not sure above info will help with finding the mails again, so sorry if anything in here is unessential. I will let anyone know if I find out what went wrong where. Of course I'm open to any propositions.

Thanks again!
fred

[falko]

Originally Posted by fredj

From the procmail manpage I understand that when encountering issues, procmail should store the mail in the default system mailbox.

Can you check the /var/spool/mail/ or /var/mail/ folders if the mails are there?

[fredj]

Hi Falko,

/var/spool/mail and /var/mail are the same (/var/Spool/mail is a symbolic link pointing to ../mail).

I have also already checked /var/spool/postfix for something obvious without much success. (Except for the usual suspects in defer* that i also find doing a postqueue -p)

Thanks for the ideas!
Fred

[falko]

Originally Posted by fredj

Hi Falko,

/var/spool/mail and /var/mail are the same (/var/Spool/mail is a symbolic link pointing to ../mail).

That's ok. Did you find the missing mails there?

[fredj]

Hi Flaco,

Originally Posted by falko

That's ok. Did you find the missing mails there?

well, no. As i said, i've looked into all sub directories and the like and have only found other mail stuck in the postqueue (for lack of existing mailservers to send it to i.e.).

I've given up for the moment, but might try reproducing this again with some time on my hands on a quiet night.

But thanks for the insights anyhow! Greast response times on this forum.

Fred