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

Re: specific internal user rerouting to external mail service

Expand Messages
  • 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 1 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 2 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.