Looking for a Microsoft person who can help w/ v6 and Office365 email
tedm at ipinc.net
Thu Apr 23 17:14:02 CEST 2015
Sigh. Unfortunately the "embrace and extend" philosophy has encouraged
that approach. Certain companies out there are so busy trying to
transmogrify network protocols into their warped software as a way of
gaining market lock-in that they give less weight to being compatible
with everyone other than their own crap.
On 4/23/2015 7:40 AM, Erik Kline wrote:
> And yet the de facto behaviour in so many situations seems to be more
> like "Be unreasonably paranoid in what you accept, and inexplicably
> random in what you send."
> On Thu, Apr 23, 2015 at 1:23 AM, Ted Mittelstaedt<tedm at ipinc.net> wrote:
>> There is an RFC:
>> Section 1.2.2 Robustness Principle
>> On 4/22/2015 8:40 AM, Frank Bulk wrote:
>> Glad to hear that Microsoft did this on their O365 platform.
>> Is there an RFC or other standard that we can point other email providers to
>> about implementing email admission in this manner?
>> From: ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de
>> [mailto:ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de] On Behalf Of
>> Bill Owens
>> Sent: Wednesday, April 22, 2015 8:08 AM
>> To: ipv6-ops at lists.cluenet.de
>> Subject: Re: Looking for a Microsoft person who can help w/ v6 and Office365
>> On Wed, Apr 1, 2015 at 8:02 PM, Bill Owens<owens.bill at gmail.com> wrote:
>>> 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.
>>> 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.
>> I don't know whether this is in response to the problems we've reported, but
>> Microsoft has changed their attitude towards SPF and
>> IPv6 just a little. Rather than returning a 5xx error code, which causes the
>> mail to bounce immediately, they're going to return 4xx
>> and allow the sender to attempt redelivery. This ought to prevent the
>> majority of bounces that we've been seeing, although it
>> doesn't fix the underlying issue(s) that cause the false SPF failures:
More information about the ipv6-ops