Subject: Suggestion for a route to compromise

From: [email-masked]
Date: Wed, 23 Jun 2004 19:06:40 +0000

Sorry here is the same message sent with its intended subject.

> 
> 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
>