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

Best way to handle a Delivered-To exploit??

Expand Messages
  • Brian Schang
    Hello: I have been using Postfix for many years. I m a hobbiest and have learned a lot by reading this newsgroup. Based on the advice shared here, I have been
    Message 1 of 6 , Nov 4, 2012
      Hello:

      I have been using Postfix for many years. I'm a hobbiest and have
      learned a lot by reading this newsgroup. Based on the advice shared
      here, I have been able to avoid bouncing emails by rejecting them before
      messages are queued. Until recently...

      In the past week, my server has accepted dozens of emails that were not
      deliverable. In all cases the issue has been a mail forwarding loop
      which resulted in the email bouncing. Given that my configuration has
      not changed in many months, I was puzzled. However, a little research
      led me to look into a Delivered-To exploit. I looked at a few of the
      messages in the queue (postcat), and sure enough those messages had a
      Delivered-To header line.

      Now I'm trying to learn how to handle this. I understand that the
      Delivered-To headers are there for a reason and don't want to defeat
      their value. But I also don't want to bounce bogus emails either. I'm
      not sure how to best balance these two.

      What is the best way to handle a problem like this? Right now I'm
      soft_bouncing until I find a more permanent solution. The best I've
      found on the net is to set up a header_check. Is this a good solution?
      If so, are there any tricks in setting this up correctly?

      I'd appreciate any advice.

      Thank you.

      --
      Brian
    • Reindl Harald
      ... we need the log lines from one example message and output of postconf -n to see what happens
      Message 2 of 6 , Nov 5, 2012
        Am 05.11.2012 03:45, schrieb Brian Schang:
        > What is the best way to handle a problem like this? Right now I'm
        > soft_bouncing until I find a more permanent solution. The best I've
        > found on the net is to set up a header_check. Is this a good solution?
        > If so, are there any tricks in setting this up correctly?

        we need the log lines from one example message and output
        of "postconf -n" to see what happens
      • Brian Schang
        Hello: ... Sure. Here is an example from the log file. Note that my email gets sent to amavis and is then re-injected into postfix: Oct 31 06:32:02 server2
        Message 3 of 6 , Nov 5, 2012
          Hello:

          On 11/5/2012 5:18 AM, Reindl Harald wrote:
          > Am 05.11.2012 03:45, schrieb Brian Schang:
          >> What is the best way to handle a problem like this? Right now I'm
          >> soft_bouncing until I find a more permanent solution. The best I've
          >> found on the net is to set up a header_check. Is this a good solution?
          >> If so, are there any tricks in setting this up correctly?
          >
          > we need the log lines from one example message and output
          > of "postconf -n" to see what happens

          Sure.

          Here is an example from the log file. Note that my email gets sent to
          amavis and is then re-injected into postfix:

          Oct 31 06:32:02 server2 postfix/smtpd[4615]: connect from
          crunhmailsapps.info[176.126.168.1]
          Oct 31 06:32:03 server2 postfix/smtpd[4615]: 8671D963AF:
          client=crunhmailsapps.info[176.126.168.1]
          Oct 31 06:32:03 server2 postfix/cleanup[4611]: 8671D963AF:
          message-id=<2683FFB1-5344-2058-3AC6-A2EDCA36C138@...>
          Oct 31 06:32:04 server2 postfix/qmgr[23776]: 8671D963AF:
          from=<SimplyInk@...>, size=6438, nrcpt=1 (queue active)
          Oct 31 06:32:04 server2 postfix/smtpd[4615]: disconnect from
          crunhmailsapps.info[176.126.168.1]
          Oct 31 06:32:05 server2 postfix/smtpd[4629]: connect from
          localhost[127.0.0.1]
          Oct 31 06:32:05 server2 postfix/smtpd[4629]: 9AF30963F8:
          client=crunhmailsapps.info[176.126.168.1]
          Oct 31 06:32:05 server2 postfix/cleanup[4611]: 9AF30963F8:
          message-id=<2683FFB1-5344-2058-3AC6-A2EDCA36C138@...>
          Oct 31 06:32:05 server2 postfix/smtpd[4629]: disconnect from
          localhost[127.0.0.1]
          Oct 31 06:32:05 server2 postfix/qmgr[23776]: 9AF30963F8:
          from=<SimplyInk@...>, size=7045, nrcpt=1 (queue active)
          Oct 31 06:32:05 server2 postfix/smtp[4623]: 8671D963AF:
          to=<jennifer@...>, relay=127.0.0.1[127.0.0.1]:10024, delay=2.5,
          delays=0.86/0/0/1.7, dsn=2.0.0, status=sent (250 2.0.
          0 Ok, id=04180-04, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as
          9AF30963F8)
          Oct 31 06:32:05 server2 postfix/qmgr[23776]: 8671D963AF: removed
          Oct 31 06:32:05 server2 postfix/local[5208]: 9AF30963F8:
          to=<jennifer@...>, relay=local, delay=0.16, delays=0.09/0/0/0.07,
          dsn=5.4.6, status=bounced (mail forwarding loop fo
          r jennifer@...)
          Oct 31 06:32:05 server2 postfix/cleanup[4611]: C2F6896401:
          message-id=<20121031103205.C2F6896401@...>
          Oct 31 06:32:05 server2 postfix/bounce[5423]: 9AF30963F8: sender
          non-delivery notification: C2F6896401
          Oct 31 06:32:05 server2 postfix/qmgr[23776]: C2F6896401: from=<>,
          size=8924, nrcpt=1 (queue active)
          Oct 31 06:32:05 server2 postfix/qmgr[23776]: 9AF30963F8: removed

          Here is my postconf -n output:

          address_verify_map = btree:/var/lib/postfix/verify
          address_verify_negative_cache = yes
          address_verify_negative_expire_time = 6d
          address_verify_negative_refresh_time = 1d
          address_verify_positive_expire_time = 6d
          address_verify_positive_refresh_time = 1d
          alias_database = $alias_maps
          alias_maps = hash:/etc/aliases, hash:/etc/postfix/aliases,
          ldap:/etc/postfix/ldap_aliases.cf
          biff = no
          canonical_maps = hash:/etc/postfix/canonical
          command_directory = /usr/sbin
          config_directory = /etc/postfix
          daemon_directory = /usr/lib/postfix
          data_directory = /var/lib/postfix
          debug_peer_level = 2
          defer_transports =
          delay_warning_time = 4h
          disable_dns_lookups = no
          disable_mime_output_conversion = no
          html_directory = /usr/share/doc/packages/postfix-doc/html
          inet_interfaces = all
          inet_protocols = all
          mail_owner = postfix
          mail_spool_directory = /var/mail
          mailbox_command = /usr/bin/procmail
          mailbox_size_limit = 0
          mailbox_transport =
          mailq_path = /usr/bin/mailq
          manpage_directory = /usr/share/man
          masquerade_classes = envelope_sender, header_sender, header_recipient
          masquerade_domains =
          !facebook.schang.net,!football.schang.net,!linux.schang.net,!lists.schang.net,!wixom.schang.net,schang.net
          masquerade_exceptions = root
          message_size_limit = 20480000
          mydestination =
          $myhostname,localhost.$mydomain,localhost,$mydomain,server2.schang.net
          mydomain = schang.net
          myhostname = s2.schang.net
          mynetworks_style = subnet
          myorigin = $mydomain
          newaliases_path = /usr/bin/newaliases
          notify_classes = resource,software,2bounce
          parent_domain_matches_subdomains = smtpd_access_maps
          queue_directory = /var/spool/postfix
          readme_directory = /usr/share/doc/packages/postfix-doc/README_FILES
          relay_domains = hash:/etc/postfix/relay_domains
          relay_recipient_maps =
          relayhost =
          relocated_maps = hash:/etc/postfix/relocated
          sample_directory = /usr/share/doc/packages/postfix-doc/samples
          sender_canonical_maps = hash:/etc/postfix/sender_canonical
          sendmail_path = /usr/sbin/sendmail
          setgid_group = maildrop
          smtp_sasl_auth_enable = no
          smtp_tls_security_level = none
          smtpd_client_restrictions =
          smtpd_data_restrictions = reject_unauth_pipelining
          smtpd_helo_required = no
          smtpd_helo_restrictions =
          smtpd_recipient_restrictions = hash:/etc/postfix/access
          reject_unknown_reverse_client_hostname reject_non_fqdn_sender
          reject_non_fqdn_recipient reject_unlisted_recipient
          reject_unknown_sender_domain reject_unknown_recipient_domain
          permit_mynetworks reject_unlisted_sender
          reject_non_fqdn_helo_hostname reject_invalid_helo_hostname
          reject_unauth_destination check_recipient_access
          hash:/etc/postfix/recipient_checks reject_rbl_client
          zen.spamhaus.org reject_rbl_client bl.spamcop.net
          smtpd_sasl_auth_enable = no
          smtpd_sasl_path = private/auth
          smtpd_sasl_type = dovecot
          smtpd_sender_restrictions =
          smtpd_tls_CAfile = /etc/postfix/ca.crt
          smtpd_tls_cert_file = /etc/postfix/postfix-crt.pem
          smtpd_tls_fingerprint_digest = sha1
          smtpd_tls_key_file = /etc/postfix/postfix-key.pem
          smtpd_tls_loglevel = 1
          smtpd_tls_received_header = yes
          smtpd_tls_security_level = none
          smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
          smtpd_tls_session_cache_timeout = 3600s
          soft_bounce = yes
          strict_8bitmime = no
          strict_rfc821_envelopes = no
          transport_maps = hash:/etc/postfix/transport
          unknown_local_recipient_reject_code = 550
          unverified_recipient_reject_code = 550
          virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps,
          ldap:/etc/postfix/ldap_virtual_alias.cf
          virtual_gid_maps = hash:/etc/postfix/virtual_gid_maps,
          ldap:/etc/postfix/ldap_virtual_gid.cf
          virtual_mailbox_base = /var/spool/mail
          virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox_maps,
          ldap:/etc/postfix/ldap_virtual_mailbox.cf
          virtual_uid_maps = hash:/etc/postfix/virtual_uid_maps,
          ldap:/etc/postfix/ldap_virtual_uid.cf

          I'd appreciate any insight you can share.

          BTW, if you see anything else in my configuration that looks wrong or
          could be done better, I'd love to learn more.

          Thanks again.

          --
          Brian
        • David Rees
          ... FWIW, I ve been seeing the same thing here. First one I saw was on Oct 23, but seems to be increasing in frequency. -Dave
          Message 4 of 6 , Nov 5, 2012
            On Sun, Nov 4, 2012 at 6:45 PM, Brian Schang <postfix@...> wrote:
            > In the past week, my server has accepted dozens of emails that were not
            > deliverable. In all cases the issue has been a mail forwarding loop
            > which resulted in the email bouncing. Given that my configuration has
            > not changed in many months, I was puzzled. However, a little research
            > led me to look into a Delivered-To exploit. I looked at a few of the
            > messages in the queue (postcat), and sure enough those messages had a
            > Delivered-To header line.

            FWIW, I've been seeing the same thing here. First one I saw was on Oct
            23, but seems to be increasing in frequency.

            -Dave
          • Thomas Harold
            ... Any suggestions on how to handle this in postfix? We re starting to see this with some frequency as well. The only solution that I ve stumbled across in
            Message 5 of 6 , Jun 21, 2013
              On 11/6/2012 12:08 AM, David Rees wrote:
              > On Sun, Nov 4, 2012 at 6:45 PM, Brian Schang <postfix@...> wrote:
              >> In the past week, my server has accepted dozens of emails that were not
              >> deliverable. In all cases the issue has been a mail forwarding loop
              >> which resulted in the email bouncing. Given that my configuration has
              >> not changed in many months, I was puzzled. However, a little research
              >> led me to look into a Delivered-To exploit. I looked at a few of the
              >> messages in the queue (postcat), and sure enough those messages had a
              >> Delivered-To header line.
              >
              > FWIW, I've been seeing the same thing here. First one I saw was on Oct
              > 23, but seems to be increasing in frequency.
              >

              Any suggestions on how to handle this in postfix? We're starting to see
              this with some frequency as well.

              The only solution that I've stumbled across in my web searches is
              documented at:

              http://forum.spamcop.net/forums/index.php?showtopic=10734

              They suggest a "header_checks" of type "pcre" with the following content
              in the file:

              /^Delivered-To: .*/
              REJECT Header Exploit

              But this apparently will also break "forward as attachment" mails unless
              you change something else (and it's not exactly clear, just that
              "nested_header_checks" is involved).
            • Wietse Venema
              Thomas Harold: [ Charset ISO-8859-1 unsupported, converting... ] ... First, there is no need block Delivered-To: addresses with remote domain names. Second,
              Message 6 of 6 , Jun 21, 2013
                Thomas Harold:
                [ Charset ISO-8859-1 unsupported, converting... ]
                > On 11/6/2012 12:08 AM, David Rees wrote:
                > > On Sun, Nov 4, 2012 at 6:45 PM, Brian Schang <postfix@...> wrote:
                > >> In the past week, my server has accepted dozens of emails that were not
                > >> deliverable. In all cases the issue has been a mail forwarding loop
                > >> which resulted in the email bouncing. Given that my configuration has
                > >> not changed in many months, I was puzzled. However, a little research
                > >> led me to look into a Delivered-To exploit. I looked at a few of the
                > >> messages in the queue (postcat), and sure enough those messages had a
                > >> Delivered-To header line.
                > >
                > > FWIW, I've been seeing the same thing here. First one I saw was on Oct
                > > 23, but seems to be increasing in frequency.
                > >
                >
                > Any suggestions on how to handle this in postfix? We're starting to see
                > this with some frequency as well.
                >
                > The only solution that I've stumbled across in my web searches is
                > documented at:
                >
                > http://forum.spamcop.net/forums/index.php?showtopic=10734
                >
                > They suggest a "header_checks" of type "pcre" with the following content
                > in the file:
                >
                > /^Delivered-To: .*/
                > REJECT Header Exploit

                First, there is no need block Delivered-To: addresses with remote
                domain names.

                Second, blocking local Delivered-To: addresses this way would suffer
                from false positive when multiple users have the same email domain.

                To avoid those false positives one would have to compare each
                envelope recipient address against each Delivered-To: address in
                the message header.

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