<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 <<a
moz-do-not-send="true" href="mailto:owens.bill@gmail.com">owens.bill@gmail.com</a>>
wrote:<br>
><br>
> 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>
><br>
> 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>
><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>