From: [email-masked]
Date: Wed, 23 Jun 2004 18:35:44 +0000

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