Re: Pipe debugging - ReadList.com

2 msg	2 postfix server on the same domain in differen...
3 msg	mailer-deamon sends error messages to: question
3 msg	Procmail
15 msg	MAIL FROM timeout with ciphers=high
2 msg	milter, broken pipe
17 msg	How to listen on 587 as well as 25?
6 msg	reject_sender_login_mismatch doesnt work
2 msg	smtp auth
4 msg	Postfix with MYSQL compile error
8 msg	mynetworks=<empty> vs mynetworks=<defa...
3 msg	message_size_limit with ldap search parameter

Pipe debugging
\ Peter Rabbitson (29 Nov 2007)
. \ (Wietse Venema) (29 Nov 2007)

12 msg	destination_concurrency_limit not respected ?
13 msg	Virtual spam forwarding issues
2 msg	cleaning up deferred queue
2 msg	static nexthop per domain
2 msg	Simple postmap question
9 msg	Issues with Recipient_Canonical mapping
3 msg	Mail server reboot after got flood
3 msg	can't create a virtual domain

Subject:	Re: Pipe debugging
Group:	Postfix-users
From:	(Wietse Venema)
Date:	29 Nov 2007

Peter Rabbitson:
[ Charset UTF-8 unsupported, converting... ]
> Hi,
>
> I had the following happen today (localhost is my scanner daemon):
>
> Nov 29 11:04:17 Arzamas postfix/cleanup[1796]: BF6C9AF9BE: message-id=<WITHHELD>
> Nov 29 11:04:17 Arzamas postfix/smtpd[1811]: connect from localhost[127.0.0.1]
> Nov 29 11:04:17 Arzamas postfix/smtpd[1811]: BF6C9AF9BE:
> client=localhost[127.0.0.1]
> Nov 29 11:04:17 Arzamas postfix/qmgr[3594]: BF6C9AF9BE: from=<WITHHELD>,
> size=2041, nrcpt=1 (queue active)
> Nov 29 11:04:17 Arzamas postfix/smtpd[1811]: disconnect from localhost[127.0.0.1]
> Nov 29 11:04:17 Arzamas postfix/pipe[10248]: BF6C9AF9BE: to=<WITHHELD>,
> relay=dbmail-pipe, delay=0.15, delays=0.09/0.01/0/0.06, dsn=5.3.0,
> status=bounced (Command died with signal 11: "/usr/sbin/dbmail-smtp")
> Nov 29 11:04:17 Arzamas postfix/qmgr[3594]: BF6C9AF9BE: removed
>
> After this a bounce was sent to the sender, and I received a system error
> notification. However the email itself was permanently lost from the queue. Is
> there a way to turn this sort of fatal failures into soft bounces, so I have a
> chance to inspect the message that might have caused this?
>

No, because the process would crap out every time Postfix retries,
and could potentially do a lot of damage when left unattended.

Instead of changing Postfix, I suggest that you wrap up the errant
program in a script that returns an appropriate exit status to
Postfix. Exit status numbers are defined in /usr/include/sysexits.h.

Wietse