<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Very good!<br>
    <br>
    Notice that only the threat of losing customers motivated them to do
    something.<br>
    <br>
    When you are a customer of a vendor and the vendor abuses you - only
    a credible threat<br>
    of leaving to find a competitor will motivate the vendor to fix the
    problem.<br>
    <br>
    "working with them" or "giving them a chance" of "cutting them
    slack" is<br>
    appeasement - and it never works.<br>
    <br>
    Very glad to see one more barrier to IPv6 adoption knocked down.<br>
    <br>
    Ted<br>
    <br>
    On 4/22/2015 6:08 AM, Bill Owens wrote:
    <blockquote
cite="mid:CANVSWVgL9XipQNAD0++955MsrYHjwxmbMugQa50jE4D3-U_cfQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">On Wed, Apr 1, 2015 at 8:02 PM, Bill Owens &lt;<a
          moz-do-not-send="true" href="mailto:owens.bill@gmail.com">owens.bill@gmail.com</a>&gt;
        wrote:<br>
        &gt;<br>
        &gt; We've been running our Office365 mail account for a few
        weeks now with IPv6 enabled. We went into this knowing that
        Microsoft was going to enforce SPF checks on inbound mail, and
        we've run into a number of issues with people sending mail over
        v6 transport and having bad SPF records (or none). So far we've
        been able to resolve all but one of those issues, or are in the
        process of doing so; that's not a big deal. The one that won't
        fix their record is going to require us to resubscribe to a few
        mail lists, not the end of the world.<br>
        &gt;<br>
        &gt; However, we've discovered that there are sporadic failures
        even when there are valid SPF records, and in some cases even
        when the email enters the Microsoft 'world' using v4 and
        transitions to v6 between two Microsoft servers - at which point
        the SPF check is applied even though the message was "accepted"
        several hops prior, and the check sometimes fails. That's
        something we can't fix on our own.<br>
        &gt;<br>
        <br>
        I don't know whether this is in response to the problems we've
        reported, but Microsoft has changed their attitude towards SPF
        and<br>
        IPv6 just a little. Rather than returning a 5xx error code,
        which causes the mail to bounce immediately, they're going to
        return 4xx<br>
        and allow the sender to attempt redelivery. This ought to
        prevent the majority of bounces that we've been seeing, although
        it<br>
        doesn't fix the underlying issue(s) that cause the false SPF
        failures:<br>
        <br>
        <a moz-do-not-send="true"
href="http://blogs.msdn.com/b/tzink/archive/2015/04/18/office-365-will-slightly-modify-its-treatment-of-anonymous-inbound-email-over-ipv6.aspx">http://blogs.msdn.com/b/tzink/archive/2015/04/18/office-365-will-slightly-modify-its-treatment-of-anonymous-inbound-email-over-ipv6.aspx</a><br>
        <br>
        Bill.<br>
      </div>
    </blockquote>
  </body>
</html>