So, yes, our records covert our entire IP space, which is way more than we have servers for, and that is unfortunate. I've had an open bug for a couple of years to fix this, but the _netblocks thing is used by things other than SPF, so it's complicated.
-all is just plain silly. If you want to reject, DMARC will do that, but we haven't even moved gmail.com to p=reject, because the false positive rate would be too high. Maybe when ARC is finalized and gets more traction. And although I realize a lot of folks like to pin things on IP reputations, to separate the world... there are a lot of GSuite customers, more than we are likely to want to use separate IPs for, which is why we go through the trouble of having dkim/spf so that hopefully you can use authenticated domains for your reputation systems instead. Especially in terms of IPv6 usage. Brandon On Tue, Aug 1, 2017 at 5:05 PM, Michael Peddemors <mich...@linuxmagic.com> wrote: > Aside from the evil's of forwarding, and the methods that are available to > do that without running afoul of SPF.. that is an argument for another day. > Every modern email client now supports checking multiple mailboxes don't > they ;) > > ... > > host -t TXT gmail.com > gmail.com descriptive text "v=spf1 redirect=_spf.google.com" > > host -t TXT _spf.google.com > _spf.google.com descriptive text "v=spf1 include:_netblocks.google.com > include:_netblocks2.google.com include:_netblocks3.google.com ~all" > > host -t TXT _netblocks.google.com > _netblocks.google.com descriptive text "v=spf1 ip4:64.18.0.0/20 > ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 > ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:207.126.144.0/20 > ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all" > > host -t TXT _netblocks2.google.com > _netblocks2.google.com descriptive text "v=spf1 ip6:2001:4860:4000::/36 > ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 > ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all" > > host -t TXT _netblocks3.google.com > _netblocks3.google.com descriptive text "v=spf1 ip4:172.217.0.0/19 > ip4:108.177.96.0/19 ~all" > > Okay, I admit it is clearer and cleaner that many operators.. but are they > ALL outgoing mail systems that should have an envelope from of @gmail.com? > > (I think gmail.com should be separate from google.com, IMHO) > > I would expect that most of those IP(s) should be relaying out the > appropriate gmail servers.. Most of that 74.125.0.0/16 doesn't even have PTR > records, so I am sure they are not used for sending email.. > > But yes, the -all would be nicer... ;) > > By being able to reject during the SMTP handshake, it would also help alert > the sending servers admin's to a problem with compromised accounts.. > > But yeah, might be living in a dream world.. for a little bit yet. > > I will take the step in the right direction for today, and tip my hat.. > > > > > > On 17-08-01 04:37 PM, Brandon Long wrote: >> >> Tighter how? >> spf_checker_util: output header: softfail (google.com: domain of >> transitioning ptp...@gmail.com does not designate 58.64.196.210 as >> permitted sender) client-ip=58.64.196.210; >> >> You want it to just fail? That would be silly, we expect people to >> forward email. >> >> I'll pass on your compliments. >> >> Brandon >> >> On Tue, Aug 1, 2017 at 3:42 PM, Michael Peddemors >> <mich...@linuxmagic.com> wrote: >>> >>> Be interesting to know if they made changes, but no matter what.. >>> >>> "Kudos' and hats off.." >>> >>> Now if we can only convince them to have tighter SPF records ;) >>> >>> Return-Path: <ptp...@gmail.com> >>> >>> Received: from aton.hk (HELO mail.aton.hk) (58.64.196.210) >>> >>> (Dont' worry, still goes to spam folder but.. would make it easier for >>> everyone else) >>> >>> (And if email operators would bite the bullet and force envelopeFrom that >>> are on their servers.. ) >>> >>> Next one we want to see improvement on... (Oh, don't want to pick on them >>> <wink>Michael<wink>) >>> >>> >>> >>> -- >>> "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 > > > > > -- > "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
