Matthew Elvey <matthew(_at_)elvey(_dot_)com> wrote:
On 6/14/2004 8:10 PM, John Leslie sent forth electrons to convey:
<http://www.jlc.net/MARID/CSV/>
Comments: I don't get why draft-crocker-marid-csvhna-00.html says in
"2.1 Reverse DNS"
that "For authentication of sending SMTP clients, Reverse DNS can be
used by itself"
We need to admit up-front that this document was the last one written,
and didn't get the same amount of scrutiny as the others. :^(
That said, the whole intent of the Host Name Authentication document
was to survey the field for things currently being done; not to
recommend which of them to use.
This doesn't make sense to me.
e.g. Spammer controls 345.0.0.0/24 (including having rDNS delegated from
its ISP), and makes 345.0.0.5 resolve in rDNS to mx34.aol.com, and sends
spam with EHLO = mx34.aol.com.
This fails to protect aol.com or tie the abuse to a responsible party.
You're right. This will be corrected.
In truth, most actual use of Reverse DNS sets out to do both forward-
and reverse-DNS queries, looking for a match between them. In fact, that
is mentioned a few paragraphs earlier.
I plead guilty to not proofreading the 2.1 section carefully enough.
Reverse DNS does not appear to be a good way to tie a domain to an IP.
Also, allowing it doesn't make CSV easier to implement, does it?
The host-name authentication function actually recommended is found
in the Client SMTP Authentication document, section 4 and following:
namely that the response to the SRV query should ordinarily list the
IP address(es) authorized to perform the MTA function; and that a match
of the actual IP address of the established SMTP connection to one of
these satisfies the authentication requirement.
I shall ensure that either the overview document or the HNA document
makes it clear what is being recommended; and that the HNA document
explains the weakness of using reverse-DNS without verifying the
forward-DNS match.
"2.2 Forward DNS Lookup"
is adequate to the task; there's no need for 2.1, AFAICT.
I agree 2.1 should not be mentioned without a warning of its weakness.
An accreditation service used by CSV cannot accredit aol.com as a
non-spammer if CSV does not allow aol to protect its use in HELO from
this abuse.
You are correct that omission of host-name authentication, or the
use of inadequate host-name authentication renders accreditation by
domain-name virtually useless.
Also, I don't see how 3.2 SMTP Auth protects aol.com from this same abuse.
RE. 3.1 StartTLS: *IF* STARTTLS is used *AND* the sending server's cert
is CA signed, then that makes sense.
I'm not sure I understand your question here. Could you clarify?
(Yes, I plan to rip out part of SPF and propose it as a replacement for
draft-crocker-marid-csvhna-00.html and
draft-crocker-marid-csvcsa-00.html in CSV, and create a chart comparing
the pieces chosen and the reason for each choice, all if I find the time.)
Sounds like a good execrcise.
draft-crocker-marid-csvcsa-00.html won't work with wildcards, right?
CSA was designed to validate the EHLO string, which should never
involve wildcards, IMHO. Thus "working with wildcards" was never a
design goal. (Please note that the Domain Name Accreditation methods
_are_ designed to work with wildcards.)
--
John Leslie <john(_at_)jlc(_dot_)net>