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]:
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], 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
Linkedin: http://www.linkedin.com/in/steveholdoway
Skype: sholdowa
--
Hugo
[1] http://www.openspf.org/SPF_Record_Syntax#a
[2] https://tools.ietf.org/html/rfc7208#section-5.3
_______________________________________________
mailop mailing list
[email protected]
http://chilli.nosignal.org/mailman/listinfo/mailop
