Re: specific internal user rerouting to external mail service
- On 04/08/2013 10:37 PM, Viktor Dukhovni wrote:
> On Mon, Apr 08, 2013 at 09:31:12PM +0200, Jeroen Geilman wrote:Ah, em, okay - I misremembered.
>> 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
>>> 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
>> 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.
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.