[pfx] Re: Any way to specify custom string when requesting forced expiration with `postsuper -f`?

Dear Viktor, dear Wietse,


Thank you for your instant reply.

Am 27.03.26 um 15:44 schrieb Wietse Venema via Postfix-users:
> Viktor Dukhovni via Postfix-users:
>> On Fri, Mar 27, 2026 at 09:35:20AM +0100, Paul Menzel via Postfix-users wrote:
>>
>>> In our hold queue, there are sometimes messages, that we want to
>>> return to the sender via forced expiration and pass a reason, like
>>> "SPF failed" or "no unsubscribe link present".
>>>
>>> According to the manual page postsuper(1), there is currently no such
>>> option. Is there another way, or would that need to implemented with a new
>>> switch?
>>
>> There's not much the current postsuper(1) can do here.  The content of
>> the bounce message is based on the bounce logs, which it does not modify.
>>
>> There would need to be new code to rewrite the bounce logs (structured data).
> 
> There may not be a bounce or defer log. A message may be placed on
> hold before any delivery attempt is made (for example, by an smtpd
> access rule, header/body_checks rule, or Milter quarantine action).
> 
> (The contents of a bounce or defer log are sacred, like the original
> message: once Postfix has taken responsibility for delivery, the
> bounce or defer logs must not be lost, and the only safe modifications
> are 'update in place' or 'append'.)
> 
> Alternative A involves a new 'hold reason' record in a bounce or
> defer log. This requires multiple small code changes.
> 
> 1a) When an an smtpd access rule, header/body_checks rule, or Milter
>      quarantine action, places a message on 'hold', it asks the
>      bounce daemon to append a 'hold reason' record to a bounce or
>      defer log.
> 
> 1b) When "postsuper -h" places a message on hold, it locks a bounce
>      or defer log, which can hang the postsuper command, and directly
>      appends a 'hold reason' record (postsuper must work even if
>      Postfix is stopped).
> 
> 2a) When the postsuper command releases a message for
>      normal delivery, it disables the 'hold reason' by updating that
>      record 'in place'.
> 
> 2b) When the postsuper command expires a message, it leaves the
>      'hold reason' record unchanged.
> 
> 3) When the bounce daemon generates a bounce message, it includes
>     the 'hold reason' information if present.
> 
> Alternative B implements 'forced expire with reason' with a new
> postsuper workflow that avoids any changes to bounce/defer logfile
> formats or daemon modifications, but does require structural code
> changes.
> 
> 1) Lock the original message file, which can hang the postsuper
>     command.
> 
> 2) Create a new message with the expiration reason, the contents
>     of bounce and defer logs, and the original message. That is a
>     significant amount of code that would have to be factored out
>     of the bounce daemon, so that it can be reused in the postsuper
>     command.
> 
> 3) If successful, delete the original message and the bounce and
>     defer logs for that message. This behavior currently exists in
>     the bounce daemon and in the queue manager.

Just to avoid any misunderstandings, I mean the message, the sender of 
the force-expired message gets in the “rejection message”, which 
currently is *message is administratively expired*. Sorry, if my comment 
is redundant.


Kind regards,

Paul
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]