I cant believe how long this thread has gone on...
1/ allow only your mail servers to send out mail 2/ set your SPF record to use IP addresses only (you obviously dont have any special needs) 3/ set fail response as -all 4/ make sure your mail servers have matching A|AAAA/PTR's 5/ your done - if situation persists with only one mail service, and no others, then that is hardly your problem, if you have issues with other services, as someone three pages back mentioned - then your provider is at fault and you need to vote with your wallet (move) On 19/03/2015 02:00, Hugo Slabbert wrote: > Sorry for the laggy reply; busy week. Glad to hear things got sorted out for > your v6 delivery. > >> But you have the IP address. A valid PTR will suffice. > > Sure; if valid PTR = "passes FCrDNS", then in cases like yours where the MX's > A record is within the same zone/domain as the SPF record, that would pass > the test as you describe it (ie. 'a' in the SPF record indicates "any A/AAAA > record defined for that zone"). > > But that's not how the logic of the 'a' mechanism in SPF records works. > > To be honest: the references I could dig up on this weren't very clear, so I > had to double-check my understanding on this. > > e.g. the Open SPF project lists this [1 [1]]: > >> All the A records for domain are tested. If the client IP is found among >> them, this mechanism matches. If domain is not specified, the current-domain >> is used. > > That sounds similar to "any A record defined for that zone". > > A commercial tool like MX Toolbox talks about the 'a' mechanism as "Match if > IP has a DNS 'A' record in given domain". > > Checking the RFC[2 [2]], though: > >> 5.3. "a" This mechanism matches if <ip> is one of the <target-name>'s IP >> addresses. For clarity, this means the "a" mechanism also matches AAAA >> records. a = "a" [ ":" domain-spec ] [ dual-cidr-length ] An address lookup >> is done on the <target-name> using the type of lookup (A or AAAA) >> appropriate for the connection type (IPv4 or IPv6). The <ip> is compared to >> the returned address(es). If any address matches, the mechanism matches. > > ...which more closely matches my understanding of the spec. Multiple A > records can be defined for the given <target-name>, and the client doing an > SPF authorization check would test if the IP address of the sender matches > any of those records returned on <target-name> *itself*, not for any child > records of <target-name>. > > Consider a situation where your sending server has valid FCrDNS, but for a > name outside of your domain. E.g.: > > - sender's domain: abcs.co.nz > - mail server IP: 10.1.2.3 > - PTR for 3.2.1.10.in-addr.arpa.: relay1.bigmsp.net > - A for relay1.bigmsp.net: 10.1.2.3 > - A for mailserver.abcs.co.nz.: 10.1.2.3 > - SPF for abcs.co.nz: "v=spf1 a ip4:120.138.27.178 ~all" > > What is the receiving server to do? > - PTR lookup on 3.2.1.10.in-addr.arpa. yields relay1.bigmsp.net > - address lookup on relay1.bigmsp.net would yield 10.1.2.3 (so valid FCrDNS) > - address lookup on abcs.co.nz yields 120.138.22.27 > > The receiving MX has looked at all of the information in the SPF record and > found no matches for the sending IP of 10.1.2.3. It must conclude the sending > server is not authorized. But, per the logic you described for the 'a' > mechanism, this should be a pass since an A record of 10.1.2.3 exists for > mailserver.abcs.co.nz, which is in the abcs.co.nz zone. > > How is the recipient supposed to validate that? > > I was trying to point that, given that it is not possible to reliably lookup > all A and AAAA records defined within a given zone, defining the 'a' > mechanism in SPF records to mean "any A or AAAA records defined within the > given zone" would have been a fragile and failure-prone test, and that for > this reason that is not how it was defined. > > NOTE: I humbly bow to anyone more versed in SPF mechanisms to straighten me > out if my reading is incorrect. > > On Tue 2015-Mar-17 14:40:45 +1300, Steve Holdoway <[email protected]> > wrote: > On Mon, 2015-03-16 at 16:51 -0700, Hugo Slabbert wrote: a = all A/AAAA > records in that domain. I'm reading that as any A record defined for that > zone, which in this case includes mailserver.abcs.co.nz. Is this where I'm > going wrong? Yes. Including a naked 'a' in the SPF record refers to the A > record for '@' in the zone. How is the receiving mail server to query for all > A and AAAA records for a given domain? It's not too common to allow AXFR > queries from all of the public internet... But you have the IP address. A valid PTR will suffice. -- Steve Holdoway BSc(Hons) MIITP http://www.greengecko.co.nz [4] Linkedin: http://www.linkedin.com/in/steveholdoway [5] Skype: sholdowa -- Hugo [1] http://www.openspf.org/SPF_Record_Syntax#a [1] [2] https://tools.ietf.org/html/rfc7208#section-5.3 [2] _______________________________________________ mailop mailing list [email protected] http://chilli.nosignal.org/mailman/listinfo/mailop [3] Links: ------ [1] http://www.openspf.org/SPF_Record_Syntax#a [2] https://tools.ietf.org/html/rfc7208#section-5.3 [3] http://chilli.nosignal.org/mailman/listinfo/mailop [4] http://www.greengecko.co.nz [5] http://www.linkedin.com/in/steveholdoway
_______________________________________________ mailop mailing list [email protected] http://chilli.nosignal.org/mailman/listinfo/mailop
