Loading ...
Sorry, an error occurred while loading the content.

Re: specific internal user rerouting to external mail service

Expand Messages
  • Jeroen Geilman
    ... 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
    Message 1 of 4 , Apr 10, 2013
      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.

    Your message has been successfully submitted and would be delivered to recipients shortly.