Sender Rewriting Scheme

Last updated

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.

Contents

Background

In a number of cases, including change of email address and mailing lists, a message transfer agent (MTA) accepts an email message that is not destined to a local mailbox but needs to be forwarded. In such cases, the question arises of who deserves to receive any related bounce message. In general, that is either the author, or a person or other entity who administers the forwarding itself. [1] Sending bounces to the author is administratively simpler and used to be accomplished by just keeping the original envelope sender. However, if the author address is subject to a strict SPF policy (-all) and the target MTA happens to enforce it, the forwarding transaction can be rejected.

As a workaround, it is possible to synthesize a temporary bounce address on the fly that will direct any bounce back to the current MTA. The scheme provides a way to recover the original envelope address so that if a bounce does arrive, it can be forwarded along the reverse path, but this time with an empty envelope sender.

While there are other workarounds, SRS is a fairly general one. Its notion of reversing the path resembles the original routing dispositions for email, see below.

Please note: Using SRS protocol fails the SPF Alignment check for your DMARC record, and it's by design. Your DMARC record can still pass with a DKIM check.

The rewriting scheme

SRS is a form of variable envelope return path (VERP) inasmuch as it encodes the original envelope sender in the local part of the rewritten address. [2] Consider example.com forwarding a message originally destined to bob@example.com to his new address <bob@example.net>:

   ORIGINAL    envelope sender:     alice@example.orgenvelope recipient:  bob@example.com
   REWRITTEN    envelope sender:     SRS0=HHH=TT=example.org=alice@example.comenvelope recipient:  bob@example.net

The example above is adapted from Shevek. [3] With respect to VERP, the local part (alice) is moved after her domain name (example.org), further adding a prefix (SRS0), a hash (HHH), and a timestamp (TT). That reflects an operational difference: Eventual bounces back to a VERP address are handled within the rewriting domain, and forged messages can at most unsubscribe some users, a kind of abuse that hasn't seen significant exploits in the last decades. Instead, SRS aims at remailing a possible bounce back to Alice, so that forged bounces can become an alluring technique for injecting spam apparently originating from the rewriting sender.

SRS provides for another prefix, SRS1, to be used for rewriting an already rewritten address, in a multi-hop scenario. If example.net has to forward the message in turn, it can spare adding another timestamp and repeating the original local part (alice). That is, each new forwarder adds just its own hash (HHH) and the domain name of the preceding forwarder:

   FURTHER REWRITTEN    envelope sender:     SRS1=HHH=example.com==HHH=TT=example.org=alice@example.netenvelope recipient:  bob@further.example

Database alternative

Using a database can definitely control the growth of rewritten addresses, since it is sufficient to put just a unique key in the rewritten local part. It also allows for a certain amount of anonymity in the resending process, if this is desired. However, a database requires centralization and is a single point of failure. [4]

Header field alternative

Another possibility is to store the long rewritten address somewhere in the message header. The i= tag of a DKIM-Signature may be a good place, as such choice considerably improves the security. This technique has been just observed. [5] Unless there is a backup mechanism, it can only work if the bounce message is in a standard format. [6]

Historical background

Historically, all mail transfer agents (MTAs) added their host name to the reverse path . In the Simple Mail Transfer Protocol (SMTP) this reverse path is also known as MAIL FROM, but paths were also used before and outside of SMTP, e.g. as bang paths in UUCP and Usenet (NetNews). All news articles still contain a Path header, example:

Path: news.server.example!other.example!not-for-mail

The same information in an RFC 5321 e-mail envelope - that is the SMTP info like MAIL FROM - would be:

  1. MAIL FROM:<not-for-mail@other.example>
  2. MAIL FROM:<@news.server.example:not-for-mail@other.example>

The 1st step reflects the sender, the 2nd step the next MTA, etc. In this example let's assume that the 2nd MTA forwards the mail to a 3rd MTA, where it is finally delivered. The final MTA is also known as Mail delivery agent (MDA), putting the mail into the mailbox of the recipient. The MDA transforms the reverse path into the known Return-Path header field:

Return-Path:<@news.server.example:not-for-mail@other.example>

SMTP uses MX records for its forward routing. Explicit source routes as in...

RCPT TO:<@news.server.example:user@destination.example>

...to route mail from other.example via MTA news.server.example to MDA destination.example were cumbersome. To make things worse sometimes the new (1982) style of addresses was mixed with old UUCP bang paths in constructs like...

destination.example!user@news.server.exampleother.example!not-for-mail@news.server.example

...and various other kludges. SMTP and MX records made all this essentially useless. Therefore, source routing was deprecated 1989 in RFC 1123.

One special case in RFC 1123 are gateways from or to other networks like UUCP and NetNews, where the first sending MTA cannot reach the final receiver directly with TCP. It is solved by MX records and if necessary rewriting foreign addresses at the gateway. MX is an acronym for Mail eXchanger.

Another special case are mailing lists, where the list server rewrites all reverse paths to its own error handling address for bounces (error messages) by recipients. The list server could automatically unsubscribe bouncing recipients. This type of address rewriting is known since RFC 821 and still used today (RFC 5321, as well as RFC 2821, updated the SMTP chapter in RFC 1123).

Last but not least forwarding to another address always worked by rewriting the address in the forward path also known as RCPT TO, if and only if the forwarding MTA accepted the responsibility for both forwarding the mail and returning potential bounce messages to the sender. RFC 821 and all later SMTP specifications offer two result codes for this situation:

For privacy reasons these result codes are today rarely used; they include the forwarded to (251) or not forwarded to (551) address. But the meaning and the effect of forwarding to third parties is identical for result code 250 and error code 550 respectively.

As noted RFC 1123 deprecated source routing, that implicitly also deprecated the reverse routing of bounces. It was a relatively small Internet back in 1989, mail admins (postmasters) often knew each other and fixed problems on the fly. Routing bounce messages back via any forwarders was a waste of time and bandwidth if the MTA noting a problem (e.g. a rejection with a 5xx error code) could send the error message directly back to the MX of sender.

Since RFC 1123. forwarders to third parties still rewrote the RCPT TO address, but kept the MAIL FROM as is. As a side effect, MTAs wishing to accept mail from forwarders generally accept any MAIL FROM address.

More than a decade later spammers started to abuse this flaw in post-1123 SMTP, today most mails are spam and most reverse paths are forged. Note that spammers typically forge working reverse paths, many MTAs reject mail if callback verification or other plausibility checks fail for the reverse path.

RFC 5321, as well as RFC 2821, states that non-delivery reports (bounces) must be sent to the originator as indicated in the reverse path after an MTA accepted the responsibility for delivery. However, the bounce message may be suppressed when the original content is hostile (cf. spam or virus mail) or the message is forged (RFC 5321, Section 6). Note that all current forgery detection methods require the mailbox owner to supply information for them to work. Failing to supply the criteria should not make any bounce message classifiable as backscatter, although some people mistakenly think it should.

Open relays and forwarders are in an unlucky position with regards to this issue, generally they can't guarantee that the MAIL FROM address indicates the originator, and they also can't guarantee that final delivery will succeed.

This SMTP problem caused as side effect of RFC 1123 is addressed by SPF, and the executive summary is SPF breaks forwarding - actually that's not the case, SPF FAIL only asks receivers to check SPF at their border MTA, not later.

Receivers can arrange their forwarding in a way that works with SPF with in essence three strategies:

  1. not checking SPF behind their border, e.g. white list forwarders
  2. just reject SPF FAIL, resulting in a bounce (SMTP error 550)
  3. rewrite the MAIL FROM at the forwarder (as done by mailing lists)

Sender Rewriting Scheme (SRS) is one way for the third strategy.

See also

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 "From:" 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.

Greylisting is a method of defending e-mail users against spam. A mail transfer agent (MTA) using greylisting will "temporarily reject" any email from a sender it does not recognize. If the mail is legitimate, the originating server will try again after a delay, and if sufficient time has elapsed, the email will be accepted.

A bounce message or just "bounce" is an automated message from an email system, informing the sender of a previous message that the message has not been delivered. The original message is said to have "bounced".

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

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.

Variable envelope return path (VERP) is a technique used by some electronic mailing list software to enable automatic detection and removal of undeliverable e-mail addresses. It works by using a different return path for each recipient of a message.

In computing, Bounce Address Tag Validation (BATV) is a method, defined in an Internet Draft, for determining whether the bounce address specified in an E-mail message is valid. It is designed to reject backscatter, that is, bounce messages to forged return addresses.

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.

<span class="mw-page-title-main">Callback verification</span> Technique used with SMTP to validate e-mail addresses

Callback verification, also known as callout verification or Sender Address Verification, is a technique used by SMTP software in order to validate e-mail addresses. The most common target of verification is the sender address from the message envelope. It is mostly used as an anti-spam measure.

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.

An email alias is simply a forwarding email address. The term alias expansion is sometimes used to indicate a specific mode of email forwarding, thereby implying a more generic meaning of the term email alias as an address that is forwarded in a simplistic fashion.

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.

Amavis is an open-source content filter for electronic mail, implementing mail message transfer, decoding, some processing and checking, and interfacing with external content filters to provide protection against spam and viruses and other malware. It can be considered an interface between a mailer and one or more content filters.

Haraka is an open source SMTP server. Its architecture is plugin-oriented and event-driven. The server and its plugins are written in JavaScript using the Node.js framework.

References

  1. ↑ "Mailing Lists and Aliases". Simple Mail Transfer Protocol. IETF. October 2008. sec. 3.9. doi: 10.17487/RFC5321 . RFC 5321. When a message is delivered or forwarded to each address of an expanded list form, the return address in the envelope ("MAIL FROM:") MUST be changed to be the address of a person or other entity who administers the list.
  2. ↑ Meng Weng Wong (June 2003). "Sender Rewriting Scheme For Forwarders and Remailers To Rewrite Sender Addresses". OpenSPF.org. Retrieved 5 July 2013. SRS can be viewed as a form of VERP.
  3. ↑ Shevek (June 2004). "The Sender Rewriting Scheme" (PDF). Anarres.org. Retrieved 5 July 2013.
  4. ↑ Meng Weng Wong (January 2004). "SRS requirements". spf-discuss mailing list. Monharc.org. Retrieved 5 July 2013.
  5. ↑ Laura Atkins (June 2013). "Weird i= in client mail". ietf-dkim mailing list. Mipassoc.org. Archived from the original on 15 February 2015. Retrieved 5 July 2013.
  6. ↑ Michael Deutschmann (July 2013). "That weird i= is most probably EDSP". ietf-dkim mailing list. Mipassoc.org. Archived from the original on 15 February 2015. Retrieved 5 July 2013.
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.