Mailing List Archive

On Wed, Apr 22, 2015 at 11:40 AM, Frank Bulk <frnkblk@iname.com> 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?

MAAWG
has
guidelines, for whatever level of 'standard' that is:

https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf

They do a little handwaving around how to handle SPF records: "MAAWG
therefore recommends moving toward rejecting email that does not contain a
valid DKIM
signature or that does not pass SPF checks..."

I am not an expert on SPF, though I've learned quite a bit while
troubleshooting this
and I think something between the Google standard of only allowing SPF to
influence spam scores and the Microsoft no-soup-for-you mode is probably
appropriate. If I were to sketch out a policy for my own server, it might
look like this:

missing or invalid SPF record -> increased spam score, moving to soft
fail or greylisting over time as fewer domains lack SPF
failed SPF check -> follow the SPF record (+?~-)

I'd also only check on the true ingress, when the email enters my domain
(not too hard since I only have one mail server). With a lot of logging to
detect issues without relying on the users to report bounces (admittedly
very hard on a big server, but Google at least may be doing some of that)
and a whitelist mechanism for domains like debian.org that use v6 mail but
refuse to add an SPF record.


Bill.

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
> <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.
>

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.