MARID

Last updated

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

Contents

Background

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

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 and its successor, DKIM. [2] In March 2004, the Internet Engineering Task Force IETF held a BoF on these proposals. As the result of that meeting, the task force chartered the MARID working group. [3]

Controversy

Microsoft's Caller-ID proposal was a late and highly controversial addition to this mix. It came with the following features:

Proceedings

The working group 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 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 is 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, and no RFCs were published. [5] [4]

The responsible IETF Area Director agreed to sponsor the publication of some of the unfinished MARID discussions as IETF experiments; these happened in 2005, as both the pre-MARID SPF [6] and Sender ID [7] were approved as experimental RFCs. The latter is to a certain degree a result of MARID, growing out of the Caller-ID proposal.

The ongoing disputes on technical issues and incompatibilities in Sender ID resulted later in appeals [8] to the IESG and the IAB.

Related Research Articles

The Simple Mail Transfer Protocol (SMTP) is an Internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients typically use SMTP only for sending messages to a mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per RFC 8314. For retrieving messages, IMAP is standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync.

A mail exchanger record specifies the mail server responsible for accepting email messages on behalf of a domain name. It is a resource record in the Domain Name System (DNS). It is possible to configure several MX records, typically pointing to an array of mail servers for load balancing and redundancy.

An email address identifies an email box to which messages are delivered. While early messaging systems used a variety of formats for addressing, today, email addresses follow a set of specific rules originally standardized by the Internet Engineering Task Force (IETF) in the 1980s, and updated by RFC 5322 and 6854. The term email address in this article refers to just the addr-spec in Section 3.4 of RFC 5322. The RFC defines address more broadly as either a mailbox or group. A mailbox value can be either a name-addr, which contains a display-name and addr-spec, or the more common addr-spec alone.

Sender Policy Framework (SPF) is an email authentication method which ensures the sending mail server is authorized to originate mail from the email sender's domain. This authentication only applies to the email sender listed in the "envelope from" field during the initial SMTP connection. If the email is bounced, a message is sent to this address, and for downstream transmission it typically appears in the "Return-Path" header. To authenticate the email address which is actually visible to recipients on the "To:" line, other technologies such as DMARC must be used. Forgery of this address is known as email spoofing, and is often used in phishing and email spam.

Sender ID is an historic anti-spoofing proposal from the former MARID IETF working group that tried to join Sender Policy Framework (SPF) and Caller ID. Sender ID is defined primarily in Experimental RFC 4406, but there are additional parts in RFC 4405, RFC 4407 and RFC 4408.

Email authentication, or validation, is a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the domain ownership of any message transfer agents (MTA) who participated in transferring and possibly modifying a message.

<span class="mw-page-title-main">Message submission agent</span>

A message submission agent (MSA), or mail submission agent, is a computer program or software agent that receives electronic mail messages from a mail user agent (MUA) and cooperates with a mail transfer agent (MTA) for delivery of the mail. It uses ESMTP, a variant of the Simple Mail Transfer Protocol (SMTP), as specified in RFC 6409.

Forward-confirmed reverse DNS (FCrDNS), also known as full-circle reverse DNS, double-reverse DNS, or iprev, is a networking parameter configuration in which a given IP address has both forward (name-to-address) and reverse (address-to-name) Domain Name System (DNS) entries that match each other. This is the standard configuration expected by the Internet standards supporting many DNS-reliant protocols. David Barr published an opinion in RFC 1912 (Informational) recommending it as best practice for DNS administrators, but there are no formal requirements for it codified within the DNS standard itself.

The Sender Rewriting Scheme (SRS) is a scheme for bypassing the Sender Policy Framework's (SPF) methods of preventing forged sender addresses. Forging a sender address is also known as email spoofing.

Certified Server Validation (CSV) is a technical method of email authentication intended to fight spam. Its focus is the SMTP HELO-identity of mail transfer agents.

In computing, Author Domain Signing Practices (ADSP) is an optional extension to the DKIM E-mail authentication scheme, whereby a domain can publish the signing practices it adopts when relaying mail on behalf of associated authors.

DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in email, a technique often used in phishing and email spam.

Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email authentication protocol. It is designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as email spoofing. The purpose and primary outcome of implementing DMARC is to protect a domain from being used in business email compromise attacks, phishing email, email scams and other cyber threat activities.

Email forwarding generically refers to the operation of re-sending a previously delivered email to an email address to one or more different email addresses.

Backscatter is incorrectly automated bounce messages sent by mail servers, typically as a side effect of incoming spam.

A bounce address is an email address to which bounce messages are delivered. There are many variants of the name, none of them used universally, including return path, reverse path, envelope from, envelope sender, MAIL FROM, 5321-FROM, return address, From_, Errors-to, etc. It is not uncommon for a single document to use several of these names.

SMTP Authentication, often abbreviated SMTP AUTH, is an extension of the Simple Mail Transfer Protocol (SMTP) whereby a client may log in using any authentication mechanism supported by the server. It is mainly used by submission servers, where authentication is mandatory.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

Murray S. Kucherawy is a computer scientist, mostly known for his work on email standardization and open source software.

References

  1. ↑ Lightweight MTA Authentication Protocol (LMAP) Discussion and Comparison
  2. ↑ "How to Read DMARC Reports?". powerdmarc.com. Retrieved 2023-07-25.
  3. ↑ MTA Authorization Records in DNS - MARID charter Retrieved 25 July 2023
  4. 1 2 Levine, John R. "An analysis of Microsoft's MARID patent applications". John R. Levine. Retrieved 15 May 2019.
  5. ↑ Seltzer, Larry (22 September 2004). "Internet Task Force Shuts Down Anti-Spam Working Group". eWeek. Retrieved 15 May 2019.
  6. ↑ Sender Policy Framework (SPF) for Authorizing Use of Domains in E-MAIL, version 1
  7. ↑ Purported Responsible Address in E-Mail Messages
  8. ↑ Mehnle, Julian (August 25, 2005). "Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02". Archived from the original on August 22, 2009.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.