On Mon, May 15, 2017 at 10:20 AM, Ken O'Driscoll via mailop < mailop@mailop.org> wrote:
> > On Mon, 2017-05-15 at 12:34 -0400, D'Arcy Cain wrote: > [...snip...] > > Are admins getting dumber or is the software (py-policyd in our case) > > getting tougher? > > You'd be surprised how many people who would identify as being technical or > worse, mail admins, still don't fully understand how SPF works. That > includes not keeping their SPF tidy and falling foul of the ten lookup > limit. > We've found, for larger entities, the ten item lookup is easily exceeded, especially since folks (like us) require multiple lookups (ie, GSuite's _ spf.google.com is 4 lookups in total). I know there are some folks who then write scripts or use a service to combine records for all of their senders into a small enough number to make it work (with monitoring to keep abreast of changes to the original records), but that's quite a bit of work. We've chosen to be more lenient in terms of the number of lookups we allow, as getting the information on authentication is more useful to us than the marginal increase in dns requests we make (and acknowledging that our cache hit rate is probably higher than smaller providers). It's true that relying on more than 10 working widely is not a great strategy. Brandon > > Add to that some major ESPs still recommending that their customers create > / replace their SPF with "v=spf1 +include:spf.esp.com ?all" > > Plus, some mailbox providers recommending that their customers create / > replace their SPF with "v=spf1 +include:spf.provider.com -all" > > And, at least one major DNS provider still letting their users create > depreciated "SPF" type records. > > The all to common "cut and paste" admin is not well served. > > > What do others think is best practice? Should we treat broken SPF > > records as if there was no record and just not check the sending server? > > This approach is taken by many mailbox providers. I don't think treating an > invalid SPF as the equivalent of none being present is a controversial > position anymore. > > [...snip...] > > They simply contact our users saying that it must be our problem. > > I have an ISP client with the same challenge. They don't accept email from > sources not listed in the SPF (if present). If someone opens a ticket they > use a 24h white-list which lets their user receive the mail and gives the > sender time to resolve their SPF. It's worked for the last few years > without issue. > > > Ken. > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
