<div dir="ltr">On Wed, Apr 22, 2015 at 11:40 AM, Frank Bulk <<a href="mailto:frnkblk@iname.com">frnkblk@iname.com</a>> wrote:<br>><br>> Glad to hear that Microsoft did this on their O365 platform.<br>><br>>  <br>><br>> Is there an RFC or other standard that we can point other email providers to about implementing email admission in this manner?<br><br>MAAWG<br>has<br>guidelines, for whatever level of 'standard' that is:<br><br><a href="https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf">https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf</a><br><br>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<br>signature or that does not pass SPF checks..."<br><br>I am not an expert on SPF, though I've learned quite a bit while troubleshooting this<br>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:<br><br>   missing or invalid SPF record -> increased spam score, moving to soft fail or greylisting over time as fewer domains lack SPF<br>   failed SPF check -> follow the SPF record (+?~-)<br><br>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 <a href="http://debian.org">debian.org</a> that use v6 mail but refuse to add an SPF record.<br><br><br>Bill.</div>