Score:1

postfix removing body of bounced messages

in flag

I've noticed for messages that fail to deliver with postfix, the body of the message is removed. Here's an example (real emails replaced with temps):

--5F54EFCA0A.1653443634/MYDOMAIN.COM
Content-Description: Delivery report
Content-Type: message/delivery-status

Reporting-MTA: dns; MYDOMAIN.COM
X-Postfix-Queue-ID: 5F54EFCA0A
X-Postfix-Sender: rfc822; [email protected]
Arrival-Date: Wed, 25 May 2022 01:47:13 +0000 (UTC)

Final-Recipient: rfc822; [email protected]
Original-Recipient: rfc822;[email protected]
Action: delayed
Status: 4.2.1
Remote-MTA: dns; alt1.gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 450-4.2.1 The user you are trying to contact is
    receiving mail at a rate that 450-4.2.1 prevents additional messages from
    being delivered. Please resend your 450-4.2.1 message at a later time. If
    the user is able to receive mail at that 450-4.2.1 time, your message will
    be delivered. For more information, please 450-4.2.1 visit 450 4.2.1
    https://support.google.com/mail/?p=ReceivingRate
    i9-20020a544089000000b0032b06b69e67si10079646oii.275 - gsmtp
Will-Retry-Until: Mon, 30 May 2022 01:47:13 +0000 (UTC)

--5F54EFCA0A.1653443634/MYDOMAIN.COM
Content-Description: Undelivered Message Headers
Content-Type: text/rfc822-headers
Content-Transfer-Encoding: 8bit

Return-Path: <[email protected]>
Received: from [XX.XX.XX.XX] (localhost [127.0.0.1])
    by MYDOMAIN.COM (Postfix) with ESMTP id 5F54EFCA0A
    for <[email protected]>; Wed, 25 May 2022 01:47:13 +0000 (UTC)
Content-Type: multipart/mixed; boundary="===============9070788644322080819=="
MIME-Version: 1.0
Subject: MY SUBJECT
From: [email protected]
To: [email protected]
Message-Id: <[email protected]>
Date: Wed, 25 May 2022 01:47:13 +0000 (UTC)

--5F54EFCA0A.1653443634/MYDOMAIN.COM--
*** HEADER EXTRACTED deferred/3/3E377FD67F ***
named_attribute: encoding=8bit
*** MESSAGE FILE END deferred/3/3E377FD67F ***

I'm wondering are any of the below options possible? Just trying to find a way to avoid losing the original message whenever there's a bounce.

  1. Is there a way to stop postfix from generating this message and instead just place the original message in the deferred queue?
  2. Or, can I change how quickly it removes the original message and replaces it with this one?
  3. Or, is there a way to customize the format to make sure the original message's body content is included?
anx avatar
fr flag
anx
Are you possibly also having a problem with your mail client? The sample you quoted.. should be accompanied by an explanatory message. Did your mail client fail to display that?
Score:1
fr flag
anx

That message is not necessarily undeliverable, just undelivered. It was not accepted by Google yet. It might be, as stated, "at a later time". I think the confusion stems from "bounce" being generally understood as "undeliverable, returned in full".

But this sample is just a notification about a delay, as seen in the subject and Action: delayed. These notifications deliberately only reference the original message: it would additionally later be returned in full if and when it is permanently rejected, or if it is still not delivered at the time specified in Will-Retry-Until.

Just trying to find a way to avoid losing the original message whenever there's a bounce.

The message is not lost.

  1. Postfix has queued this message, as is, including the body. The code provided with X-Postfix-Queue-ID: 5F54EFCA0A is the name of the queue file. Using the postcat(1) command the admin can be retrieve it, including the body - until delivery or return.
  2. You can configure delay_warning_time to warn about delays at a later time (or not at all). Do not disable this feature if you have users who do understand and make use of delay notifications.
  3. Your can configure maximal_queue_lifetime to define how long postfix should attempt to retry delivery when faced it temporary errors. I do not recommend to change this.
in flag
Thanks for the info! I tried your suggestion using `postcat -q 5F54EFCA0A` but it said it doesn't exist. I believe that only works with the Message ID, not the Queue ID. Is there another way to use postcat that can look up via Queue ID and retrieve the body? And I'm aware of your suggestions with 2 and 3, but really my desire isn't to delay or change the liftetime, it's moreso to change postfix's behavior of queueing the message *as is*, rather than this bounce message otherwise I worry the body can't be retrieved. Please tell me there's hope :)
anx avatar
fr flag
anx
It won't be in the queue if it has been delivered meanwhile ;) Find the queue ID in your logs, that will tell you what happened before you checked.
anx avatar
fr flag
anx
@smaili Postfix *does* queue the complete message, and it *can* be retrieved from the queue - until there is no longer a need to, because delivery or return has happened.
in flag
I want to believe it but I've tried everything and have gotten nowhere, including a full grep on the entire OS but nothing. I also did stumble on this: https://serverfault.com/questions/491224/log-headers-contents-of-rejected-messages-via-postfix where it is mentioned that postmaster does truncate the body of bounced messages so at this point I don't think it's possible to retrieve.
anx avatar
fr flag
anx
@smaili Just `grep` alone will not work on certain binary log file storage. E.g. for systemd journal, you want to use `journalctl` to view logs. The notifications for the `postmaster` mailbox are separate from the notification to the sender. Truncation in those happens in the same manner, but for different reasons.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.