Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
warning: maildrop/33CAC20FBB: error writing BFF19213F8: queue file write error
997 views
Skip to first unread message
deoren
Jan 28, 2015, 9:28:36 AM1/28/15
to
Hi,
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?
Thanks for your time.
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?
Thanks for your time.
li...@rhsoft.net
Jan 28, 2015, 9:33:20 AM1/28/15
to
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
Wietse Venema
Jan 28, 2015, 9:41:11 AM1/28/15
to
deoren:
> Hi,
shuts down, it kills processes.
> 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);
Wietse
> Hi,
>
> 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.
What warnings? You failed to include the program name. As the system
> 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.
shuts down, it kills processes.
> 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?
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);
Wietse
deoren
Jan 28, 2015, 11:10:58 AM1/28/15
to
>> 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.
>> 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?
>
>> 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
>
> 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
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 fail2b...@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 "fail2b...@example.com"
Jan 27 16:27:56 screech postfix/cleanup[1140]: warning: BFF19213F8:
sender_canonical_maps map lookup problem for fail2b...@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 "fail2b...@example.com"
Jan 27 16:27:56 screech postfix/cleanup[1140]: warning: C0150213F8:
sender_canonical_maps map lookup problem for fail2b...@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
>> 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);
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.
li...@rhsoft.net
Jan 28, 2015, 11:36:33 AM1/28/15
to
Am 28.01.2015 um 17:10 schrieb deoren:
> 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
>>
> 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.
>
> attempting to trim the message down to just the relevant portion and
> trimmed too far.
>
> Jan 27 16:27:56 screech postfix/cleanup[1140]: warning:
> mysql:/etc/postfix/mysql-pfix-no-srs-virtual-mailbox-maps.cf lookup
> error for "fail2b...@example.com"
> Jan 27 16:27:56 screech postfix/cleanup[1140]: warning: C0150213F8:
> sender_canonical_maps map lookup problem for fail2b...@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
postfix *must not act* that way
> mysql:/etc/postfix/mysql-pfix-no-srs-virtual-mailbox-maps.cf lookup
> error for "fail2b...@example.com"
> Jan 27 16:27:56 screech postfix/cleanup[1140]: warning: C0150213F8:
> sender_canonical_maps map lookup problem for fail2b...@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
you can't accept/held something when half of your lookup-tables are not
available because they may contain rules to clearly reject a message
there is no "temporarily accept"
if you accept a message you issue 250 OK to the sender and after that
you have to deliver it or create a bounce which makes you to a
backscatter and leads in blacklisting
the only sane thing a MTA can do in doubt is *temporary reject* with 4xx
and so the sender tries again later
Wietse Venema
Jan 28, 2015, 12:44:35 PM1/28/15
to
deoren:
> Jan 27 16:27:56 screech postfix/cleanup[1140]: warning: BFCD1213F8:
The cleanup server has a problem.
> Jan 27 16:27:56 screech postfix/pickup[1134]: warning:
leaves it in the queue, so that it can try again later.
Wietse
> Jan 27 16:27:56 screech postfix/cleanup[1140]: warning: BFCD1213F8:
The cleanup server has a problem.
> Jan 27 16:27:56 screech postfix/pickup[1134]: warning:
> maildrop/D9D4C21208: error writing BFCD1213F8: queue file write error
Therefore the pickup daemon cannot process the submission and
leaves it in the queue, so that it can try again later.
Wietse
0 new messages