On 2015-01-28 08:33, li...@rhsoft.net wrote:
Am 28.01.2015 um 15:28 schrieb deoren:
I searched via Google and via the mailing list archives, but I didn't
find a post which matched my specific situation.
I see those warnings in the logs when the system goes down for a
reboot.
Is the mail lost? Should I be using a different approach when
rebooting
a server running Postfix? Does the client receive an error and it's
then
up to it to try again?
you need to provide the loglines before *and* after that message
anyways, that's not a normal behavior and the way how postfix and the
SMTP protocol is designed for the delivering client a message is
counted as undelivered until the destination responds with a 2xx code
since postfix can't write the queue file it won't answer with 2xx
Thanks, and you're right, I should have included more information. I was
attempting to trim the message down to just the relevant portion and
trimmed too far.
# grep 33CAC20FBB -A 5 -B 5 /var/log/mail/mail.log.1
Jan 27 16:27:56 screech postfix/cleanup[1140]: warning: BFCD1213F8:
sender_canonical_maps map lookup problem for fail2ban-l...@example.com
Jan 27 16:27:56 screech postfix/pickup[1134]: warning:
maildrop/D9D4C21208: error writing BFCD1213F8: queue file write error
Jan 27 16:27:56 screech postfix/pickup[1134]: BFF19213F8: uid=0
from=<fail2ban>
Jan 27 16:27:56 screech postfix/cleanup[1140]: warning:
mysql:/etc/postfix/mysql-pfix-no-srs-virtual-mailbox-maps.cf lookup
error for "fail2ban-l...@example.com"
Jan 27 16:27:56 screech postfix/cleanup[1140]: warning: BFF19213F8:
sender_canonical_maps map lookup problem for fail2ban-l...@example.com
Jan 27 16:27:56 screech postfix/pickup[1134]: warning:
maildrop/33CAC20FBB: error writing BFF19213F8: queue file write error
Jan 27 16:27:56 screech postfix/pickup[1134]: C0150213F8: uid=0
from=<fail2ban>
Jan 27 16:27:56 screech postfix/cleanup[1140]: warning:
mysql:/etc/postfix/mysql-pfix-no-srs-virtual-mailbox-maps.cf lookup
error for "fail2ban-l...@example.com"
Jan 27 16:27:56 screech postfix/cleanup[1140]: warning: C0150213F8:
sender_canonical_maps map lookup problem for fail2ban-l...@example.com
Jan 27 16:27:56 screech postfix/pickup[1134]: warning:
maildrop/D754B212B1: error writing C0150213F8: queue file write error
Jan 27 16:27:56 screech postfix/pickup[1134]: C1FCE213F8: uid=0
from=<fail2ban>
I looked further and within the stunnel logs on this box I noted that
the connection between this box and the database server wasn't live yet,
so that's why the lookup problem for the destination address occurred. I
was under the mistaken impression that Postfix would have temporarily
accepted/held the mail and tried to perform additional lookup requests
before giving up, but evidently I don't have a solid understanding of
the intake process. I'll do further research in that area.
On 1/28/2015 8:40 AM, wie...@porcupine.org (Wietse Venema) wrote:
deoren:
Is the mail lost? Should I be using a different approach when
rebooting
a server running Postfix? Does the client receive an error and it's
then
up to it to try again?
As required by the SMTP standard, the Postfix SMTP server does not
report success at end-of-data before the message has been stored
(in the case of UNIX-like systems, that includes an fsync call on
the queue file handle).
The same logic applies for local submission and other message
handling paths. The Postfix sendmail command will report "success"
(exit status zero) only after the message is stored. Otherwise, the
program that invokes the Postfix sendmail will have to deal with
the error (as expressed with the exit status);
Thanks. So in my specific case I guess the mail would be lost since
fail2ban uses the sendmail command for delivery attempts and Postfix
isn't able to properly queue the mail?
Regarding solving the lookup error, it looks like I need to introduce a
delay for Postfix until the stunnel connection is available.
# runlevel
N 2
# ls -l /etc/rc2.d/ | grep -E 'postfix|fail2ban|stunnel'
lrwxrwxrwx 1 root root 17 Jun 2 2013 S20postfix -> ../init.d/postfix
lrwxrwxrwx 1 root root 18 Nov 8 23:05 S20stunnel4 ->
../init.d/stunnel4
lrwxrwxrwx 1 root root 18 May 9 2014 S99fail2ban ->
../init.d/fail2ban
Thanks for your feedback. I see that I have some additional
learning/research to do.
