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

Re: specific internal user rerouting to external mail service

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

      > I would much appreciate suggestions on how I should go about this as I
      > suspect it is simple but I'm a bit frazzled by my efforts.
      > Thanks much, Gary

      As simple as above.


      --
      J.
    • Viktor Dukhovni
      ... This is not correct. Only content_filter settings are queue-file sticky. Transport resolution happens each time a message enters the active queue. If
      Message 2 of 4 , Apr 8, 2013
      • 0 Attachment
        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.

        --
        Viktor.
      • 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 3 of 4 , Apr 10, 2013
        • 0 Attachment
          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.
        Your message has been successfully submitted and would be delivered to recipients shortly.