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)
- 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 stands for no crypto as opposed to DomainKeys.
Microsoft's Caller-ID proposal was a late and highly controversial addition to this mix, with the following features:
- 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 is already beyond the lightweight LMAP limits, because it operates on the SMTP DATA, or in other words the mail. In this sense Caller-ID started outside of its class.
The working group (WG) co-Chairs decided to postpone the question of RFC 2821 SMTP identities - i.e. MAIL FROM covered by SPF, or HELO covered by CSV and SPF - in favour of RFC 2822 identities covered by Caller-ID's and later Sender-ID's Purported Responsible Address (PRA).
The WG finally arrived at a point, where sender policies could be split into different scopes like the 2821 MAIL FROM or the 2822 PRA. The MARID spf2.0 syntax also allowed to join different scopes into one policy record, if the sets of permitted IPs are identical, as it's often the case.
Less than a week after the publication of a first mfrom or MAIL FROM draft the WG was terminated unilaterally by its leadership. MARID existed only seven months, no RFCs were published.
A podcast with a former co-Chair tries to explain the MARID fiasco. Another view of these events is the observation that 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 ID were approved as experimental RFCs. The latter is to a certain degree a result of MARID.
- Historical ASRG LMAP draft (2004)
- MARID status page (2004) and mxcomp list archive
- IESG applications area DEA directorate (dissolved)
- IESG evaluation of Sender-ID (2005)
- IAB appeal with links to more sources (2006)
- SenderID appeal history (2006)
- "Selected MARID-Related Terms and Acronyms". Techmoids.org. Retrieved 2008-06-14.