Using Wietse's first approach (adding a custom id to the MAIL FROM address as an extension) I have tried to output the sender's address in the same line of the mail.log as the bounce message. I believe I would need to change the global/log_adhoc.c (e.g. line 109 in 2.9.4) to do so but I cannot access the sender there. Is there a way to access the initial sender from the log_adhoc void? Maybe through the RECIPIENT object: RECIPIENT->QMGR_QUEUE->QMGR_ENTRY_LIST->QMGR_ENTRY->QMGR_MESSAGE->sender
I know it sounds awefully complicated but I really need a custom id in the same line as the bounce message. Alternatively, if there is another location where I access and ouput the sender, the recipient, the status=bounced (reason) and the dsn that would also work. Any help is greatly appreciated. Best, Steffen -----Ursprüngliche Nachricht----- Von: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] Im Auftrag von Wietse Venema Gesendet: Donnerstag, 4. Oktober 2012 14:26 An: Postfix users Betreff: Re: AW: How to change queue id? Steffen Schebesta: > If that doesn't work though then maybe I could work around this > problem. I thought about adding the message-id to the bounce message > but that probably Postfix has lots of options to identify a returned message. 1) You can encode the unique identifier in the envelope sender address (as an address extension). This works even when mail is returned by a remote MTA. 2) Your unique Message ID is already returned in the bounce message. See RFC 3462. This may or may not work for mail that is returned by a remote MTA. 3) You can specify your own unique ENVELOPE ID via SMTP (see RFC 3461) or via the Postfix "sendmail -V" option. This ENVELOPE ID is also returned in the bounce message. See RFC 3464. This works only if all MTAs in the forward path implement RFC 3461. I suggest that you study the many RFCs and non-RFC features that Postfix already implements, before tinkering with internals. But first, as Stan mentioned, you should describe your problem, instead of your proposed solutions. There are likely better solutions that already exist. I already mentioned three of them. Wietse
