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

Re: disable ipv6 when sending to gmail ?

Expand Messages
  • Wietse Venema
    ... That is incorrect. ... Of course. Why can tt you follow instructions? Wietse
    Message 1 of 24 , Aug 21 6:15 AM
    • 0 Attachment
      Nicolas KOWALSKI:
      > On Wed, Aug 21, 2013 at 06:44:55AM -0400, Wietse Venema wrote:
      > > Argh. You need to replace the 5.X.X.
      > >
      > > This pattern replaces both fives just to be sure.
      > >
      > > /^5(\d\d )5(.*your:ipv6:addr:here.*)/ 4${1}4$2
      >
      > I used this one ('-' instead of space):

      That is incorrect.

      > /^5(\d\d-)5(.*2a01:e35:8ae7:65f0::2.*)/ 4${1}4${2}
      >
      >
      > But even with a return code rewritten as 450-4.X.Y, it bounces:

      Of course. Why can'tt you follow instructions?

      Wietse
    • Nicolas KOWALSKI
      ... Sorry, I was confused by the error message, forgetting about the last line of the server reply. So, I corrected it to be exactly as you wrote: /^5( d d
      Message 2 of 24 , Aug 21 7:43 AM
      • 0 Attachment
        On Wed, Aug 21, 2013 at 09:15:46AM -0400, Wietse Venema wrote:
        > Nicolas KOWALSKI:
        > > On Wed, Aug 21, 2013 at 06:44:55AM -0400, Wietse Venema wrote:
        > > > Argh. You need to replace the 5.X.X.
        > > >
        > > > This pattern replaces both fives just to be sure.
        > > >
        > > > /^5(\d\d )5(.*your:ipv6:addr:here.*)/ 4${1}4$2
        > >
        > > I used this one ('-' instead of space):
        >
        > That is incorrect.

        Sorry, I was confused by the error message, forgetting about the last
        line of the server reply.

        So, I corrected it to be exactly as you wrote:

        /^5(\d\d )5(.*2a01:e35:8ae7:65f0::2.*)/ 4${1}4$2


        In the logs, the reply was then not filtered:

        Aug 21 15:29:18 petole postfix/smtp[18007]: Trusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:400c:c03::1b]:25: TLSv1.2 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
        Aug 21 15:29:19 petole postfix/smtp[18007]: D424D40555: to=<nicolas.kowalski@...>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c03::1b]:25, delay=1.4, delays=0.04/0.07/0.7/0.57, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[2a00:1450:400c:c03::1b] said: 550-5.7.1 [2a01:e35:8ae7:65f0::2 16] The sender does not meet basic ipv6 550-5.7.1 sending guidelines of authentication and rdns resolution of sending 550-5.7.1 ip. Please review 550 5.7.1 https://support.google.com/mail/answer/81126for more information. gp4si4464911wib.46 - gsmtp (in reply to end of DATA command))


        By testing the mail sending manually, I saw that the "550 5.7.1 ..."
        line, was not containing the IPv6 address:

        $ telnet 2a00:1450:400c:c03::1a 25
        Trying 2a00:1450:400c:c03::1a...
        Connected to 2a00:1450:400c:c03::1a.
        Escape character is '^]'.
        220 mx.google.com ESMTP pf5si4330259wjb.13 - gsmtp
        ehlo petole.demisel.net
        250-mx.google.com at your service, [2a01:e35:8ae7:65f0::2]
        250-SIZE 35882577
        250-8BITMIME
        250-STARTTLS
        250 ENHANCEDSTATUSCODES
        mail from: <root@...>
        250 2.1.0 OK pf5si4330259wjb.13 - gsmtp
        rcpt to: <nicolas.kowalski@...>
        250 2.1.5 OK pf5si4330259wjb.13 - gsmtp
        data
        354 Go ahead pf5si4330259wjb.13 - gsmtp
        from: <root@...>
        to: <nicolas.kowalski@...>
        subject: test

        test
      • Nicolas KOWALSKI
        ... Sorry, I was confused by the error message, forgetting about the last line of the server reply. So, I corrected it to be exactly as you wrote: /^5( d d
        Message 3 of 24 , Aug 21 7:50 AM
        • 0 Attachment
          On Wed, Aug 21, 2013 at 09:15:46AM -0400, Wietse Venema wrote:
          > Nicolas KOWALSKI:
          > > On Wed, Aug 21, 2013 at 06:44:55AM -0400, Wietse Venema wrote:
          > > > Argh. You need to replace the 5.X.X.
          > > >
          > > > This pattern replaces both fives just to be sure.
          > > >
          > > > /^5(\d\d )5(.*your:ipv6:addr:here.*)/ 4${1}4$2
          > >
          > > I used this one ('-' instead of space):
          >
          > That is incorrect.

          Sorry, I was confused by the error message, forgetting about the last
          line of the server reply.

          So, I corrected it to be exactly as you wrote:

          /^5(\d\d )5(.*2a01:e35:8ae7:65f0::2.*)/ 4${1}4$2


          In the logs, the reply was then not filtered:

          Aug 21 15:29:18 petole postfix/smtp[18007]: Trusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:400c:c03::1b]:25: TLSv1.2 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
          Aug 21 15:29:19 petole postfix/smtp[18007]: D424D40555: to=<nicolas.kowalski@...>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c03::1b]:25, delay=1.4, delays=0.04/0.07/0.7/0.57, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[2a00:1450:400c:c03::1b] said: 550-5.7.1 [2a01:e35:8ae7:65f0::2 16] The sender does not meet basic ipv6 550-5.7.1 sending guidelines of authentication and rdns resolution of sending 550-5.7.1 ip. Please review 550 5.7.1 https://support.google.com/mail/answer/81126for more information. gp4si4464911wib.46 - gsmtp (in reply to end of DATA command))


          By testing the mail sending manually, I saw that the "550 5.7.1 ..."
          line, was not containing the IPv6 address:

          $ telnet 2a00:1450:400c:c03::1a 25
          Trying 2a00:1450:400c:c03::1a...
          Connected to 2a00:1450:400c:c03::1a.
          Escape character is '^]'.
          220 mx.google.com ESMTP pf5si4330259wjb.13 - gsmtp
          ehlo petole.demisel.net
          250-mx.google.com at your service, [2a01:e35:8ae7:65f0::2]
          250-SIZE 35882577
          250-8BITMIME
          250-STARTTLS
          250 ENHANCEDSTATUSCODES
          mail from: <root@...>
          250 2.1.0 OK pf5si4330259wjb.13 - gsmtp
          rcpt to: <nicolas.kowalski@...>
          250 2.1.5 OK pf5si4330259wjb.13 - gsmtp
          data
          354 Go ahead pf5si4330259wjb.13 - gsmtp
          from: <root@...>
          to: <nicolas.kowalski@...>
          subject: test

          test
          ...
          550-5.7.1 [2a01:e35:8ae7:65f0::2 16] The sender does not meet basic ipv6
          550-5.7.1 sending guidelines of authentication and rdns resolution of sending
          550-5.7.1 ip. Please review
          550 5.7.1 https://support.google.com/mail/answer/81126for more information. pf5si4330259wjb.13 - gsmtp


          Now I have put this in the smtp_reply_filter table:

          /^5(\d\d )5(.*support.google.com\/mail\/answer\/81126.*)/ 4${1}4$2


          It works well:

          Aug 21 16:29:26 petole postfix/smtp[19900]: Trusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:400c:c03::1b]:25: TLSv1.2 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
          Aug 21 16:29:27 petole postfix/smtp[19900]: gmail-smtp-in.l.google.com[2a00:1450:400c:c03::1b]:25: replacing server reply "550 5.7.1 https://support.google.com/mail/answer/81126for more information. x5si3345140wjx.49 - gsmtp" with "450 4.7.1 https://support.google.com/mail/answer/81126for more information. x5si3345140wjx.49 - gsmtp"
          Aug 21 16:29:27 petole postfix/smtp[19900]: 0EFB640557: host gmail-smtp-in.l.google.com[2a00:1450:400c:c03::1b] said: 550-5.7.1 [2a01:e35:8ae7:65f0::2 16] The sender does not meet basic ipv6 550-5.7.1 sending guidelines of authentication and rdns resolution of sending 550-5.7.1 ip. Please review 450 4.7.1 https://support.google.com/mail/answer/81126for more information. x5si3345140wjx.49 - gsmtp (in reply to end of DATA command)
          Aug 21 16:29:27 petole postfix/smtp[19900]: Trusted TLS connection established to gmail-smtp-in.l.google.com[173.194.66.26]:25: TLSv1.2 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
          Aug 21 16:29:28 petole postfix/smtp[19900]: 0EFB640557: to=<nicolas.kowalski@...>, relay=gmail-smtp-in.l.google.com[173.194.66.26]:25, delay=2, delays=0.05/0.07/1.5/0.32, dsn=2.0.0, status=sent (250 2.0.0 OK 1377095368 w8si10322842wib.85 - gsmtp)



          Thanks a lot for your help,
          --
          Nicolas
        • Wietse Venema
          ... You made a mistake. With this: % cat /tmp/x.pcre /^5( d d )5(.*)/ 4${1}4$2 % postmap -q - pcre:/tmp/x.pcre 550 5.7.1 whatever 550 5.7.1 whatever
          Message 4 of 24 , Aug 21 10:32 AM
          • 0 Attachment
            Nicolas KOWALSKI:
            > On Wed, Aug 21, 2013 at 09:15:46AM -0400, Wietse Venema wrote:
            > > Nicolas KOWALSKI:
            > > > On Wed, Aug 21, 2013 at 06:44:55AM -0400, Wietse Venema wrote:
            > > > > Argh. You need to replace the 5.X.X.
            > > > >
            > > > > This pattern replaces both fives just to be sure.
            > > > >
            > > > > /^5(\d\d )5(.*your:ipv6:addr:here.*)/ 4${1}4$2
            > > >
            > > > I used this one ('-' instead of space):
            > >
            > > That is incorrect.
            >
            > Sorry, I was confused by the error message, forgetting about the last
            > line of the server reply.
            >
            > So, I corrected it to be exactly as you wrote:
            >
            > /^5(\d\d )5(.*2a01:e35:8ae7:65f0::2.*)/ 4${1}4$2
            >
            >
            > In the logs, the reply was then not filtered:
            >
            > Aug 21 15:29:18 petole postfix/smtp[18007]: Trusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:400c:c03::1b]:25: TLSv1.2 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)

            You made a mistake.

            With this:

            % cat /tmp/x.pcre
            /^5(\d\d )5(.*)/ 4${1}4$2

            % postmap -q - pcre:/tmp/x.pcre
            550 5.7.1 whatever
            550 5.7.1 whatever 450 4.7.1 whatever

            So you erred in your text inside the second ().

            Wietse
          • HQJaTu
            Google chose to change the wording in their 550 error. 550-5.7.1 [2001:-my-IPv6-address-here- 16] Our system has detected 550-5.7.1 that this message does
            Message 5 of 24 , Oct 17, 2013
            • 0 Attachment
              Google chose to change the wording in their 550 error.
              550-5.7.1 [2001:-my-IPv6-address-here- 16] Our system has detected
              550-5.7.1 that this message does not meet IPv6 sending guidelines regarding
              PTR
              550-5.7.1 records and authentication. Please review
              550-5.7.1 https://support.google.com/mail/?p=ipv6_authentication_error for
              more
              550 5.7.1 information. dj7si12191118bkc.191 - gsmtp (in reply to end of DATA
              command))
              My smtp_reply_filter is:
              /^5(\d\d )5(.*information. \S+ - gsmtp.*)/ 4${1}4$2
              That seems to do the job of luring Postfix for doing a second attempt via
              IPv4. Now Google should be happy, they get 2 attempts instead of one.
              Anyways, my users are happy. Their mail gets delivered. See my blog post
              <http://blog.hqcodeshop.fi/archives/122-Fixing-Googles-new-IPv6-mail-policy-with-Postfix.html>
              about my fix.



              --
              View this message in context: http://postfix.1071664.n5.nabble.com/disable-ipv6-when-sending-to-gmail-tp60672p62278.html
              Sent from the Postfix Users mailing list archive at Nabble.com.
            • Dominik George
              Hi, that all sounds cool, but ... ... could you please fix that to point to something more helpful than an empty, albeit nicely decorated, page so I can test
              Message 6 of 24 , Oct 17, 2013
              • 0 Attachment
                Hi,

                that all sounds cool, but ...

                > Anyways, my users are happy. Their mail gets delivered. See my blog
                > post
                > <http://blog.hqcodeshop.fi/archives/122-Fixing-Googles-new-IPv6-mail-policy-with-Postfix.html>
                > about my fix.

                could you please fix that to point to something more helpful than an
                empty, albeit nicely decorated, page so I can test it ☺?

                Cheers,
                Nik

                --
                * concerning Mozilla code leaking assertion failures to tty without D-BUS *
                <mirabilos> That means, D-BUS is a tool that makes software look better
                than it actually is.

                PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296
              • HQJaTu
                Sorry, my bad. I dropped the ball on publish settings, the writing was not visible for general public to see. Apologies. Anyway, I realized that since I
                Message 7 of 24 , Oct 17, 2013
                • 0 Attachment
                  Sorry, my bad. I dropped the ball on publish settings, the writing was not
                  visible for general public to see. Apologies.

                  Anyway, I realized that since I replied to an existing conversation on
                  Nabble.com, it is impossible for a person not seeing the entire thread to
                  get my idea. The thread can be seen here:
                  http://postfix.1071664.n5.nabble.com/disable-ipv6-when-sending-to-gmail-td60672.html

                  It is Wietse's idea to re-write the response code into temporary, so that
                  Postfix will attempt delivery again. My fix was merely an enhancement to an
                  existing solution to compensate the changes on Google's end. To repeat:

                  Add a reply filter into main.cf:
                  smtp_reply_filter = pcre:/etc/postfix/smtp_reply_filter

                  Re-write IPv6 complaints:
                  /^5(\d\d )5(.*information. \S+ - gsmtp.*)/ 4${1}4$2

                  That re-write regexp will fail again, when Google changes their error
                  message.

                  Regards,
                  Jari Turkia



                  --
                  View this message in context: http://postfix.1071664.n5.nabble.com/disable-ipv6-when-sending-to-gmail-tp60672p62319.html
                  Sent from the Postfix Users mailing list archive at Nabble.com.
                • Mark Martinec
                  ... Thanks for this information! That page now clearly states: Additional guidelines for IPv6 The sending IP must have a PTR record (i.e., a reverse DNS of the
                  Message 8 of 24 , Oct 18, 2013
                  • 0 Attachment
                    HQJaTu writes:
                    > Google chose to change the wording in their 550 error.

                    > 550-5.7.1 [2001:-my-IPv6-address-here-16] Our system has detected
                    > 550-5.7.1 that this message does not meet IPv6 sending guidelines regarding
                    > 550-5.7.1 PTR records and authentication. Please review
                    > 550-5.7.1 https://support.google.com/mail/?p=ipv6_authentication_error
                    > 550 5.7.1 for more information. dj7si12191118bkc.191 - gsmtp

                    Thanks for this information!
                    That page now clearly states:

                    Additional guidelines for IPv6
                    The sending IP must have a PTR record (i.e., a reverse DNS of the sending
                    IP) and it should match the IP obtained via the forward DNS resolution of
                    the hostname specified in the PTR record. Otherwise, mail will be marked
                    as spam or possibly rejected.
                    The sending domain should pass either SPF check or DKIM check. Otherwise,
                    mail might be marked as spam.

                    IMO, instead of working on workarounds, people's efforts would be better spent
                    on setting up their DKIM and/or SPF, reverse DNS mapping, and making sure that
                    postfix only binds to an intentionally configured IPv6 address (not on SLAAC
                    or 'privacy extensions' random address).

                    Mark
                  • Dominik George
                    ... Hash: SHA512 ... I took care of all of this, and I do habe working SPF, DKIM and DNS for IPv6 and did so forever. Yet it does not make Google accept my
                    Message 9 of 24 , Oct 18, 2013
                    • 0 Attachment
                      -----BEGIN PGP SIGNED MESSAGE-----
                      Hash: SHA512

                      Mark Martinec <Mark.Martinec+postfix@...> schrieb:
                      >IMO, instead of working on workarounds, people's efforts would be
                      >better spent
                      >on setting up their DKIM and/or SPF, reverse DNS mapping, and making
                      >sure that
                      >postfix only binds to an intentionally configured IPv6 address (not on
                      >SLAAC
                      >or 'privacy extensions' random address).


                      I took care of all of this, and I do habe working SPF, DKIM and DNS for IPv6 and did so forever. Yet it does not make Google accept my mail.

                      - -nik
                      -----BEGIN PGP SIGNATURE-----
                      Version: APG v1.0.8-fdroid

                      iQFNBAEBCgA3BQJSYVpqMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p
                      a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJecgB/49OAPz9vrgBq+b0WsyyxAa
                      Q1GB78JRnzfR9O7xrwnM684SsPrPu+vf7ZvGLOqUnR4YCCEQyTfF41IXck/CEasJ
                      HjUYh1s9Bd9aoD+lmgAS3XnYS00IHz06Tnju/HKSsXkVKg+4Xd8aUeSM3AFNH4Ww
                      x2c8ZTCOruCxRm45vrNysXWVngL3Dor4bP6hC+fLQe8El7Zx8XA5JhVMzNnpL4ya
                      cGQKuCKWX0F69qjZ+FgsjFh9lLHeNWPfcWIBXxsrcaUtNFXyVE2CWJkkEQduDFwF
                      1XVF0cbpBS8EcqZXKcoYsPO2S5yFJHerQWUtzKESR5PigBoxIT8FxHV4xcVS2ATh
                      =Xdq8
                      -----END PGP SIGNATURE-----
                    • lists@rhsoft.net
                      ... what about giving the real IP and output of ifconfig to give others the chance to verify this for you instead say i took care * sender address *
                      Message 10 of 24 , Oct 18, 2013
                      • 0 Attachment
                        Am 18.10.2013 17:57, schrieb Dominik George:
                        > Mark Martinec <Mark.Martinec+postfix@...> schrieb:
                        >> IMO, instead of working on workarounds, people's efforts would be
                        >> better spent
                        >> on setting up their DKIM and/or SPF, reverse DNS mapping, and making
                        >> sure that
                        >> postfix only binds to an intentionally configured IPv6 address (not on
                        >> SLAAC
                        >> or 'privacy extensions' random address).
                        >
                        > I took care of all of this, and I do habe working SPF, DKIM and DNS for IPv6 and did so forever.
                        > Yet it does not make Google accept my mail.

                        what about giving the real IP and output of "ifconfig" to give others
                        the chance to verify this for you instead say "i took care"

                        * sender address
                        * configuration
                        * real IP adress to verify PTR that *only 1* PTR exists and matchs
                        * verify that *all* matchs

                        most times if people say "i have done that all" they made a small
                        mistake which they do not face independent how often you verufy it
                        by yourself
                      • Dominik George
                        Hi, ... Dominik George ... alias_database = hash:/etc/aliases alias_maps = ldap:/etc/postfix/ldap-group-aliases.conf, hash:/etc/aliases,
                        Message 11 of 24 , Oct 18, 2013
                        • 0 Attachment
                          Hi,

                          > what about giving the real IP and output of "ifconfig" to give others
                          > the chance to verify this for you instead say "i took care"

                          ok, here we go:

                          > * sender address

                          Dominik George <nik@...>

                          > * configuration

                          alias_database = hash:/etc/aliases
                          alias_maps = ldap:/etc/postfix/ldap-group-aliases.conf, hash:/etc/aliases, ldap:/etc/postfix/ldap-routing.conf
                          append_dot_mydomain = no
                          biff = no
                          broken_sasl_auth_clients = yes
                          canonical_maps = hash:/etc/postfix/canonical
                          config_directory = /etc/postfix
                          inet_interfaces = all
                          inet_protocols = all
                          local_header_rewrite_clients = static:all
                          mailbox_command = /usr/lib/dovecot/deliver
                          mailbox_size_limit = 0
                          mailman_destination_recipient_limit = 1
                          message_size_limit = 204800000
                          mydestination = naturalnet.de, shore.naturalnet.de, localhost.naturalnet.de, localhost
                          myhostname = shore.naturalnet.de
                          mynetworks = 172.29.10.0/24 172.29.12.0/24 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 hash:/etc/postfix/mynetworks
                          myorigin = /etc/mailname
                          non_smtpd_milters = inet:localhost:8891
                          postscreen_access_list = permit_mynetworks
                          postscreen_dnsbl_action = enforce
                          postscreen_dnsbl_sites = zen.spamhaus.org*2 bl.spamcop.net*1 b.barracudacentral.org*1
                          postscreen_dnsbl_threshold = 2
                          readme_directory = no
                          recipient_delimiter = +
                          relay_domains = fax.naturalnet.de, speech.naturalnet.de
                          relayhost =
                          smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
                          smtp_use_tls = yes
                          smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
                          smtpd_milters = inet:localhost:8891
                          smtpd_proxy_filter = 127.0.0.1:10024
                          smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_helo_hostname, reject_unauth_destination, check_policy_service inet:127.0.0.1:12525
                          smtpd_relay_restrictions =
                          smtpd_sasl_auth_enable = yes
                          smtpd_sasl_authenticated_header = yes
                          smtpd_sasl_path = private/auth
                          smtpd_sasl_security_options = noanonymous
                          smtpd_sasl_type = dovecot
                          smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_sender_domain
                          smtpd_tls_cert_file = /etc/ssl/private/shore_cert.pem
                          smtpd_tls_key_file = /etc/ssl/private/shore_privatekey.pem
                          smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
                          smtpd_use_tls = yes
                          transport_maps = hash:/etc/postfix/transport
                          virtual_alias_domains = ldap:/etc/postfix/ldap-domains.conf
                          virtual_alias_maps = hash:/etc/postfix/virtual-aliases, ldap:/etc/postfix/ldap-aliases.conf

                          > * real IP adress to verify PTR that *only 1* PTR exists and matchs

                          2a00:1828:2000:239::2

                          $ host 2a00:1828:2000:239::2
                          2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.3.2.0.0.0.0.2.8.2.8.1.0.0.a.2.ip6.arpa domain name pointer shore.naturalnet.de.

                          $ host shore.naturalnet.de
                          shore.naturalnet.de has address 89.238.64.147
                          shore.naturalnet.de has IPv6 address 2a00:1828:2000:239::2

                          > * verify that *all* matchs

                          I do not see what should not match ;).

                          Further:

                          $ dig naturalnet.de MX
                          ;; ANSWER SECTION:
                          naturalnet.de. 3600 IN MX 30 shore.naturalnet.de.

                          $ dig shore.naturalnet.de AAAA
                          ;; ANSWER SECTION:
                          shore.naturalnet.de. 3521 IN AAAA 2a00:1828:2000:239::2

                          $ dig naturalnet.de TXT
                          ;; ANSWER SECTION:
                          naturalnet.de. 3591 IN TXT "v=spf1 mx ~all"

                          # ifconfig eth0
                          eth0 Link encap:Ethernet Hardware Adresse 00:1d:7d:95:b1:17
                          inet Adresse:89.238.64.147 Bcast:89.238.64.255 Maske:255.255.255.0
                          inet6-Adresse: 2a00:1828:2000:239::2/64 Gültigkeitsbereich:Global
                          inet6-Adresse: fe80::21d:7dff:fe95:b117/64 Gültigkeitsbereich:Verbindung
                          UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
                          RX packets:1257801434 errors:1277 dropped:73460221 overruns:1258 frame:128
                          TX packets:363061519 errors:0 dropped:0 overruns:0 carrier:0
                          Kollisionen:0 Sendewarteschlangenlänge:1000
                          RX bytes:568012008739 (529.0 GiB) TX bytes:262260488983 (244.2 GiB)


                          > most times if people say "i have done that all" they made a small
                          > mistake which they do not face independent how often you verufy it
                          > by yourself

                          Ok, I believe that. But do you see anything I missed?

                          Cheers,
                          Nik

                          --
                          * mirabilos is handling my post-1990 smartphone *
                          <mirabilos> Aaah, it vibrates! Wherefore art thou, demonic device??

                          PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296
                        • lists@rhsoft.net
                          ... if i would be you i would *not* use v=spf1 mx ~all until we switched to declare ip-addresses in SPF i noted repeatly negative results from several
                          Message 12 of 24 , Oct 18, 2013
                          • 0 Attachment
                            Am 18.10.2013 23:52, schrieb Dominik George:
                            > $ host 2a00:1828:2000:239::2
                            > 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.3.2.0.0.0.0.2.8.2.8.1.0.0.a.2.ip6.arpa domain name pointer shore.naturalnet.de.
                            >
                            > $ host shore.naturalnet.de
                            > shore.naturalnet.de has address 89.238.64.147
                            > shore.naturalnet.de has IPv6 address 2a00:1828:2000:239::2
                            >
                            >> * verify that *all* matchs
                            >
                            > I do not see what should not match ;).
                            >
                            > Further:
                            >
                            > $ dig naturalnet.de MX
                            > ;; ANSWER SECTION:
                            > naturalnet.de. 3600 IN MX 30 shore.naturalnet.de.
                            >
                            > $ dig shore.naturalnet.de AAAA
                            > ;; ANSWER SECTION:
                            > shore.naturalnet.de. 3521 IN AAAA 2a00:1828:2000:239::2
                            >
                            > $ dig naturalnet.de TXT
                            > ;; ANSWER SECTION:
                            > naturalnet.de. 3591 IN TXT "v=spf1 mx ~all"

                            if i would be you i would *not* use "v=spf1 mx ~all"

                            until we switched to declare ip-addresses in SPF i noted repeatly
                            negative results from several testing tools online, maybe caused
                            by the additional ookups needed for MX to A/AAA and IP

                            after switch to ipv4:<network> i *never* faced any fasle positive

                            rhsoft.net. 86400 IN TXT "v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 ip4:84.113.45.179 -all"
                            rhsoft.net. 86400 IN SPF "v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 ip4:84.113.45.179 -all"

                            here you go for ipv6

                            http://www.openspf.org/SPF_Record_Syntax#ip6
                          • Dominik George
                            Hi, ... If I were [...] ... ... Jeez, I don t believe it. The problem is that the mx mechanism simply only enumerates A records of MXs. That s broken ...
                            Message 13 of 24 , Oct 18, 2013
                            • 0 Attachment
                              Hi,

                              > if i would be you i would *not* use "v=spf1 mx ~all"

                              If I were [...] ...

                              > here you go for ipv6
                              >
                              > http://www.openspf.org/SPF_Record_Syntax#ip6

                              Jeez, I don't believe it. The problem is that the mx mechanism simply
                              only enumerates A records of MXs. That's broken ...

                              Thanks for the pointer to the docs!

                              -nik

                              --
                              # apt-assassinate --help
                              Usage: apt-assassinate [upstream|maintainer] <package>

                              PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296
                            • Wietse Venema
                              ... That s retarded. I wonder how many sites have been bitten by that bug. ... Thanks, indeed. Wietse
                              Message 14 of 24 , Oct 18, 2013
                              • 0 Attachment
                                Dominik George:
                                > >
                                > > http://www.openspf.org/SPF_Record_Syntax#ip6
                                >
                                > Jeez, I don't believe it. The problem is that the mx mechanism simply
                                > only enumerates A records of MXs. That's broken ...

                                That's retarded. I wonder how many sites have been bitten by that bug.

                                > Thanks for the pointer to the docs!

                                Thanks, indeed.

                                Wietse
                              • DTNX Postmaster
                                ... The only place I ve seen this problem with the lookup of IPv6 addresses via the mx construct in SPF records was Gmail, which was resolved, and recently
                                Message 15 of 24 , Oct 18, 2013
                                • 0 Attachment
                                  On Oct 19, 2013, at 00:13, Dominik George <nik@...> wrote:

                                  >> if i would be you i would *not* use "v=spf1 mx ~all"
                                  >
                                  > If I were [...] ...
                                  >
                                  >> here you go for ipv6
                                  >>
                                  >> http://www.openspf.org/SPF_Record_Syntax#ip6
                                  >
                                  > Jeez, I don't believe it. The problem is that the mx mechanism simply
                                  > only enumerates A records of MXs. That's broken ...

                                  The only place I've seen this problem with the lookup of IPv6 addresses via the 'mx' construct in SPF records was Gmail, which was resolved, and recently some small local operator who kept insisting that the problem was on our side until the evidence was so overwhelmingly pointing to his own setup that he could no longer ignore it.

                                  He made the same claim, however, but never backed it up. How are you reaching your conclusion?

                                  Because this only mentions A records and IPv4 prefixes?

                                  http://www.openspf.org/SPF_Record_Syntax#mx

                                  Mvg,
                                  Joni
                                • staticsafe
                                  ... Quick testing: me@staticsafe.ca - @gmail.com account Received-SPF: pass (google.com: domain of me@staticsafe.ca designates 2607:5300:60:e3a::1 as
                                  Message 16 of 24 , Oct 19, 2013
                                  • 0 Attachment
                                    On 10/19/2013 01:45, DTNX Postmaster wrote:
                                    > On Oct 19, 2013, at 00:13, Dominik George <nik@...> wrote:
                                    >
                                    >>> if i would be you i would *not* use "v=spf1 mx ~all"
                                    >>
                                    >> If I were [...] ...
                                    >>
                                    >>> here you go for ipv6
                                    >>>
                                    >>> http://www.openspf.org/SPF_Record_Syntax#ip6
                                    >>
                                    >> Jeez, I don't believe it. The problem is that the mx mechanism simply
                                    >> only enumerates A records of MXs. That's broken ...
                                    >
                                    > The only place I've seen this problem with the lookup of IPv6 addresses via the 'mx' construct in SPF records was Gmail, which was resolved, and recently some small local operator who kept insisting that the problem was on our side until the evidence was so overwhelmingly pointing to his own setup that he could no longer ignore it.
                                    >
                                    > He made the same claim, however, but never backed it up. How are you reaching your conclusion?
                                    >
                                    > Because this only mentions A records and IPv4 prefixes?
                                    >
                                    > http://www.openspf.org/SPF_Record_Syntax#mx
                                    >
                                    > Mvg,
                                    > Joni
                                    >

                                    Quick testing:
                                    me@... -> @... account

                                    Received-SPF: pass (google.com: domain of me@... designates
                                    2607:5300:60:e3a::1 as permitted sender) client-ip=2607:5300:60:e3a::1;

                                    staticsafe.ca. 1792 IN SPF "v=spf1 mx -all"

                                    To check-auth@...:
                                    ----------------------------------------------------------
                                    SPF check details:
                                    ----------------------------------------------------------
                                    Result: pass
                                    ID(s) verified: smtp.mailfrom=me@...
                                    DNS record(s):
                                    staticsafe.ca. 1800 IN SPF "v=spf1 mx -all"
                                    staticsafe.ca. 1800 IN MX 10 mx1.staticsafe.ca.
                                    mx1.staticsafe.ca. 1800 IN AAAA 2607:5300:60:e3a::1


                                    --
                                    staticsafe
                                    O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
                                    Please don't top post. It is not logical.
                                    Please don't CC me! I'm subscribed to whatever list I just posted on.
                                  • Dominik George
                                    ... Correct. The changes to SPF proposed yesterday do not change anything. -nik -- Wer den Grünkohl nicht ehrt, ist der Mettwurst nicht wert! PGP-Fingerprint:
                                    Message 17 of 24 , Oct 19, 2013
                                    • 0 Attachment
                                      > >He made the same claim, however, but never backed it up. How are you
                                      > >reaching your conclusion?
                                      > >
                                      > >Because this only mentions A records and IPv4 prefixes?
                                      > >
                                      > >http://www.openspf.org/SPF_Record_Syntax#mx

                                      > Quick testing:
                                      > me@... -> @... account
                                      >
                                      > Received-SPF: pass (google.com: domain of me@...
                                      > designates 2607:5300:60:e3a::1 as permitted sender)
                                      > client-ip=2607:5300:60:e3a::1;

                                      Correct. The changes to SPF proposed yesterday do not change anything.

                                      -nik

                                      --
                                      Wer den Grünkohl nicht ehrt, ist der Mettwurst nicht wert!

                                      PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296
                                    • John Allen
                                      ... I had a similar problem to yours, Might I suggest adding smtp_bind_address and/or smtp_bind_address6 to your config. In my case I added them tot he smtp
                                      Message 18 of 24 , Oct 22, 2013
                                      • 0 Attachment
                                        >>> He made the same claim, however, but never backed it up. How are you
                                        >>> reaching your conclusion?
                                        >>>
                                        >>> Because this only mentions A records and IPv4 prefixes?
                                        >>>
                                        >>> http://www.openspf.org/SPF_Record_Syntax#mx
                                        >> Quick testing:
                                        >> me@... -> @... account
                                        >>
                                        >> Received-SPF: pass (google.com: domain of me@...
                                        >> designates 2607:5300:60:e3a::1 as permitted sender)
                                        >> client-ip=2607:5300:60:e3a::1;
                                        > Correct. The changes to SPF proposed yesterday do not change anything.
                                        >
                                        > -nik
                                        >
                                        I had a similar problem to yours,

                                        Might I suggest adding smtp_bind_address and/or smtp_bind_address6 to
                                        your config. In my case I added them tot he smtp entry in master.cf,
                                        they seemed to fix the problem for me.
                                        John A
                                      • Mark Martinec
                                        ... That http://www.openspf.org/SPF_Record_Syntax wiki page is wrong, or misleading in the least. The SPF specification in RFC 4408 does not fall into this
                                        Message 19 of 24 , Oct 24, 2013
                                        • 0 Attachment
                                          Dominik George wrote:
                                          > if i would be you i would *not* use "v=spf1 mx ~all"
                                          > here you go for ipv6
                                          >
                                          > > http://www.openspf.org/SPF_Record_Syntax#ip6
                                          >
                                          > Jeez, I don't believe it. The problem is that the mx mechanism simply
                                          > only enumerates A records of MXs. That's broken ...

                                          Wietse wrote:
                                          > That's retarded. I wonder how many sites have been bitten by that bug.

                                          Joni wrote:
                                          > The only place I've seen this problem with the lookup of IPv6 addresses via
                                          > the 'mx' construct in SPF records was Gmail, which was resolved, and
                                          > recently some small local operator who kept insisting that the problem was
                                          > on our side until the evidence was so overwhelmingly pointing to his own
                                          > setup that he could no longer ignore it.
                                          >
                                          > He made the same claim, however, but never backed it up. How are you
                                          > reaching your conclusion?
                                          >
                                          > Because this only mentions A records and IPv4 prefixes?
                                          > http://www.openspf.org/SPF_Record_Syntax#mx

                                          That http://www.openspf.org/SPF_Record_Syntax wiki page is wrong,
                                          or misleading in the least.


                                          The SPF specification in RFC 4408 does not fall into this trap,
                                          it talks about a (generic) <ip> address.

                                          Some excerpts from RFC 4408:


                                          When any mechanism fetches host addresses to compare with <ip>, when
                                          <ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6
                                          address, AAAA records are fetched.

                                          5.3. "a"
                                          This mechanism matches if <ip> is one of the <target-name>'s IP
                                          addresses.
                                          A = "a" [ ":" domain-spec ] [ dual-cidr-length ]
                                          An address lookup is done on the <target-name>. The <ip> is compared
                                          to the returned address(es). If any address matches, the mechanism
                                          matches.

                                          5.4. "mx"

                                          This mechanism matches if <ip> is one of the MX hosts for a domain
                                          name.
                                          MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
                                          check_host() first performs an MX lookup on the <target-name>. Then
                                          it performs an address lookup on each MX name returned. The <ip> is
                                          compared to each returned IP address. [...]

                                          dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]


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