It appears to me that it might be better for what this work group is trying
to do if the work is separated into two parts - one related to policies
and how the records maybe used by mail servers and another part related
to actual technical specifications of how records are expressed in dns.
The link between these parts is the name(s) of the SMTP parameter(s) that
we want to be able to specify in dns, but in reality technical specification
can be worked on to be general and have the "parameter name" not be absolute
but something that can be specified as part of the record itself. In such
case, the technical specifications can be worked on separately from policy
questions. Each of these parts of this workgroup work can produce separate
document, one being STD track document specifiying protocol standards on
how to express mail transmission parameters in the dns (without specifying
which these parameters are to be) where as second part of the work can
produce BCP document specifying which parameters are recommended that mail
systems use these marid records for and how these are to be used.
I have strong feeling that in the end we'll see that checking more then
one parameter is better (or at least leaving the choice on which parameters
are to be used to domain administrator) and what we can not agree on is
in terms of the efficency of the algorithm which parameters should be
checked on first, etc. In my opinion its actually too early to even tell
which order is better and in the end the practical use of the specification
and early tests would help in that regard.
For each of this parts there are some things people seem to say over and
over again while on other topics there is no agreement.
1. For policy part:
a. Work group participants agree (or else why are you on this workgroup)
that information on authorization to use one or mor parameter used in
email transmission should be made available as part of dns record
b. Participants can't agree on which parameter(s) it should be (i.e. EHLO
domain, Mail-From domain, rfc822 from or other header, etc)
c. But most agree that what is what we want to design should be general
enough that the system can be enahnced (and quickly change specification
if necessary) and to be able in the future to add more parameters to
be checked on and possibly even link to some other more complex policy
or email authentication system
2. And for technical implementation in dns:
a. We want to be able to tell which ip addresses are ok
b. We want to be able to specify it as range of ip addresses rather then
by singular ips (records are then lot smaller and more efficient)
c. We want to be able to specify the record such as that it would apply
for entire domain tree (i.e so that domain and all its subdomains
would automaticly have the same record) but also have it so that if it
exists particular domain subtree record would override the general record
(* - also see additional comments at the end of this email)
d. We can't agree on which record type is best to be used in dns
(i.e. if use of TXT is ok or SRV or new record is needed)
e. We can't agree on best way to express these records in dns tree
I think what we have right now is situation when mostly the requirements
are ready and the parts we don't agree on are not the requirements but
implemention details and this is not that unusual for any workgroup.
* - The "particular domain subtree" is usually host.subdomain.domain.com
However I note that today in the chat we were discussing if doing
records that allow to specify policies for particular email user,
(i.e username(_at_)host(_dot_)subdomain(_dot_)domain(_dot_)com) is a good
idea considering
it brings more complexity. But it doesnt! We already have specification
for expressing email address in dns - for SOA or for RP (and maybe
somewhere else too) we specify
username(_at_)host(_dot_)subdomain(_dot_)domain(_dot_)com as
"username.host.subdomain.domain.com" - this view of email address
makes the question equivalent to question on how to specify the records
(most likely by using wildcards) so that general domain.com record can
be specified and apply to any subdomain below it and at the same time
there was a way to specify an overriding host.subdomain.domain.com
record that would be queried first if it exists.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net