I would like to suggest, what I hope will lead to some meaningful discussions
on a possible path for compromise on two of the biggest issues which have faced
this group for quite some time. In the most basic terms the two issues are
1) whether we are creating a Email Policy Publication mechanism that begins by
tying a sending MTA to a domain name, or solely an MTA authentication record,
2) and whether the data is stored solely in a TXT record, or we create a new RR.
The syntax discussion really should follow the answer to question 1 (and I am a
little surprised we never answered this during the time we were supposed to
be deciding on semantics).
I would also suggest the following four points as ideas that led me to the
compromise path which will follow
1) Despite all of the debate about what needs to be expressible in an email
policy, no-one debates the need for an authentication mechanism.
2) In an ideal world the data a receiver needs should be as small, clear, and
unambiguous as possible.
3) If policies are necessary, and can be manageably placed in DNS directly or
via a pointer they need to be extensible.
4) Given the same sender record and the same message the "authentication"
question should yield the same answer for all recipients performing the test.
So, based on the above here is my suggestion.
We split the authentication and the policy expression into two separate
problems, and acknowledge that both need to be addressed. We create a new MARID
RR which has the sole purpose of encoding the authentication information for a
sending domain. The specific encoding syntax should be as small as possible,
and because of statement 4 above should specifically not be extensible outside
of a standards process. As methods for defining new authentication mechanisms
other than IP address based are discussed the method for encoding them can
continue to be the work of the MARID WG, I foresee several possibilities on the
immediate horizon.
We define the existing SenderID proposal as an experimental means of encoding
email sending policies in DNS and continue to store that data in the TXT record
for now. I am not 100% positive that this is the correct WG to continue efforts
in that space or that the policy storage mechanisms have to be limited to DNS,
but it seems to me to be valuable work that will need to be addressed somewhere
and quickly enough to capitalize on the amount of work and thought which is
currently underway in this venue and others.
The risk here is that the authentication information is stored twice in DNS and
there is the potential for people to create conflicting records (actually this
already exists even with one mechanism but is made more likely with two). This
really though just emphasizes the need for tools like the SPF and Caller ID
wizards to help people accurately create these records. The benefit is that for
systems which are only able to query TXT they have a place to look, for systems
able to query new RR's they can query either of the two depending on what
information they are attempting to find out. If they only want to know if an
MTA is legitimately sending on behalf of a domain they can use the MARID
record, if valuable new extensions are added and they want to know that
information they can retrieve the TXT record.
I would further suggest that as an added benefit, since the SenderID record is
experimental, that it continue as originally suggested to support both the
existing SPF syntax and the XML syntax.
The specific details here may or may not end up being of any value, but I
believe separating the problems of authentication alone, and of email policy
provide a means to resolve some of the more nagging issues (like the arguments
for and against XML) on which we are currently hung up.
Regards,
Robert