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

Re: Postfix 2.8.x anti anti backscattering settings

Expand Messages
  • Tom Hendrikx
    ... Last time I read ADDRESS_VERIFICATION_README, I noticed that this isn t true: you can route your probes to the final delivery machine while leaving the
    Message 1 of 12 , Apr 18, 2013
    • 0 Attachment
      On 04/19/2013 12:07 AM, Stan Hoeppner wrote:
      > On 4/18/2013 4:26 AM, Mikael Bak wrote:
      >> Hi Josef,
      >>
      >> On 04/18/2013 11:06 AM, Josef Karliak wrote:
      >>> Good morning,
      >>> our outgoing smtp server gets into a backscatter blacklist. When I
      >>> checked my logs, there were only one mailer daemon email to some server
      >>> in the time that is mentioned on the backscatter web.
      >>> In all servers in the way of the email (incoming MX->antispam server->
      >>> our imap server) has unknown_local_recipient_reject_code = 550.
      >>> What else could I do ? There could be one thing - incoming MX accept
      >>> all emails for our domain, he doesn't know our aliases. The mail is send
      >>> to antispam and when antispam wanna sent the email to imap server and
      >>> the target email address doesn't exists, it has 550 error and it is send
      >>> away by our antispam server (it is our outgoing server).
      >>> So, is this all wrong ? We decided to have more servers because of
      >>> loading reasons (we've daily up to 15 000 emails, but there were a 60
      >>> 000 peak)
      >>
      >> You can have "reject_unverified_recipient" on the MX to check the IMAP
      >> server if the email address exists before accepting it.
      >
      >
      > To be clear Josef, reject_unverified_recipient performs recipient
      > address verification via an SMTP RCPT TO test. See:
      > http://www.postfix.org/postconf.5.html#reject_unverified_recipient
      >
      > You state your MX Postfix server relays all mail to the AS appliance
      > which accepts everything regardless of recipient address, which is why
      > you're in trouble currently. Verification queries will be sent to the
      > AS box, so reject_unverified_recipient will not work in your setup.

      Last time I read ADDRESS_VERIFICATION_README, I noticed that this isn't
      true: you can route your probes to the final delivery machine while
      leaving the current delivery mechanism intact:
      http://www.postfix.org/ADDRESS_VERIFICATION_README.html#probe_routing

      >
      > To fix your problem you must have some form of recipient validation at
      > the MX so it only accepts mail for valid mailbox addresses and rejects
      > mail to invalid addresses. You have a couple of options:
      >
      > 1. Export the valid recipient list from the mailbox server to the MX
      > server with one address per line in a text file. Create an access table
      > from this file with OK action. Use check_recipient_access:
      > http://www.postfix.org/postconf.5.html#check_recipient_access
      >
      > 2. Implement an LDAP or mysql database containing valid addresses.
      > This can be used with check_recipient_access, local_recipient_maps,
      > virtual_mailbox_maps, etc. For implementation details of each see:
      > http://www.postfix.org/postconf.5.html
      >
    • Stan Hoeppner
      ... Ahh, you are correct. This may make things much simpler for Josef. http://www.postfix.org/postconf.5.html#address_verify_relayhost But let s note the
      Message 2 of 12 , Apr 19, 2013
      • 0 Attachment
        On 4/19/2013 1:28 AM, Tom Hendrikx wrote:

        > Last time I read ADDRESS_VERIFICATION_README, I noticed that this isn't
        > true: you can route your probes to the final delivery machine while
        > leaving the current delivery mechanism intact:
        > http://www.postfix.org/ADDRESS_VERIFICATION_README.html#probe_routing

        Ahh, you are correct. This may make things much simpler for Josef.

        http://www.postfix.org/postconf.5.html#address_verify_relayhost

        But let's note the caveats:

        Inconsistencies can happen when probe messages don't follow the same
        path as regular mail. For example, a message can be accepted when it
        follows the regular route while an otherwise identical probe message is
        rejected when it follows the forced route. The opposite can happen, too,
        but is less likely.

        --
        Stan
      • Josef Karliak
        Hi, thanks for tip. I may be something missed: In main.cf I ve added: address_verify_relayhost = 19.13.13.11 #ip of my mail server that knows all users
        Message 3 of 12 , May 6 6:08 AM
        • 0 Attachment
          Hi,
          thanks for tip. I may be something missed:
          In main.cf I've added:
          address_verify_relayhost = 19.13.13.11 #ip of my mail server that
          knows all users
          address_verify_sender = master@...

          communication between this incoming server and final imap server
          (between them is antispam/antivir server) is enabled. But in the log I
          see no records, that the server wanted to communicate with imap server
          for verification.
          Did I missed something else ? Ofcourse, postmap of main.cf and
          postfix restart has been done...
          Thanks and best regards
          J.Karliak.

          Cituji Stan Hoeppner <stan@...>:

          > On 4/19/2013 1:28 AM, Tom Hendrikx wrote:
          >
          >> Last time I read ADDRESS_VERIFICATION_README, I noticed that this isn't
          >> true: you can route your probes to the final delivery machine while
          >> leaving the current delivery mechanism intact:
          >> http://www.postfix.org/ADDRESS_VERIFICATION_README.html#probe_routing
          >
          > Ahh, you are correct. This may make things much simpler for Josef.
          >
          > http://www.postfix.org/postconf.5.html#address_verify_relayhost
          >
          > But let's note the caveats:
          >
          > Inconsistencies can happen when probe messages don't follow the same
          > path as regular mail. For example, a message can be accepted when it
          > follows the regular route while an otherwise identical probe message is
          > rejected when it follows the forced route. The opposite can happen, too,
          > but is less likely.
          >
          > --
          > Stan
          >
          >
          >
          >



          --
          Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a
          DomainKeys/DKIM (with ADSP) . Pokud mate problemy s dorucenim emailu,
          zacnete pouzivat metody overeni puvody emailu zminene vyse. Dekuji.
          My domain use SPF (www.openspf.org) and DomainKeys/DKIM (with ADSP)
          policy and check. If you've problem with sending emails to me, start
          using email origin methods mentioned above. Thank you.

          ----------------------------------------------------------------
          This message was sent using IMP, the Internet Messaging Program.
        • Robert Schetterer
          ... at my knwoledge this dont work verify is done over smtp, you may ask for relay permit ,over imap via saslauthd Best Regards MfG Robert Schetterer -- [*]
          Message 4 of 12 , May 6 6:20 AM
          • 0 Attachment
            Am 06.05.2013 15:08, schrieb Josef Karliak:
            > communication between this incoming server and final imap server

            at my knwoledge this dont work verify is done over smtp, you may ask for
            relay permit ,over imap via saslauthd


            Best Regards
            MfG Robert Schetterer

            --
            [*] sys4 AG

            http://sys4.de, +49 (89) 30 90 46 64
            Franziskanerstraße 15, 81669 München

            Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
            Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
            Aufsichtsratsvorsitzender: Florian Kirstein
          • Wietse Venema
            ... This overrides the relayhost setting, which is used ONLY for REMOTE delivery, not LOCAL. It will NEVER be used to find out if a LOCAL email address is
            Message 5 of 12 , May 6 7:06 AM
            • 0 Attachment
              Josef Karliak:
              > Hi,
              > thanks for tip. I may be something missed:
              > In main.cf I've added:
              > address_verify_relayhost = 19.13.13.11 #ip of my mail server that
              > knows all users
              > address_verify_sender = master@...

              This overrides the "relayhost" setting, which is used ONLY for
              REMOTE delivery, not LOCAL. It will NEVER be used to find out
              if a LOCAL email address is valid.

              Which override SHOULD you use? That depends on your Postfix
              configuration.

              Wietse
            • Josef Karliak
              Ohh. So there is only one solution - on mail server generate an alias list that contains aliases and result. Like : chose OK user OK ... ... And in main.cf
              Message 6 of 12 , May 7 12:00 AM
              • 0 Attachment
                Ohh. So there is only one solution - on mail server generate an
                alias list that contains aliases and result. Like :

                chose OK
                user OK
                ...
                ...


                And in main.cf use directive
                smtpd_recipient_restrictions = <other options>,check_recipient_access
                hash:/etc/postfix/alias_list,<other options>


                So we'll generate aliases into a "alias_list" file and scp it from
                email server to incomming smtp and use it in postfix.

                Is it only one option ? Or there are better ? Just asking.

                Thanks very much.
                J.Karliak.

                Cituji Wietse Venema <wietse@...>:

                > Josef Karliak:
                >> Hi,
                >> thanks for tip. I may be something missed:
                >> In main.cf I've added:
                >> address_verify_relayhost = 19.13.13.11 #ip of my mail server that
                >> knows all users
                >> address_verify_sender = master@...
                >
                > This overrides the "relayhost" setting, which is used ONLY for
                > REMOTE delivery, not LOCAL. It will NEVER be used to find out
                > if a LOCAL email address is valid.
                >
                > Which override SHOULD you use? That depends on your Postfix
                > configuration.
                >
                > Wietse
                >



                --
                Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a
                DomainKeys/DKIM (with ADSP) . Pokud mate problemy s dorucenim emailu,
                zacnete pouzivat metody overeni puvody emailu zminene vyse. Dekuji.
                My domain use SPF (www.openspf.org) and DomainKeys/DKIM (with ADSP)
                policy and check. If you've problem with sending emails to me, start
                using email origin methods mentioned above. Thank you.

                ----------------------------------------------------------------
                This message was sent using IMP, the Internet Messaging Program.
              • Robert Schetterer
                ... depending to you r setup some easy way would be main.cf relay_domains = hash:/etc/postfix/relay_domains relay_recipient_maps =
                Message 7 of 12 , May 7 12:47 AM
                • 0 Attachment
                  Am 07.05.2013 09:00, schrieb Josef Karliak:
                  > Ohh. So there is only one solution - on mail server generate an alias
                  > list that contains aliases and result. Like :
                  >
                  > chose OK
                  > user OK
                  > ...
                  > ...
                  >
                  >
                  > And in main.cf use directive
                  > smtpd_recipient_restrictions = <other options>,check_recipient_access
                  > hash:/etc/postfix/alias_list,<other options>

                  depending to "you"r setup some easy way would be

                  main.cf
                  relay_domains = hash:/etc/postfix/relay_domains
                  relay_recipient_maps = hash:/etc/postfix/relay_recipients

                  /etc/postfix/relay_domains

                  mydomain1.test1 OK
                  mydomain2.test2 OK

                  /etc/postfix/relay_recipients

                  user1@...1 OK
                  user2@...1 OK

                  ---so you have to find a sync mech, or edit manual each change----

                  or/and as catch all ( not recommended without verify )

                  @...2 OK


                  with verify

                  main

                  smtpd_recipient_restrictions = ...
                  check_recipient_access hash:/etc/postfix/verify_access
                  ...


                  /etc/postfix/verify_access
                  ...
                  mydomain2.test2 verify_recipient
                  ...

                  main.cf

                  smtpd_restriction_classes = verify_recipient,
                  ...

                  verify_recipient = reject_unverified_recipient
                  address_verify_map = btree:/var/lib/postfix/verify

                  make sure that you have stable con by using smtp verify

                  this is typical used for a backup mx setup !!!

                  so postfix follows dns mx settings, it may combined with transport setting

                  other mehtods may work as well with asking valid recipients via sql,ldap
                  on the orig/main server

                  there are also milters that check orig/main servers

                  i.e

                  http://www.benzedrine.cx/milter-checkrcpt.html

                  did not tested that

                  after all you missed giving more and exact information what setup you
                  are trying to goal, and having recipient list is mandatory these spam
                  days, but its not a global solution against every backscatter, as
                  backscatters may get created for many complex reasons, but mostly as an
                  result of abused mail addresses or missconfigurations by sender servers etc


                  >
                  >
                  > So we'll generate aliases into a "alias_list" file and scp it from
                  > email server to incomming smtp and use it in postfix.
                  >
                  > Is it only one option ? Or there are better ? Just asking.
                  >
                  > Thanks very much.
                  > J.Karliak.
                  >
                  > Cituji Wietse Venema <wietse@...>:
                  >
                  >> Josef Karliak:
                  >>> Hi,
                  >>> thanks for tip. I may be something missed:
                  >>> In main.cf I've added:
                  >>> address_verify_relayhost = 19.13.13.11 #ip of my mail server that
                  >>> knows all users
                  >>> address_verify_sender = master@...
                  >>
                  >> This overrides the "relayhost" setting, which is used ONLY for
                  >> REMOTE delivery, not LOCAL. It will NEVER be used to find out
                  >> if a LOCAL email address is valid.
                  >>
                  >> Which override SHOULD you use? That depends on your Postfix
                  >> configuration.
                  >>
                  >> Wietse
                  >>
                  >
                  >
                  >



                  Best Regards
                  MfG Robert Schetterer

                  --
                  [*] sys4 AG

                  http://sys4.de, +49 (89) 30 90 46 64
                  Franziskanerstraße 15, 81669 München

                  Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
                  Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
                  Aufsichtsratsvorsitzender: Florian Kirstein
                Your message has been successfully submitted and would be delivered to recipients shortly.