MARID

MARID was an IETF working group in the "applications" area tasked to propose standards for E-mail authentication in 2004.The name is an acronym of MTA Authorization Records In DNS.

Background

Lightweight MTA Authentication Protocol (LMAP) was a generic name for a set of 'designated sender' proposals that were discussed in the ASRG in the Fall of 2003, including:

* Designated Mailers Protocol (DMP)
* Designated Relays Inquiry Protocol (DRIP)
* Flexible Sender Validation (FSV)
* MTAMARK
* Reverse MX (RMX)
* Sender Policy Framework (SPF)

These schemes attempt to list the valid IP addresses that can send mail for a domain.The "lightweight" in LMAP essentially standsfor "no crypto" as opposed to DomainKeys.

In March 2004, the Internet Engineering Task Force IETFheld a BoF on these proposals and as the result of that meeting, chartered the MARID working group.

Microsoft's Caller-ID proposal was a late and highly controversial addition to this mix:

* use of XML policies with DNS - this was reduced to what is now known as Sender ID,
* proposals of an unfriendly takeover of SPF policies by Sender ID,
* use of RFC 2822 mail header fields as by DomainKeys, all other LMAP drafts used the SMTP envelope,
* specific questions and unspecific flame wars about patents and licensing.

For many the use of RFC 2822 mail header fields isalready beyond the "lightweight" LMAP limits,because it operates on the SMTP DATA, or in otherwords the mail. In this sense Caller-ID started outside of its class.

Proceedings

The working group (WG) co-Chairs decided to postpone the questionof RFC 2821 SMTP identities - i.e. MAIL FROM covered by SPF, or HELO covered by
CSV and SPF - infavour of RFC 2822 identities covered byCaller-ID's and later Sender-ID'sPurported Responsible Address (PRA).

The WG finally arrived at a point, where senderpolicies could be split into different "scopes"like the 2821 MAIL FROM or the 2822 PRA. TheMARID spf2.0 syntax also allowed tojoin different "scopes" into one policy record,if the sets of "permitted IPs" are identical, asit's often the case.

Less than a week after the publication of a firstmfrom or MAIL FROM draft the WG was terminated unilaterally by its leadership. MARIDexisted only seven months, no RFCs were published. A podcast with a former co-Chair tries to explain the [http://podcast.resource.org/rf-rfc/index.html#item0003 MARID fiasco] .Another view of these events is the observationthat the WG did not support a division of the
E-mail authentication field into PRA for 2822 and CSV for 2821, squeezing out the MAIL FROM.

The responsible IETF Area Director agreed to "sponsor" the publication of some MARID fallout as IETF experiments, this happened in 2005. Both"classic" pre-MARID
SPF and Sender IDwere approved as experimental RFCs. The latter isto a certain degree a result of MARID.

The ongoing disputes on technical issues and incompatibilities in Sender ID resulted laterin appeals to the
IESG andthe IAB.

External links

* Historical ASRG [http://tools.ietf.org/html/draft-irtf-asrg-lmap-discussion LMAP] draft (2004)
* MARID [http://tools.ietf.org/wg/marid/ status page] (2004) and [http://dir.gmane.org/gmane.ietf.mxcomp mxcomp] list archive
* IESG applications area [http://web.archive.org/web/20060715020416/http://www.ietf.org/u/ietfchair/dea-directorate.html DEA directorate] "(dissolved)"
* IESG [https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12542 evaluation] of Sender-ID (2005)
* [http://www.iab.org/appeals/2006-02-08-mehnle-appeal.html IAB appeal] with links to more sources (2006)
* (2006)
*