Glad to see the spec get refined a bit; perfection in an ID isn't
expected; some refinement discussion snipped.
This is how IETF specs are supposed to be developed - in open
discussion.
On Tue, 15 Jun 2004 07:58:28 -0400, "John Leslie" <john(_at_)jlc(_dot_)net>
said:
Matthew Elvey <matthew(_at_)elvey(_dot_)com> wrote:
...
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.
"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.
Sounds good. (IMO, it should be mentioned as supplemental, if at all, as
KISS makes the spec easier to read, and that's critical.)
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?
I'm saying two things.
1)Just as rDNS doesn't tie an IP to a domain for our purposes, perhaps
neither does SMTP Auth. So it perhaps shouldn't be part of the spec, if
the purpose is just to be a component of CSV.
2)Just as rDNS doesn't tie an IP to a domain for our purposes, STARTTLS
might not either - i.e. STARTTLS should be used to validate the identity
of the connection initiator, not the connection acceptor. Typically,
STARTTLS validates the connection acceptor to the initiator. In other
words, it typically (e.g. in https:// or for secure SMTP) is used to
ensure that when you go to a site, you're communicating with who you
think you're communicating with. It typically doesn't ensure that the
site is communicating whith whom it thinks it's communicating with - the
web surfer doesn't have an identity tied to a domain; the site (the
connection acceptor) is tied to a domain via the CA. Hopefully that's
more clear, not less clear.
I guess if either these two methods are mentioned here but not relevant
to CSV, that should be stated.
(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.)
Oh, right. There's an MX wildcard on elvey.com.
But I expect no server is going to send EHLO matthew.elvey.com.
Or even EHLO elvey.com, unless I set up my own server.
Thinking aloud about something:
Well, I just noticed that my posts ARE often from a server that seems to
be sending
EHLO elvey.com, e.g.
Received: from elvey.com (adsl-63-195-86-147.dsl.snfc21.pacbell.net
[63.195.86.147])
by mail.messagingengine.com (Postfix) with ESMTP id D227ABDDD8D;
Wed, 26 May 2004 22:17:21 -0400 (EDT)
But this doesn't matter because this is me sending to a server that I've
authenticated to with STARTTLS. It will not be doing CSV validation on
email I send it; it trusts me.
It's not the the hop that we're concerned with. My mail server doesn't
do something silly like put elvey.com in the EHLO just because it's in
the from for this hop:
Received: from out2.smtp.messagingengine.com ([66.111.4.26])
by ietf-mx with esmtp (Exim 4.12) id 1BTAUD-0005Mh-00
for asrg(_at_)ietf(_dot_)org; Wed, 26 May 2004 22:19:13 -0400
and I don't think others do either.