Mitigating DMARC damage to third party mail: Difference between revisions

From ASRG
Jump to navigationJump to search
No edit summary
 
(38 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers to mitigate the damage from security breaches involving theft of user information including theft of user address books.
[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.


DMARC ''alignment'' requires that the From: line address in a mail message match either a DKIM signature d= domain, or an SPF-validated bounce address domain. Depending on a domain's published ''policy'', unaligned mail may be quarantined, i.e. relegated to the spam folder or rejected by recipient systems. Mailing lists and other software that send legitimate but unaligned mail often find that mail rejected. Problems include recipients not getting the mail they want, and in some cases the normal list bounce processing removes the recipients from lists.
DMARC ''alignment'' requires that the From: line address in a mail message match either a DKIM signature d= domain, or an SPF-validated bounce address domain. Depending on a domain's published ''policy'', unaligned mail may be quarantined, i.e., relegated to the spam folder, or rejected with a 5xx SMTP code by recipient systems. Mailing lists and other software that send legitimate but unaligned mail often find that mail rejected. Problems include recipients not getting the mail they want, and in some cases the normal list bounce processing removes the recipients from lists.


== Exclude domains that require alignment ==
== Sending side workarounds ==
Techniques which can be applied unilaterally by any operator that sends unaligned mail.
 
=== Exclude domains that require alignment ===


Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.
Line 12: Line 15:
* Operation otherwise unaffected.
* Operation otherwise unaffected.


== Turn off all message modifications ==
=== Turn off all message modifications ===


Disable subject tags, message footers, and anything else that might break a DKIM signature.
Disable subject tags, message footers, and anything else that might break a DKIM signature.
Line 18: Line 21:
''Effects:''
''Effects:''


* Still doesn't work for domains that validate mail with SPF
* Still doesn't work for domains that validate mail with SPF.
* Doesn't help mail-an-article.
* Users can't recognize list mail by subject tags or anything else.
* Users can't recognize list mail by subject tags or anything else.
* Sorting by subject tags doesn't work.
* Sorting by subject tags doesn't work.
* Often impractical when footers have mandated content.
* Often impractical when footers have required content.


== Replace address with a generic one ==
=== Replace address with a generic one ===


Lists rewrite the From: line to use the list's address rather than the author's, either for all mail, or for mail from domains with policies.
Lists rewrite the From: line to use the list's address rather than the author's, either for all mail, or for mail from domains with policies.
Line 29: Line 33:
Address may be moved into address comment, e.g.
Address may be moved into address comment, e.g.


<code>From: foo list for mmeyer-at-yahoo.com <foo@list.org></code>
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code>


Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.
Line 40: Line 44:
* Mail sorting rules don't work the same.
* Mail sorting rules don't work the same.
* Encourages phishing by training users that address in the comment is equivalent to address.
* Encourages phishing by training users that address in the comment is equivalent to address.
* Breaks S/MIME signatures


== Add fixed string such as .invalid to addresses ==
=== Add fixed string such as .invalid to addresses ===


Add a suffix to From: line addresses with policies.
Add a suffix to From: line addresses with policies.
Line 52: Line 57:
* Reply to author requires usenet-style demunging
* Reply to author requires usenet-style demunging
* Encourages phishing by training users that munged address is equivalent to address.
* Encourages phishing by training users that munged address is equivalent to address.
* Breaks S/MIME signatures
* Many mail systems reject mail if the From: address domain doesn't resolve.


== Rewrite addresses to forwarding addresses ==
=== Rewrite addresses to forwarding addresses ===


Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.


<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code>
<code>From: Marissa <mmeyer@yahoo.com.dmarc.fail></code>


<code>From: Marissa <hash123@fwd.list.org></code>
<code>From: Marissa <hash123@fwd.list.org></code>
Line 65: Line 72:
* List function largely unchanged
* List function largely unchanged
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam
* Forwarding addresses likely to end up in user address books, which means either the forwarder has to work forever or the address book entries will suffer bit rot. (Too bad no SMTP software supports 251 and 551 reply codes any more.)
* Encourages phishing by training users that modified address is equivalent to address.
* Encourages phishing by training users that modified address is equivalent to address.
* Breaks S/MIME signatures


== Message wrapping ==
=== Message wrapping ===


Wrap each message in an outer message, similar to single-message digests.
Wrap each message in an outer message, similar to single-message digests.
Line 76: Line 85:
* May encourage phishing depending on how MUA displays message.
* May encourage phishing depending on how MUA displays message.


== Mandatory digests ==
=== Mandatory digests ===


Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests
Line 84: Line 93:
* All the usual reasons people don't like digests, mail is delayed until the digest is sent, replying to individual messages is harder, replying to the whole digest loses threads, etc.
* All the usual reasons people don't like digests, mail is delayed until the digest is sent, replying to individual messages is harder, replying to the whole digest loses threads, etc.


== Ignore DMARC bounces ==
=== Ignore DMARC bounces ===


Check for DMARC codes in bounce messages and disregard them for list management.
Check for DMARC codes in bounce messages and disregard them for list management.
Line 93: Line 102:
* Bounces may affect list reputation and delivery
* Bounces may affect list reputation and delivery


== Shared whitelist ==
== Author's domain side workarounds ==
 
Techniques that can be applied unilaterally by author's domains.
 
=== Third Party Authorization Label ===
 
With respect to RFC 6541, DKIM Authorized Third-Party Signatures, TPA-Label allows a domain to authorize other domains unilaterally; that is, without the need for mailing lists or other forwarders to claim they're signing on behalf of a given domain.
 
TPA-Label allows either a community or domain managed list of informally federated domains using a single and small DNS transaction. Deployment only requires the trusted domain and the system evaluating DMARC alignment to implement TPA-Label processing.  Few third-party services will be required to make any changes.
 
TPA-Label helps direct which message element provides alignment and can signal when a domain is excluded from the federation for policy reasons.  The exclusion circumvents repeated processing during review of DMARC feedback against outbound logs which is only done by the Trusted Domain (email provider).
 
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].
 
''Effects:''
 
* Messages by such authors won't be blocked even if the From: is left intact, assuming TPA-Label compliant recipients.
 
== Recipient workarounds ==
 
Techniques that can be applied unilaterally by recipient systems and users.
 
=== Forwarder whitelist ===
 
The recipient system or perhaps each individual recipient maintains a list of IPs or DKIM signatures for mailing lists and other non-hostile forwarders. Probably wouldn't be absolute whitelist, just skip DMARC alignment check, due to spammers compromising users' accounts and sending spam to addresses in their address books, including lists to which they are subscribed.
 
''Effects:''
 
* Lets forwarders work the way they always have.
* A lot of work for recipient systems or users.
* Unsophisticated users could mistakenly whitelist malicious senders.
 
== Cooperative solutions ==
 
Techniques which need mutual cooperation in order to work.
 
=== Shared whitelist ===


Third party maintains DMARC-bypass whitelist of IPs and/or DKIM signatures of senders who send legitimate unaligned mail. Could probably seed with forwarders known to large mail systems.  Probably wouldn't be absolute whitelist, just skip DMARC alignment check.
Third party maintains DMARC-bypass whitelist of IPs and/or DKIM signatures of senders who send legitimate unaligned mail. Could probably seed with forwarders known to large mail systems.  Probably wouldn't be absolute whitelist, just skip DMARC alignment check.
Line 100: Line 145:


* Someone has to do it.
* Someone has to do it.
* Eligble senders need to find out about it and apply, if not seeded.
* Eligible senders need to find out about it and apply, if not seeded.
* Could allow more spam or phish depending on how careful forwarders are.
* Could allow more spam or phish depending on how careful forwarders are.


== Per sender whitelist ==
=== Per sender whitelist ===


Senders publish list of DKIM signatures allowed to send for them
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.


''Effects:''
''Effects:''
Line 111: Line 156:
* A lot of work for each sender
* A lot of work for each sender
* Large senders unlikely to know all of the third parties that their users use.
* Large senders unlikely to know all of the third parties that their users use.
=== Original-Authentication-Results header ===
Remailers include a header reporting on the authentication of the incoming message. AR header is intended to detect spear-phishing if the remailer doesn't.
''Effects:''
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)
* List operation unaffected if it works.
* Doesn't help mail-an-article.
=== Forwarding token ===
Original sender includes a header with a signed token that identifies the relay. See this
[https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ conditional DKIM signature draft] for a possible implementation.
''Effects:''
* A variety of bad things if the relay is compromised or tries to play games.
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)
== Authorization approaches ==
Ways to get a DKIM author signature or something similar on the message.
=== Authenticated Received Chain (ARC) ===
ARC defines a chain of DKIM-like signatures applied by forwarders so that a receiving host can estimate whether a message was authenticated when it was sent. Currently under development by an [https://datatracker.ietf.org/wg/dmarc/documents/ IETF working group], with drafts of
[https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ the protocol spec] and a [https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-usage/ usage guide].
''Effects:''
* No changes to user-visible parts of messages. If it works, mailing lists and other forwarders can continue working as they always have,
* Proposed by large mail systems so they are likely to implement it.
* ARC headers are easy to forge, so recipients have to track forwarder reputation before believing ARC headers.
* Forwarders depend on recipients to implement it.
=== Signing key delegation ===
The author domain delegates a signing key to the list operator.
''Effects:''
* Requires that mail providers trust the list operators.
* Scales poorly since each list operator needs to get a key from each sending domain.
=== Relay through author domain server ===
Use API or SUBMIT to send mail through the author domain's server
''Effects:''
* Requires a a password at each author domain
* Web submission (mail and article) could use API and oauth to avoid disclosing password
* Otherwise need users' password for SUBMIT
* Author domain likely to force its own bounce address
* Author domain likely to limit volume
=== Relay one copy through author domain server ===
As above, but send one copy back to the list to get signed, then remail that copy
''Effects:''
* As above but avoids bounce address and volume issues
* Only works if all recipients get the same message, not customized per-recipient
=== Have author domains sign camera-ready posts ===
The author domain runs a subset of the list software that carries out the changes as configured by each target list.
''Effects:''
* List has to recognize camera-ready posts and avoid applying further changes in that case
* List has to publish part of its configuration (specification)
* Only works if all recipients get the same message, not customized per-recipient
=== Recognize message transformations ===
The most common transformations that mailing lists operate, namely the addition of a subject tag and of a message footer, the [[#Replace_address_with_a_generic_one| change of From:]], and the possible change of encoding, can be recognized and undone, so as to validate the author domain's DKIM signature.  To be recognized across transformation, an author domain's signature must be somewhat "mild".  That is, use relaxed canonicalization, at least for the header, avoid signing key fields that mailing lists almost certainly rewrite (for example, Content-Type: and MIME-Version:), and possibly provide some auxiliary fields (for example, Original-Content-Transfer-Encoding:).
See [https://tools.ietf.org/html/draft-vesely-dmarc-mlm-transform draft-vesely-dmarc-mlm-transform].
''Limits:''
* Only "mild" author domain's signatures can be recovered.
* Only basic transformations can be recognized.
* Only specific software can recognize transformations.
''Effects:''
* Can restore the Original From:
* Overcome the security implications of l= by restricting the content type of the footer.

Latest revision as of 09:36, 22 February 2021

DMARC is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.

DMARC alignment requires that the From: line address in a mail message match either a DKIM signature d= domain, or an SPF-validated bounce address domain. Depending on a domain's published policy, unaligned mail may be quarantined, i.e., relegated to the spam folder, or rejected with a 5xx SMTP code by recipient systems. Mailing lists and other software that send legitimate but unaligned mail often find that mail rejected. Problems include recipients not getting the mail they want, and in some cases the normal list bounce processing removes the recipients from lists.

Sending side workarounds

Techniques which can be applied unilaterally by any operator that sends unaligned mail.

Exclude domains that require alignment

Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.

Effects:

  • Users in affected domains have to get new addresses or leave.
  • Operation otherwise unaffected.

Turn off all message modifications

Disable subject tags, message footers, and anything else that might break a DKIM signature.

Effects:

  • Still doesn't work for domains that validate mail with SPF.
  • Doesn't help mail-an-article.
  • Users can't recognize list mail by subject tags or anything else.
  • Sorting by subject tags doesn't work.
  • Often impractical when footers have required content.

Replace address with a generic one

Lists rewrite the From: line to use the list's address rather than the author's, either for all mail, or for mail from domains with policies.

Address may be moved into address comment, e.g.

From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org>

Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.

Effects:

  • Reply to author unavailable without Reply-To:
  • Address book techniques based on recognizing From: address don't work or work differently.
  • Author not visible in MUA message list.
  • Mail sorting rules don't work the same.
  • Encourages phishing by training users that address in the comment is equivalent to address.
  • Breaks S/MIME signatures

Add fixed string such as .invalid to addresses

Add a suffix to From: line addresses with policies.

From: Marissa <mmeyer@yahoo.com.invalid>

Effects:

  • Sorting rules might break depending on match details
  • Reply to author requires usenet-style demunging
  • Encourages phishing by training users that munged address is equivalent to address.
  • Breaks S/MIME signatures
  • Many mail systems reject mail if the From: address domain doesn't resolve.

Rewrite addresses to forwarding addresses

Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.

From: Marissa <mmeyer@yahoo.com.dmarc.fail>

From: Marissa <hash123@fwd.list.org>

Effects:

  • List function largely unchanged
  • Requires list operator to run a forwarder, which must be managed to avoid relaying spam
  • Forwarding addresses likely to end up in user address books, which means either the forwarder has to work forever or the address book entries will suffer bit rot. (Too bad no SMTP software supports 251 and 551 reply codes any more.)
  • Encourages phishing by training users that modified address is equivalent to address.
  • Breaks S/MIME signatures

Message wrapping

Wrap each message in an outer message, similar to single-message digests.

Effects:

  • Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions
  • May encourage phishing depending on how MUA displays message.

Mandatory digests

Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests

Effects:

  • All the usual reasons people don't like digests, mail is delayed until the digest is sent, replying to individual messages is harder, replying to the whole digest loses threads, etc.

Ignore DMARC bounces

Check for DMARC codes in bounce messages and disregard them for list management.

Effects:

  • Recipients lose mail
  • Bounces may affect list reputation and delivery

Author's domain side workarounds

Techniques that can be applied unilaterally by author's domains.

Third Party Authorization Label

With respect to RFC 6541, DKIM Authorized Third-Party Signatures, TPA-Label allows a domain to authorize other domains unilaterally; that is, without the need for mailing lists or other forwarders to claim they're signing on behalf of a given domain.

TPA-Label allows either a community or domain managed list of informally federated domains using a single and small DNS transaction. Deployment only requires the trusted domain and the system evaluating DMARC alignment to implement TPA-Label processing. Few third-party services will be required to make any changes.

TPA-Label helps direct which message element provides alignment and can signal when a domain is excluded from the federation for policy reasons. The exclusion circumvents repeated processing during review of DMARC feedback against outbound logs which is only done by the Trusted Domain (email provider).

See the Internet Draft.

Effects:

  • Messages by such authors won't be blocked even if the From: is left intact, assuming TPA-Label compliant recipients.

Recipient workarounds

Techniques that can be applied unilaterally by recipient systems and users.

Forwarder whitelist

The recipient system or perhaps each individual recipient maintains a list of IPs or DKIM signatures for mailing lists and other non-hostile forwarders. Probably wouldn't be absolute whitelist, just skip DMARC alignment check, due to spammers compromising users' accounts and sending spam to addresses in their address books, including lists to which they are subscribed.

Effects:

  • Lets forwarders work the way they always have.
  • A lot of work for recipient systems or users.
  • Unsophisticated users could mistakenly whitelist malicious senders.

Cooperative solutions

Techniques which need mutual cooperation in order to work.

Shared whitelist

Third party maintains DMARC-bypass whitelist of IPs and/or DKIM signatures of senders who send legitimate unaligned mail. Could probably seed with forwarders known to large mail systems. Probably wouldn't be absolute whitelist, just skip DMARC alignment check.

Effects:

  • Someone has to do it.
  • Eligible senders need to find out about it and apply, if not seeded.
  • Could allow more spam or phish depending on how careful forwarders are.

Per sender whitelist

Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.

Effects:

  • A lot of work for each sender
  • Large senders unlikely to know all of the third parties that their users use.

Original-Authentication-Results header

Remailers include a header reporting on the authentication of the incoming message. AR header is intended to detect spear-phishing if the remailer doesn't.

Effects:

  • Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)
  • List operation unaffected if it works.
  • Doesn't help mail-an-article.

Forwarding token

Original sender includes a header with a signed token that identifies the relay. See this conditional DKIM signature draft for a possible implementation.

Effects:

  • A variety of bad things if the relay is compromised or tries to play games.
  • Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)

Authorization approaches

Ways to get a DKIM author signature or something similar on the message.

Authenticated Received Chain (ARC)

ARC defines a chain of DKIM-like signatures applied by forwarders so that a receiving host can estimate whether a message was authenticated when it was sent. Currently under development by an IETF working group, with drafts of the protocol spec and a usage guide.

Effects:

  • No changes to user-visible parts of messages. If it works, mailing lists and other forwarders can continue working as they always have,
  • Proposed by large mail systems so they are likely to implement it.
  • ARC headers are easy to forge, so recipients have to track forwarder reputation before believing ARC headers.
  • Forwarders depend on recipients to implement it.

Signing key delegation

The author domain delegates a signing key to the list operator.

Effects:

  • Requires that mail providers trust the list operators.
  • Scales poorly since each list operator needs to get a key from each sending domain.

Relay through author domain server

Use API or SUBMIT to send mail through the author domain's server

Effects:

  • Requires a a password at each author domain
  • Web submission (mail and article) could use API and oauth to avoid disclosing password
  • Otherwise need users' password for SUBMIT
  • Author domain likely to force its own bounce address
  • Author domain likely to limit volume

Relay one copy through author domain server

As above, but send one copy back to the list to get signed, then remail that copy

Effects:

  • As above but avoids bounce address and volume issues
  • Only works if all recipients get the same message, not customized per-recipient

Have author domains sign camera-ready posts

The author domain runs a subset of the list software that carries out the changes as configured by each target list.

Effects:

  • List has to recognize camera-ready posts and avoid applying further changes in that case
  • List has to publish part of its configuration (specification)
  • Only works if all recipients get the same message, not customized per-recipient

Recognize message transformations

The most common transformations that mailing lists operate, namely the addition of a subject tag and of a message footer, the change of From:, and the possible change of encoding, can be recognized and undone, so as to validate the author domain's DKIM signature. To be recognized across transformation, an author domain's signature must be somewhat "mild". That is, use relaxed canonicalization, at least for the header, avoid signing key fields that mailing lists almost certainly rewrite (for example, Content-Type: and MIME-Version:), and possibly provide some auxiliary fields (for example, Original-Content-Transfer-Encoding:).

See draft-vesely-dmarc-mlm-transform.

Limits:

  • Only "mild" author domain's signatures can be recovered.
  • Only basic transformations can be recognized.
  • Only specific software can recognize transformations.

Effects:

  • Can restore the Original From:
  • Overcome the security implications of l= by restricting the content type of the footer.