On Feb 11, 2004, at 1:38 AM, Fred Viles wrote:
> If you want to override an existing Reply-To:, if I read the spec
> correctly you can also do it in the router with headers_add and
> headers_remove (untested):
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.
> # 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).
> # 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. If there is a reply_to header AND a
list_post header, fail the reply_to. I'm not really certain how the
fail works here. I guess it either ignores it and doesn't forward that
information through, or it removes it in a different manner.
> The various headers_add and headers_remove are remembered, and are
> all processed at transport time (removes first).
So this should go in routers? transports? rewrite? I'm confused. At
the beginning of the message, you wrote that it should go in the router
section. Does "processed at transport time" mean "once it has gone
through the router" or "do this in the transport section"?
-Michael
---------------------------------------
Who is the happiest of men? He who values the merits of others, and in
their pleasure takes joy, even as though t'were his own.
- Johann von Goethe
