Expiration of message log feedback

get-help
1

Maybe I am doing things still old school, but the Expiration message doesn’t really give a helpful message if you want to use the expiration message as NDR email. So I watched my logs a few times to be certain I am not rambling , but I registred for one Expired email address in my elastic logs: 10 events:

  • 1x Reception (obviously)
  • 8x TransientFailure in this case mentioning “The recipient’s inbox is out of storage space.”
  • 1x Expiration with the message “Next delivery time PT612237.788971432S > PT432000S”

First of all, this expiration message is not explanative (this is prolly some timestamp), but when sending an ndr report I would also like to mention the reason of expiration. So first of all I think that the message should be something like… “Message expired. Original send out time was . Last failure reason: The recipient’s inbox is out of storage space.”. In general I would say that the Expiration notifications could be more obvious as in stating that it is an expiration mail. The Last failure reason would be a nice to have :slightly_smiling_face:

Since I have scripted an ndr_sendmail script I could do some logic in there, but I thought I would bring it up as a get help request.. I am not sure if this can be mod-ed in Lua on the existing KumoMTA code.

I think my question is more conceptual then that I am really expecting a solution. So can the Expire message be modified and eventually hold the last transient failure message? I did check the documentation and did not get a lot of hits on expiration. Or at least not something that would get me going and not ask this question :slightly_smiling_face:

Kumo version: 2024.06.10.140609.74a0f2be
OS: Debian 12

3

can the Expire message be modified and eventually hold the last transient failure message?

The primary reason that we don’t (and don’t want to) do this because it will have the effect of a 2x increase in the amount of writes for every transient failure, and disk is usually the most constrained resource.

We can improve the wording of the expiration, but fundamentally, the expiration is because the message either has been in the queue for longer than your configured max_age, or would have been in there for longer than that duration at its next attempt.

The reason for the expiration is not directly connected to a prior transient failure. There may never have been a prior transient failure.

We do not keep a history of transient failures in the message metadata because of the storage pressure and size impact.

The logs are where the history is stored, and will have the highest fidelity record of what has happened.

4

Well, I agree on the the impact of the extra lookup/storing of data. But improving the exact wording is already better, since in my case the Expiration message is shown in the bounce of the application. I will for now do a rewrite in my NDR script, but I guess this is a sweet and simple improvement :slightly_smiling_face:
And you are right that the last Transient Failure does not need to be the factual reason for the expire. But I would be happy with a beter wording in future releases. Thanks!