Mailing List Archive

I guess I don't understand why this is an IPv6 issue.

You said:

"...we've discovered that there are sporadic failures even when there
are valid SPF records...""

If there are sporadic failures internally in Microsoft how can they
guarantee that those sporadic failures will go away if you change to
IPv4?

They can't.

Bill, you sound like one of my customers who 5 months ago bought a
Dell Windows 8 tablet. He was a "believer" He setup that tablet
and he was dammed if he was going to get it to work like the laptop
it replaced. Every time he had a problem, instead of blaming the
tablet he blamed everything else - the network, the peripherals, the
software - on and on and on.

Finally last week he admitted defeat. The tablet went home for the
kids to take to school (and probably lose/drop/whatever) and he bought a
laptop.

You called Microsoft and gave their support team a fair chance to fix
the problem. They didn't. Cut your losses and move on. There are
plenty of other cloud providers who are offering email that works. By
the time Microsoft finally fixes O365 you will be retired and so will I.

How long did it take for them to fix all the bugs in the Outlook mail
client?

Ted

On 4/1/2015 5:02 PM, Bill Owens 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.
>
> We've been pursuing this through Microsoft support but are not making
> progress. The latest response is a recommendation to give up and disable
> IPv6 mail. I would really rather not do that, because the next step will
> be for me to push as hard as I can for our company to abandon Office365
> as a defective product. I don't think there's anything fundamentally
> wrong with requiring SPF for IPv6 mail; I believe this is a bug that
> ought to be fixable, if we can just find someone within Microsoft who is
> willing to look hard at it. Is there anyone from Microsoft on this list
> who is willing to look into this, or any suggestions for someone at
> Microsoft who could help encourage the support folks to take it seriously?
>
> Thanks,
> Bill.
>
> PS - After sending this from my work/Office365 I realized that I hadn't
> seen any ipv6-ops email in a couple of weeks, and I've come to the
> conclusion that it's all being bounced by Microsoft because
> lists.cluenet.de <http://lists.cluenet.de> doesn't have an SPF record. I
> wouldn't be surprised to find out that Mailman has already unsubscribed
> my work address for excessive bounces. So I've re-subscribed from my
> personal Google account in order to have something that actually works...

Hi,

> I guess I don't understand why this is an IPv6 issue.
>
> You said:
>
> "...we've discovered that there are sporadic failures even when there
> are valid SPF records...""
>
> If there are sporadic failures internally in Microsoft how can they
> guarantee that those sporadic failures will go away if you change to
> IPv4?
>
> They can't.

+1

(...)

> You called Microsoft and gave their support team a fair chance to fix
> the problem. They didn't. Cut your losses and move on. There are
> plenty of other cloud providers who are offering email that works. By
> the time Microsoft finally fixes O365 you will be retired and so will I.
>
> How long did it take for them to fix all the bugs in the Outlook mail
> client?

My 0,02€, when you use clouded services you have industrial services, so don't even expect having nice QOS or fixed stupid issues.
Remember of postmaster that has been crazy with bloody hotmail services that loosed mail or even don't be able to have their mail arrived on time.

If mail is really important : use dedicated servers like a Zimbra for example on your office or even on a hoster company.
It can be cheaper than O365 or other and gets better services (and debug).

Now using "clowd" services is a choice and you should pay issues with them.

IP has the ability to have the possiblity to host yourself your services (eg an IP can be a client or a server), so why continue to centralize services ? SDSL or Fiber access are going to be cheap... So use them.

Regards,
Xaviers

On Thu, Apr 2, 2015 at 3:38 AM, Ted Mittelstaedt <tedm@ipinc.net> wrote:
>
> I guess I don't understand why this is an IPv6 issue.
>
> You said:
>
> "...we've discovered that there are sporadic failures even when there are
valid SPF records...""
>
> If there are sporadic failures internally in Microsoft how can they
> guarantee that those sporadic failures will go away if you change to
> IPv4?

It's an IPv6 issue because Microsoft has made it their policy to require
SPF (or DKIM) for mail that arrives over IPv6 transport, and not for mail
that arrives over IPv4. This particular topic was brought up a few months
ago: https://www.mail-archive.com/ipv6-ops@lists.cluenet.de/msg01549.html
It's also documented by Microsoft themselves:
https://technet.microsoft.com/en-us/library/dn720852%28v=exchg.150%29.aspx
And apparently the MAAWG agrees, for whatever that's worth:
https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf

So yes, I can guarantee that the problem will go away by changing to IPv4.
​ ​
I could therefore 'fix' the problem by simply admitting defeat.
​ ​
I don't want to do that, because I want to move towards IPv6 ;)

I *could* also solve the problem by switching to Google, because although
they check SPF for IPv6 their internal policies are somewhat different and
much more forgiving. But before moving on to that question I'd like to see
whether it's possible to get Microsoft to work a little harder on fixing
their problem(s).

> You called Microsoft and gave their support team a fair chance to fix
> the problem. They didn't. Cut your losses and move on. There are
> plenty of other cloud providers who are offering email that works. By
the time Microsoft finally fixes O365 you will be retired and so will I.

I think I've been more than fair, especially when the standard refrain from
their support people appears to be "this service doesn't really work, you
should stop using it." And let me be clear that I didn't choose Office365
and don't recommend it. However, it isn't my sole decision; the IT function
in our company does not report to me. And the choice to out-source email
has a number of drivers that aren't relevant at this point.

Like I said, I do want to work harder with Microsoft to get this fixed,
both for us and for anyone else who would like to use v6 transport for
their Outlook365 email. I just need to find someone within Microsoft who is
also willing to work at it.

Bill.

​PS - I'm only 47, so I hope that I can see widespread IPv6 adoption before
I retire ;)​

On 4/2/2015 3:07 AM, Bill Owens wrote:
> On Thu, Apr 2, 2015 at 3:38 AM, Ted Mittelstaedt <tedm@ipinc.net
> <mailto:tedm@ipinc.net>> wrote:
> >
> > I guess I don't understand why this is an IPv6 issue.
> >
> > You said:
> >
> > "...we've discovered that there are sporadic failures even when there
> are valid SPF records...""
> >
> > If there are sporadic failures internally in Microsoft how can they
> > guarantee that those sporadic failures will go away if you change to
> > IPv4?
>
> It's an IPv6 issue because Microsoft has made it their policy to require
> SPF (or DKIM) for mail that arrives over IPv6 transport, and not for
> mail that arrives over IPv4. This particular topic was brought up a few
> months ago:
> https://www.mail-archive.com/ipv6-ops@lists.cluenet.de/msg01549.html
> It's also documented by Microsoft themselves:
> https://technet.microsoft.com/en-us/library/dn720852%28v=exchg.150%29.aspx
> And apparently the MAAWG agrees, for whatever that's worth:
> https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf
>
> So yes, I can guarantee that the problem will go away by changing to IPv4.
> ​ ​

You said in your original post that they were ALSO losing mail during
INTERNAL transfers WITHIN their system.

If they receive mail via IPv4 and then transfer it from server to server
via IPv6 and there is no SPF record it seems to me that the
same problem will happen. You had said this much was already happening.

It just sounds to me like your making excuses for them.

It sounds like the same problem those sex-trafficked victims have.
Their pimps beat them and they still make excuses for their pimps and
defend them.

Microsoft is beating you up and your making excuses for them.

No difference from my viewpoint.

This SPF on IPv6 only is clearly ridiculous policy. It is juvenile.

> I could therefore 'fix' the problem by simply admitting defeat.
>

Leaving a vendor that is abusing you is not admitting defeat. It is
embracing liberation. Your abuser - Microsoft - has programmed you
into believing that leaving them means you are a failure. Deprogram
yourself and come to the light.

Microsoft has done many things right. Like Windows XP and Windows 7 But
they have done many things
wrong. O365 is some of their trash. As is Surface RT. and Windows 8.
And many others. Just because you use the right things of theirs does
not mean you must suck up their trash as well.
​ ​
> I don't want to do that, because I want to move towards IPv6 ;)
>
> I *could* also solve the problem by switching to Google, because
> although they check SPF for IPv6 their internal policies are somewhat
> different and much more forgiving. But before moving on to that question
> I'd like to see whether it's possible to get Microsoft to work a little
> harder on fixing their problem(s).
>

Why switch to Google? There are plenty of other email providers out
there. Google, Microsoft and Apple are not the computer universe.

> > You called Microsoft and gave their support team a fair chance to fix
> > the problem. They didn't. Cut your losses and move on. There are
> > plenty of other cloud providers who are offering email that works.
> By the time Microsoft finally fixes O365 you will be retired and so will I.
>
> I think I've been more than fair, especially when the standard refrain
> from their support people appears to be "this service doesn't really
> work, you should stop using it." And let me be clear that I didn't
> choose Office365 and don't recommend it. However, it isn't my sole
> decision; the IT function in our company does not report to me. And the
> choice to out-source email has a number of drivers that aren't relevant
> at this point.
>

Now your making excuses for other execs in your org. Why do you protect
these people who beat you up so much?

Just tell your people we are switching, and do it. 99% of them don't
give a rat's ass where the email comes from or how it's handled in the
back end as long as it shows up in their Outlook inbox.

> Like I said, I do want to work harder with Microsoft to get this fixed,
> both for us and for anyone else who would like to use v6 transport for
> their Outlook365 email. I just need to find someone within Microsoft who
> is also willing to work at it.
>

You (your org) is paying MS money. That, and bug reports, is -all- you
owe them. It's not your responsibility to fix Microsoft. You explained
their problem to them. Now it's their responsibility to fix. Don't
worry they are big boys.

I may sound like a hard-ass but I learned a long time ago that when my
employers (and customers - as today, my employers are all customers) are
given too much information by me to them, they feel as though I am
asking them to make decisions. And they will oblige.

If I call a plumber in to fix a sink I expect the plumber to come in and
fix it and leave. I don't expect the plumber to spend an hour
discussing the current trends in the plumbing industry or give me a
dissertation as to why brass is better than plastic.

if the plumber arrives and starts doing that - tells me all about brass
and plastic fittings and such - then I will feel compelled to voice my
uninformed opinions which ultimately will further complicate the job.

Similarly, if a customer calls me to come in and fix a system, I will
come in and do it. I will NOT spend 3 hours giving them a history of
the Internet or explaining all about the current war between Google and
Microsoft and why we are going with one or the other or with someone
different. I will just come in and pick the pieces of the system that I
feel are the best, and plug them in together and hand the finished piece
to the customer. I don't try to weasel out of responsibility for my
reputation.

That's what your boss and my customers want. They don't want to be
drawn into choosing Microsoft and such. That's your job. They just
want you to fix it.

You're complicating this by pulling them in to make this
sit-around-the-campfire-and-have-a-feel-good-confab and paying attention
to their opinions. If their opinions were competent ones they wouldn't
have hired you to fix the problem. Don't pay attention to what the "IT
function" in the company is doing, if they were truly in charge you
wouldn't even be here bringing all of this up because you wouldn't be in
the loop at all. You're in charge, take the bull by the balls and start
calling other providers, get your ducks in line, get the research done,
then move to a functioning provider and dump O365 - or get out of the
kitchen and let someone else come in and do it.

Power is not given. Power is taken. Learn that and power will be your
servant the rest of your life.

Ted

> Bill.
>
> ​PS - I'm only 47, so I hope that I can see widespread IPv6 adoption
> before I retire ;)​
>

On Thu, Apr 2, 2015 at 6:53 AM, Ted Mittelstaedt <tedm@ipinc.net> wrote:
>
>
>
> On 4/2/2015 3:07 AM, Bill Owens wrote:
>>
>> On Thu, Apr 2, 2015 at 3:38 AM, Ted Mittelstaedt <tedm@ipinc.net
>> <mailto:tedm@ipinc.net>> wrote:
>> >
>> > I guess I don't understand why this is an IPv6 issue.
>> >
>> > You said:
>> >
>> > "...we've discovered that there are sporadic failures even when there
>> are valid SPF records...""
>> >
>> > If there are sporadic failures internally in Microsoft how can they
>> > guarantee that those sporadic failures will go away if you change to
>> > IPv4?
>>
>> It's an IPv6 issue because Microsoft has made it their policy to require
>> SPF (or DKIM) for mail that arrives over IPv6 transport, and not for
>> mail that arrives over IPv4. This particular topic was brought up a few
>> months ago:
>> https://www.mail-archive.com/ipv6-ops@lists.cluenet.de/msg01549.html
>> It's also documented by Microsoft themselves:
>>
https://technet.microsoft.com/en-us/library/dn720852%28v=exchg.150%29.aspx
>> And apparently the MAAWG agrees, for whatever that's worth:
>>
https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf
>>
>> So yes, I can guarantee that the problem will go away by changing to
IPv4.
>>
>
> You said in your original post that they were ALSO losing mail during
INTERNAL transfers WITHIN their system.
>
> If they receive mail via IPv4 and then transfer it from server to server
via IPv6 and there is no SPF record it seems to me that the
> same problem will happen. You had said this much was already happening.

Yes, because they have our domain marked to require SPF checks. If we were
to switch off IPv6, that would no longer be the case.

> It just sounds to me like your making excuses for them.
>
> It sounds like the same problem those sex-trafficked victims have.
> Their pimps beat them and they still make excuses for their pimps and
> defend them.

Thanks for that viewpoint. I'll confine my remarks to the topic of IPv6 and
email, though.

Bill.

On Wed, Apr 1, 2015 at 8:02 PM, Bill Owens <owens.bill@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:

http://blogs.msdn.com/b/tzink/archive/2015/04/18/office-365-will-slightly-modify-its-treatment-of-anonymous-inbound-email-over-ipv6.aspx

Bill.

Very good!

Notice that only the threat of losing customers motivated them to do
something.

When you are a customer of a vendor and the vendor abuses you - only a
credible threat
of leaving to find a competitor will motivate the vendor to fix the problem.

"working with them" or "giving them a chance" of "cutting them slack" is
appeasement - and it never works.

Very glad to see one more barrier to IPv6 adoption knocked down.

Ted

On 4/22/2015 6:08 AM, Bill Owens wrote:
> On Wed, Apr 1, 2015 at 8:02 PM, Bill Owens <owens.bill@gmail.com
> <mailto:owens.bill@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:
>
> http://blogs.msdn.com/b/tzink/archive/2015/04/18/office-365-will-slightly-modify-its-treatment-of-anonymous-inbound-email-over-ipv6.aspx
>
> Bill.

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.

Ted

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@ipinc.net> wrote:
>> There is an RFC:
>>
>> http://tools.ietf.org/html/rfc1122
>>
>> Section 1.2.2 Robustness Principle
>>
>> Ted
>>
>>
>> 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?
>>
>>
>>
>> Frank
>>
>>
>>
>> From: ipv6-ops-bounces+frnkblk=iname.com@lists.cluenet.de
>> [mailto:ipv6-ops-bounces+frnkblk=iname.com@lists.cluenet.de] On Behalf Of
>> Bill Owens
>> Sent: Wednesday, April 22, 2015 8:08 AM
>> To: ipv6-ops@lists.cluenet.de
>> Subject: Re: Looking for a Microsoft person who can help w/ v6 and Office365
>> email
>>
>>
>>
>> On Wed, Apr 1, 2015 at 8:02 PM, Bill Owens<owens.bill@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:
>>
>> http://blogs.msdn.com/b/tzink/archive/2015/04/18/office-365-will-slightly-modify-its-treatment-of-anonymous-inbound-email-over-ipv6.aspx
>>
>> Bill.