bounce template question
Which $variables are available in a bounce template?
The second portion of a bounce template consists of message text. As the
above example shows, template message text may contain main.cf
$parameters. Besides the parameters that are defined in main.cf, the
following parameters are treated spe- cially depending on the suffix that
is appended to their name.
I wonder if something like "orig_recipient_domain" is available :)
Similar Topics
| Topic | Started |
|---|---|
| Local mailserver | 57 min 47 sec ago |
| Remove Received: headers | 12 hours 58 min ago |
| Reading mail messages from local files | 14 hours 14 min ago |
| sender and recipient dependend routing in a single postfix engine | 1 day 25 min ago |
| Aggregating/rate-limiting emails | 1 day 2 hours ago |
| reject_unknown_client_hostname light? | 1 day 5 hours ago |
| Relay to another internal server using TLS | 1 day 13 hours ago |
| Postfix rejecting mail when plenty of space | 1 day 15 hours ago |
| Unable to drop mails | 1 day 20 hours ago |
4 comments
Re: bounce template question
Ralf Hildebrandt:
main.cf parameters, including some main.cf parameters with special
suffixes as listed in the bounce(5) manual page.
That is not a main.cf parameter, and it is not a main.cf parameter
with a special suffix as listed in the bounce(5) manual page.
Recipient information would have to be stored into an array (there
can be more than one) of structures that also contain the reason
and other status information. The bounce template would look like
a PHP script. Not sure if it is a good idea to put a PHP processor
into Postfix.
Wietse
Re: bounce template question
* Wietse Venema < ... at porcupine dot org>:
Indeed.
Probably not.
Re: bounce template question
Ralf Hildebrandt:
This is not an insane idea. My original plan was to implement
Postfix as a configuration language, with built-in operators
implemented by what is now libutil, libglobal, etc. But I got
stuck with the prototype C version.
Wietse
Re: bounce template question
We could wrap Python around the (higher level APIs in the) C libraries,
and over time implement new daemons that are Python scripts and offer
a richer configuration language. This need not happen all at once. The
first experiment could be a Python smtpd(8) clone...