Earl Hood <earl(_at_)earlhood(_dot_)com> wrote:
On September 1, 2005 at 23:05, Douglas Otis wrote:
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 |
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Actually the IETF has a practice of defining the MSB as bit 0. This
can be confusing when describing bit settings. Rather than
specifying the bit ordering, the settings were defined by value. A
bit with a value of 1 would be bit 15 per IETF big endian
conventions, and bit 0 per common little endian architectures. Bit
values of 1, 2, or 4 was an attempt to avoid this ambiguity.
I'm trying to write a technical summary of CSV, hence my initial
questions, especially on the details since I would like to include
example zone file record entries.
I want to confirm that bit value 1, 2, 3, ... in CSA terminology
corresponds to bit value 15, 14, 13, ... in RFC-1035 terminology.
No. (Those are bit _numbers_.)
If I have an SMTP client called smtp.example.com that I want
to authorize under CSA, I should have the following records in
my zone file:
_client._smtp.smtp.example.com. IN SRV 1 2 1 smtp.example.com.
smtp.example.com. IN A 172.30.10.33
This would say that; but it also says that all subdomains of
smtp.example.com will have CSA records. If you don't mean to say
anything about subdomains, you would use "SRV 1 2 0". (This is
described in detail in documents at http://mipassoc.org/csv/ ).
If I want to inform SMTP servers that I provide CSA records for
all my clients, I'd have the following record in my zone file:
_client._smtp.example.com. IN SRV 1 3 1 _client._smtp.example.com.
No.
Perhaps you'd have
"
" _client._smtp.example.com. IN SRV 1 1 1 _client._smtp.example.com.
If you used weight==3 you'd be saying that "example.com" is an
authorized EHLO name, but that you're giving no advice on what IP
addresses are authentic for it. This is _rarely_ if ever useful.
I'm trying to understand the applicable uses of a Weight summed value
of 3. What are the cases where authorization is allowed, but target
must not be used for authentication?
There are known cases where the number of actual IP addresses
assigned to a domain-name exceeds what can be returned _and_ the
domain managers choose to use a non-standard DNS server which returns
an incomplete list. Although the design team is strongly of the opinion
that such domain names should not be used as EHLO strings, we do not
choose to try to enforce that belief. Thus there must be an escape
hatch. There may be other cases as well...
Is my use of Weight 3 in my above assertion record appropriate?
No.
If an SMTP server gets a Weight 3 on a client lookup, must it then do
an explicit address lookup to determine if the client is authenticated?
No.
In fact, it MUST NOT report non-authentication if the IP address
is not in the list returned by such a lookup. It should NOT report
authentication if the IP _is_ found in such a list, because the
CSA protocol clearly says "IP addresses associated with the Target
field MUST NOT be used for authentication". In the opinion of the
design team, no such lookup should be done at all.
What is server behavior if a client is listed as authorized but
cannot be authenticated?
There is no required behavior: this is a case of "unknown".
However, there might be alternative sources of information available
to a server -- quite outside the CSA protocol. The weight==3 case
should be so rare that a database of IP addresses obtained out-of-band
could be considered reasonable to consult.
--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
ietf-clear mailing list
ietf-clear(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-clear