On Fri, 2004-12-10 at 13:58 -0500, John Leslie wrote:
and don't screw up cutting and pasting your SRV records in the zonefile...
_client._smtp.canuck.infradead.org SRV 1 2 0 phoenix.infradead.org.
The FAQ example assumes a zonefile origin of the domain itself, and
shows both the client MTA and the EHLO string should be mailhost.domain.
(Did you mean screw-up by omitting the dot after "infradead.org" ? )
In any case, that SRV RR looks to be OK now.
That was the output of 'host -t srv _client._smtp.canuck.infradead.org'
before I fixed it to allow canuck.infradead.org to HELO as itself rather
than only allowing phoenix.infradead.org, which shouldn't be trying to
do so anyway :)
I fail to understand the point of the "don't authenticate me" option in
CSA, and what implementers are supposed to do with that kind of CSA record
that's different from the absence of a CSA record. I *think* you should
just throw away CSA records with weight=3.
Tony is basically correct. Unless you have some other method to
authenticate the matching of IP address to EHLO string, you must treat
the weight == 3 case as "unknown".
Note that checking the A)ddress RR won't work for authentication in
the weight==3 case. This is intended as a warning that the list of RRs
which would be returned is incomplete.
(Also, I take note that there should be a mention of this in the
Best Practices document...)
I believe a result of "unknown" in this case means that I should accept
the HELO command and move on, so am I not doing the right thing already?
However, your SRV record says that "infradead.org" is "not authorized",
so I'm not sure what point there is in the accreditation stuff...
There is no host which will identify itself with 'HELO infradead.org'.
Somewhere in the documentation an optimisation was suggested where a
host could look at the DNA record first, before checking the CSA
records. If the accreditation is bad, there's no point in accepting the
connection whether the host is authorised or not.
--
dwmw2