On 11 Feb 2004 at 10:27, Michael Johnson wrote about
"Re: [Exim] how to rewrite":
| On Feb 11, 2004, at 1:38 AM, Fred Viles wrote:
|...
| I want to see if I understand this correctly
|
| > # If both Reply-to and List-Post exist, copy original Reply-To
| > # (optional)
| > headers_add = ${if and { \
| > {def:header_reply-to:} {def:header_list-post:}\
| > } {X-was-reply-to: $header_reply-to:} {} }
|
| This is basically saying, headers_add (add a header) if there is a
| header "reply_to" AND "list_post", make a new header called
| "X-was-reply-to" with the information from the original "reply_to"
| header.
Right, if you want to preserve the address(es) from the original
Reply-To that you are about to replace.
| > # If List-Post exists, generate Reply-To from it
| > headers_add = ${if match {$header_list-post:} {\<mailto:(.*)\>} \
| > {reply-to: <$1>} {} }
|
| Again, this is adding a header. It says if there is a "list_post"
| header containing a "mailto" URL, make a "reply_to" header with the
| information in string 1 (a.k.a., the mailto URL).
Right. $1 expands to the part of the first string that matches the
part of the regular expression in the parenthesis (ie the email
address).
Of course, as has already been pointed out, you can't have two
headers_add statements in the same router. The spec mentions
accumulating headers_add and headers_remove statements, but it must
mean from multiple routers/transports.
| > # If both Reply-to and List-Post exist, remove original Reply-To
| > headers_remove = ${if and { \
| > {def:header_reply-to:} {def:header_list-post:}\
| > } {reply-to} fail }
|
| One more time adding a header.
No, this is removing the original Reply-To: header so the one added
above will be the only one.
| If there is a reply_to header AND a
| list_post header, fail the reply_to.
No, fail the expansion if there is NOT both reply-to: and list-post:,
which will mean no action is taken. IOW, remove the existing
reply-to: only if the headers_add above will be adding a new one.
|...
| > The various headers_add and headers_remove are remembered, and are
| > all processed at transport time (removes first).
|
| So this should go in routers?
In the appropriate routers.
|...
| Does "processed at transport time" mean "once it has gone
| through the router" or "do this in the transport section"?
It means that the actual addition and removing of headers requested
here is done by the transport.
- Fred
