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

Relay hosts + forwarding specific addresses

Expand Messages
  • Jeroen
    Hi there, I m running two postfix mail servers which at the moment only relay and filter for several tld s. What I would like to accomplish is keep relaying,
    Message 1 of 4 , Jul 2, 2011
      Hi there,

      I'm running two postfix mail servers which at the moment only relay
      and filter for several tld's.

      What I would like to accomplish is keep relaying, but have exception
      e-mail addresses that need to be forwarded other accounts.

      For example:
      @... > relay to some host
      foo@... > forward to foobar@...

      From reading the documentation, I think I need to implement
      virtual_maps, but the same documentation also notes that virtual_maps
      and relay_domains should not be used together.

      The configuration is now based on a relay_domains hash file,
      relay_recipients hash file and a transport hash file.
      What's the best way to accomplish my needs? Can someone provide me an example?

      Thanks in advance!

      --
      Jeroen
    • /dev/rob0
      ... BTW, please do not use real domain names as examples. We have example.com and example in all gTLDs as well as many other TLDs, which has been set aside for
      Message 2 of 4 , Jul 2, 2011
        On Sun, Jul 03, 2011 at 12:27:19AM +0200, Jeroen wrote:
        > I'm running two postfix mail servers which at the moment only relay
        > and filter for several tld's.
        >
        > What I would like to accomplish is keep relaying, but have exception
        > e-mail addresses that need to be forwarded other accounts.
        >
        > For example:
        > @... > relay to some host

        BTW, please do not use real domain names as examples. We have
        example.com and example in all gTLDs as well as many other TLDs,
        which has been set aside for examples. Or better yet, when seeking
        help on mail routing issues, use the real names!

        Wildcard forwarding is a very bad idea. You WILL be abused by
        spammers into becoming a backscatter source.

        > foo@... > forward to foobar@...

        Same-envelope forwarding to external sites is also quite likely to
        become a source of problems for you. When you receive and forward
        spam to this address, gmail content filtering will identify it as
        such, and will regard you as the spammer.

        > From reading the documentation, I think I need to implement
        > virtual_maps,

        Did you note in the documentation that virtual_maps was deprecated
        with Postfix 2.0?

        > but the same documentation also notes that virtual_maps
        > and relay_domains should not be used together.

        I do not know what you read. You can indeed use virtual_alias_maps
        with any and all address classes. See:
        http://www.postfix.org/ADDRESS_CLASS_README.html
        http://www.postfix.org/postconf.5.html#virtual_alias_maps
        http://www.postfix.org/VIRTUAL_README.html (might also help)

        > The configuration is now based on a relay_domains hash file,
        > relay_recipients hash file and a transport hash file.

        Good. Sounds right to me. No catchall in relay_recipient_maps means
        that my backscatter warning above is moot in your case.

        > What's the best way to accomplish my needs? Can someone provide
        > me an example?

        virtual_alias_maps = hash:/path/to/your/virtual_alias_maps

        /path/to/your/virtual_alias_maps contains:
        foo@... foobar@...

        Note the problem as mentioned above, but otherwise, it works.
        --
        Offlist mail to this address is discarded unless
        "/dev/rob0" or "not-spam" is in Subject: header
      • Jeroen
        ... Thank you Rob, you are absolutely right, I didn t think of this. Will take this into account next time! ... I just tried the virtual_alias_maps option, and
        Message 3 of 4 , Jul 2, 2011
          On 3 July 2011 01:07, /dev/rob0 <rob0@...> wrote:

          > BTW, please do not use real domain names as examples. We have
          > example.com and example in all gTLDs as well as many other TLDs,
          > which has been set aside for examples. Or better yet, when seeking
          > help on mail routing issues, use the real names!

          Thank you Rob, you are absolutely right, I didn't think of this. Will
          take this into account next time!

          > Wildcard forwarding is a very bad idea. You WILL be abused by
          > spammers into becoming a backscatter source.
          >
          >> foo@... > forward to foobar@...
          >
          > Same-envelope forwarding to external sites is also quite likely to
          > become a source of problems for you. When you receive and forward
          > spam to this address, gmail content filtering will identify it as
          > such, and will regard you as the spammer.

          I just tried the virtual_alias_maps option, and indeed this works.
          Like you said, it does not change the envelop. Gmail does in fact
          accept it, but this might not be the case for other MX's. Is there an
          option for postfix to change the envelop?

          >> From reading the documentation, I think I need to implement
          >> virtual_maps,
          >
          > Did you note in the documentation that virtual_maps was deprecated
          > with Postfix 2.0?

          Actually I didn't; I found the manual page while googling. It might
          have referred to an old version of the manual, or might have got it
          from another source. I searched and read many pages before consulting
          the mailing list.

          > I do not know what you read. You can indeed use virtual_alias_maps
          > with any and all address classes. See:
          >    http://www.postfix.org/ADDRESS_CLASS_README.html
          >    http://www.postfix.org/postconf.5.html#virtual_alias_maps
          >    http://www.postfix.org/VIRTUAL_README.html (might also help)

          Thank you, I will look into this!

          >> The configuration is now based on a relay_domains hash file,
          >> relay_recipients hash file and a transport hash file.
          >
          > Good. Sounds right to me. No catchall in relay_recipient_maps means
          > that my backscatter warning above is moot in your case.

          > virtual_alias_maps = hash:/path/to/your/virtual_alias_maps
          >
          > /path/to/your/virtual_alias_maps contains:
          > foo@...             foobar@...
          >
          > Note the problem as mentioned above, but otherwise, it works.

          Thanks Rob!
        • /dev/rob0
          ... Not exactly, but there are workarounds. Delivery to a script which runs sendmail(1) and sets a sender is one such workaround. For more safety, possibly,
          Message 4 of 4 , Jul 4, 2011
            On Sun, Jul 03, 2011 at 01:44:26AM +0200, Jeroen wrote:
            > On 3 July 2011 01:07, /dev/rob0 <rob0@...> wrote:
            > >> foo@... > forward to foobar@...
            > >
            > > Same-envelope forwarding to external sites is also quite likely
            > > to become a source of problems for you. When you receive and
            > > forward spam to this address, gmail content filtering will
            > > identify it as such, and will regard you as the spammer.
            >
            > I just tried the virtual_alias_maps option, and indeed this works.
            > Like you said, it does not change the envelop. Gmail does in fact
            > accept it, but this might not be the case for other MX's. Is there
            > an option for postfix to change the envelop?

            Not exactly, but there are workarounds. Delivery to a script which
            runs sendmail(1) and sets a sender is one such workaround. For more
            safety, possibly, you could run mutt(1) or Heirloom mailx to MIME-
            encode the message as an attachment. For absolute safety, mutt can
            invoke gpg(1) and encrypt the message.

            Since gmail [so far] is accepting your forwarded mail, it might be
            good enough to employ aggressive pre-acceptance or pre-forwarding
            spam controls. If there is any spam sign, quarantine and do not send
            it on its way.

            DKIM exists to help with this. Whether or not it would help with the
            specific problem, there is no way to know. But DKIM signing of
            outbound mail is a good idea in any case.

            > >> From reading the documentation, I think I need to implement
            > >> virtual_maps,
            > >
            > > Did you note in the documentation that virtual_maps was
            > > deprecated with Postfix 2.0?
            >
            > Actually I didn't; I found the manual page while googling. It might
            > have referred to an old version of the manual, or might have got it
            > from another source. I searched and read many pages before
            > consulting the mailing list.

            With most free software projects, and especially with Postfix, it's a
            good idea to check the project's own documentation before Google. And
            when you do come down to the need to Google for Postfix, start with
            searches of the various online archives of this mailing list.

            Most packages of Postfix from third-party distributors should include
            the complete documentation. I recommend to consult the local copy
            before the online versions, because features are added, and you must
            read carefully to see if a feature was not available in your version.

            If installing from source, be sure to set html_directory. If you're
            going to do much with Postfix, bookmark that in your browser. :)
            --
            Offlist mail to this address is discarded unless
            "/dev/rob0" or "not-spam" is in Subject: header
          Your message has been successfully submitted and would be delivered to recipients shortly.