Re: [mailop] Speaking of too many SPF, Many SPF failures lately
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2017-05-18 at 08:53 -0700, Luis E. Munoz wrote: > It looks not bad, successive lookups to 3 parts.. and they all look > > good. Don't like this part of course.. include:sharepointonline.com > > > > ip4:52.104.0.0/14 > Right there! Anyone hosting mail on office 365 will probably have an spf that includes spf.protection.outlook.com which lists 40.92.0.0/14 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlkegYgACgkQL6j7milTFsHqswCfSSytyvttuYojwPm77UljS+GO nEkAnAx0oXARTZUSwAEJdOq34We8Qw1o =4juJ -END PGP SIGNATURE- ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Speaking of too many SPF, Many SPF failures lately
We've seen "v=spf1 +all" for example. On the other hand, what are you supposed to do with this from a prominent tech company: "v=spf1 ip4:17.0.0.0/8 -all" So, "it's complicated" Brandon On Thu, May 18, 2017 at 6:47 PM, Ángel wrote: > The question is, when does a large range start being "too large"? > > Because otherwise, every org will start weighting at a different point. > And the worst part of this is that there are good reasons to add those > includes, to begin with (and little margin to have the upstream reducing > them). > > > ___ > 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
Re: [mailop] Speaking of too many SPF, Many SPF failures lately
On 17-05-18 06:47 PM, Ángel wrote: The question is, when does a large range start being "too large"? Because otherwise, every org will start weighting at a different point. And the worst part of this is that there are good reasons to add those includes, to begin with (and little margin to have the upstream reducing them). How nice it is of you Angel to volunteer to update the RFC with a recommendation on this :) Maybe do a little research on the 'largest' email provider(s) and how many they think they could possibly need .. a kind of 'Best Practices for SPF'.. j/k of course.. I go back to working on getting ppl to conform to recommendations made over 10 years ago as 'Best Practices'. Or getting abuse@ responses when reporting networks that 'look' like belonging to a bank, that are hacked.. Or getting ColoCrossing and others to stop letting snowshoe spammers light up.. Or get ISP's to put proper PTR records in.. Or.. (yeah, getting jaded a little, thank god a 3 day weekend ahead, and golfing weather) Can we just turn off the internet for three days please? (Hoping for that Solar Flare) -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Speaking of too many SPF, Many SPF failures lately
The question is, when does a large range start being "too large"? Because otherwise, every org will start weighting at a different point. And the worst part of this is that there are good reasons to add those includes, to begin with (and little margin to have the upstream reducing them). ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Don't you just love it when...
... someone at work changes your department's SPF record from saying "?all" (for which there have always been very good reasons) to "-all" without telling *anyone*. Tomorrow is going to be another one of "those" days. I can tell already. There is an out-of-hours procedure for getting stuff fixed. I'm bored of doing their job for them this week. It'll wait till tomorrow. Jules -- Jules Field MEng CEng CITP MBCS MIEEE MACM email+iMessage: ju...@ecs.soton.ac.uk Twitter: @JulesFM Senior Tutor, Electronics and Computer Science Postmaster, Electronics and Computer Science Teaching Systems Manager, Faculty of Physical Sciences and Engineering University of Southampton SO17 1BJ, UK 'It's okay to live without all the answers' - Charlie Eppes, 2011 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Many SPF failures lately
It's good practice to read the standard before implementing it. For permerror, 550 with 5.5.2 status code must be used, it's RFC 7208 requirement for one, who decides to block delivery based on SPF error. 451 with 4.4.3 status code should only be used for temperror, such as DNS timeout . Using 4xx for permerror is not good for sender, because he will not be aware e-mail is not delivered before some timeout and there is little chance for administrator to notice the problem in reasonable time. For temperror 4xx is used, because there is a high chance the problem is general (e.g. connectivity issues) and will be resolved. 18.05.2017 19:16, Dominique Rousseau пишет: > Le Mon, May 15, 2017 at 12:34:30PM -0400, D'Arcy Cain [da...@vex.net] a écrit: > [... broken SPF ...] >> My personal preference is to just bounce it and make them fix their >> records but it is becoming a support problem because the senders are >> not reading the bounce message which explains the problem and has a >> link to a page with more detail. They simply contact our users >> saying that it must be our problem. > You could soft-bounce with 4xx error code stating the problem > encountered. The "good" sending administrators would then view their > outgoing queues growing, have a clue about the problem, correct it, and > let the spool catch-up. > For the "bad" ones, their queues would pile up anf finally bounce to > their users. > > Else, I would consider "broken SPF" as "no SPF" rather than fail. > -- Vladimir Dubrovin @Mail.Ru ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Many SPF failures lately
Le Mon, May 15, 2017 at 12:34:30PM -0400, D'Arcy Cain [da...@vex.net] a écrit: [... broken SPF ...] > > My personal preference is to just bounce it and make them fix their > records but it is becoming a support problem because the senders are > not reading the bounce message which explains the problem and has a > link to a page with more detail. They simply contact our users > saying that it must be our problem. You could soft-bounce with 4xx error code stating the problem encountered. The "good" sending administrators would then view their outgoing queues growing, have a clue about the problem, correct it, and let the spool catch-up. For the "bad" ones, their queues would pile up anf finally bounce to their users. Else, I would consider "broken SPF" as "no SPF" rather than fail. -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 21 rue Frédéric Petit - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Speaking of too many SPF, Many SPF failures lately
On May 18, 2017 9:02 AM, "Luis E. Muñoz" wrote: On 17 May 2017, at 16:49, Michael Peddemors wrote: It looks not bad, successive lookups to 3 parts.. and they all look good. Don't like this part of course.. include:sharepointonline.com ip4:52.104.0.0/14 Right there! I've had thoughts about actually penalizing sites that list such vast amounts of IP space in their SPF records or perhaps just ignoring those large ranges in the SPF validation. I suppose it would be plagued with false positives, but if enough people did it, it would give some priority to actually think about your SMTP flows when setting up your SPF records. Yeah, we already ignore overly large ranges, don't recall at what level, but we definitely saw a bunch of exploits of wide ranges over a year ago. Brandon ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Speaking of too many SPF, Many SPF failures lately
On Thu, 18 May 2017 08:53:37 -0700, "Luis E. Muñoz" said: > large ranges in the SPF validation. I suppose it would be plagued with > false positives, but if enough people did it, it would give some > priority to actually think about your SMTP flows when setting up your > SPF records. That sort of thinking may have worked 3 decades ago, when Sendmail 5.67 was the latest and greatest way to move e-mail around, and pretty much all the sysadmins on the network knew each other by reputation, and posting "Hey guys, I can't seem to get this working, what am I missing?" was guaranteed to get you useful help. However, I haven't seen much evidence that it's been a workable strategy anytime this century. In particular, it would require a number of 800 pound gorillas who are mostly centered around increasing the success percentage to voluntarily choose a course of action that would lower the percentage - and they'd be relying on the set of sysadmins who did the *least* thinking about their configuration to fix their stuff. Phrased differently - did anybody in school *ever* voluntarily choose to work on a project with the least clued and engaged student in the class, in hopes of improving their own grade on the project? pgpKpSNoaca12.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Speaking of too many SPF, Many SPF failures lately
On 17 May 2017, at 16:49, Michael Peddemors wrote: It looks not bad, successive lookups to 3 parts.. and they all look good. Don't like this part of course.. include:sharepointonline.com ip4:52.104.0.0/14 Right there! I've had thoughts about actually penalizing sites that list such vast amounts of IP space in their SPF records or perhaps just ignoring those large ranges in the SPF validation. I suppose it would be plagued with false positives, but if enough people did it, it would give some priority to actually think about your SMTP flows when setting up your SPF records. Best regards -lem ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
