On 04/08/2013 10:37 PM, Viktor Dukhovni wrote:
On Mon, Apr 08, 2013 at 09:31:12PM +0200, Jeroen Geilman wrote:
On 04/05/2013 07:13 PM, gbrinker wrote:
Hi, I hope I have a simple request for how and where to look to accomplish
this.
Situation - I was using postfix as a gateway to route incoming mail to two
locations, one a listserv server and second to an exchange server with a
couple of family users internally. I had a hardware crash of the exchange
server and have had to reconfigure postfix to handle the listserv mail which
I have done.
Not an expert I have been reading Ralf's book and found that I had many
errors in the original set up in continuing to use local delivery with
transport maps to forward all mail to the two internal servers. I've changed
set up to a relay domain now and the listserv part is functioning.
The problem I still have is trying to temporarily relay the exchange users
to an external service while I restore the exchange server. I have tried
using transport maps and virtual maps but haven't found the key. I am able
to receive the mail okay but it is held in postfix with messages such as
status=deferred (delivery temporarily suspended: transport is
unavailable)
IFF these messages were already in the queue /before/ you changed
the delivery route, you must re-queue them; queued messages include
their static (i.e. resolved) next-hop transport destination, which
will not change merely because you altered configuration.
Run "postsuper -r ALL" (with capitals) to re-queue.
This is not correct. Only "content_filter" settings are queue-file sticky.
Transport resolution happens each time a message enters the active queue.
If the OP used a content_filter that does not at this time correspond
to a transport in master.cf, a "postsuper -r" may be required.
If the OP has a entries in the transport table that map destinations
to non-existent transports, then a simple update to the transport
table is sufficient.
Ah, em, okay - I misremembered.
Queued messages _do_ contain next-hop information, so if you have, say,
an incoming queue that can't move forward due to slow-to-fail
destinations, this will not be solved automatically when you change the
transport - it requires a re-queue.
The point (which, admittedly, has nothing to do with the OPs use case)
was that transport information is not resolved when /reading from/ the
queue; rather, it is added when /inserting into/ the queue, which
enables per-destination queueing, among other things.
--
J.
