Mitigating DMARC damage to third party mail

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.

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.

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
• Users can't recognize list mail by subject tags or anything else.
• Sorting by subject tags doesn't work.
• Often impractical when footers have mandated 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 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.

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.

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.email> 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
• Encourages phishing by training users that modified address is equivalent to address.

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.