ietf-mxcomp
[Top] [All Lists]

Re: CSV details

2004-06-25 14:08:08

Meng Weng Wong <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com> wrote:

On Fri, Jun 25, 2004 at 10:45:52AM -0400, John Leslie wrote:
|] CSV usually returns the list of IP addresses in the reply to the
|] SRV query. The Host Name Authentication appendix gives advice on
|] how to proceed if no list is returned.
|] 
|] If the list is returned and the actual IP address is in it, the
|] receiving SMTP server SHOULD consider the EHLO domain name to be
|] authenticated. Conversely, if the list is returned and the
|] actual IP address is not in it, the assertion of the EHLO domain
|] name SHOULD be considered incorrect, and an error returned.

OK, what happens if the list is not returned?

   There are a number of possibilities:

1) There is no list; name is not authorized:
   Immediate reject, with error.

2) There is no list; name is authorized:
   An A)ddress query would be pointless. Some other authentication
   method needs to be used (a local option) or the "Authentication
   Failed" error needs to be returned.

   As noted in draft-ietf-marid-csv-csa, "Regardless of what is specified,
   this  receiving SMTP server may decide to refuse the client if their
   chosen accreditation service returns 'Unknown'." Our expectation is
   that without a reasonably good accreditation report, an error will
   be returned.

   Even with a good accreditation report, there would need to be some
   indication of _what_ alternative authentication mechanism to use:
   otherwise an error will need to be returned. Perhaps accreditation
   services will choose to recommend a method for domains which fall
   in this category: the information _that_ they do will be publicly
   available, after all.

   Please note that this case is equivalent to "we're not going to tell
   you what IP addresses might be used" -- thus trusting the EHLO name
   without authentication is really _not_ justified.

3) There is a list, but the DNS server didn't return it.
   This probably means the list is too long. Our expectation is that
   only a domain with good accreditation reports will be considered to
   deserve the time penalty for what will no doubt turn out to be a
   TCP DNS query; and any others will be refused with an "Authentication
   Failed" error.

   If the receiving SMTP server chooses to pursue this further, we
   would expect it to do a TCP DNS query and check for a match to the
   remote IP address of the existing SMTP connection. If found, the
   authentication (as well as the authorization) would be positive.

   Note, of course, that most of what I've said is a matter of local
policy, and IMHO is inappropriate to specify even at a SHOULD level.
However, if WG participants feel differently, I'm happy to write
some of this into the CSV documents.

--
John Leslie <john(_at_)jlc(_dot_)net>