We have recently begun using PostFix to replace one of our legacy systems. For the most part, the system appears to be running fine under load. Recently we have begun seeing some sporadic delivery errors. One error in particular is hard to trace back to its original message and confirm that the message was delivered.
The error we see in the logs looks like: Mar 27 16:20:54 redactedServer postfix/cleanup[24237]: warning: ldap:/etc/postfix/ldap-aliases.cf lookup error for "redacted@domain" Mar 27 16:20:54 redactedServer postfix/cleanup[24237]: warning: 745EC6AC49: virtual_alias_maps map lookup problem for redacted@domain -- deferring delivery We also receive an email with this content: =========== Transcript of session follows. Out: 220 redactedServer ESMTP Postfix In: EHLO redacted2Server Out: 250-redactedServer Out: 250-PIPELINING Out: 250-SIZE 36700160 Out: 250-VRFY Out: 250-ETRN Out: 250-ENHANCEDSTATUSCODES Out: 250-8BITMIME Out: 250 DSN In: MAIL From:<redacted@domain> SIZE=1302 Out: 250 2.1.0 Ok In: RCPT To:<redacted@domain> Out: 250 2.1.5 Ok In: DATA Out: 354 End data with <CR><LF>.<CR><LF> Out: 451 4.3.0 Error: queue file write error In: QUIT Out: 221 2.0.0 Bye For other details, see the local mail logfile ======= Emails sent to the same user, before and after this error occurs, are delivered without issue. We have three questions regarding this issue: 1 If we search for the message ID that is included in the error in the logs, in this case 745EC6AC49, it doesn't appear to pull any log data on the original email. We can search for emails to that the same recipient, with the same sender, and confirm that a message was delivered. However, in some cases the person receives multiple messages from the same sender so it is hard to determine if we are seeing the original message being delivered or not. Is there some additional logging we could turn on so we could definitively confirm the delivery of the deferred email? 2 Since emails before and after the errors are delivered properly, we believe the issue might be caused by a timeout/network interruption of some sort between the server and the LDAP it is checking for address lookups. Is there a logging parameter we can use to gather more data specifically on this type of connection issue? 3 Because we're still moving into our PostFix environment, the system is set to soft bounce. When we turn that off, if the system has an error of this type, will it still defer the message or will this type of error generate a permanent failure at that time? tia, =lc
