Mitigating DMARC damage to third party mail: Difference between revisions
No edit summary |
(Divide into two sections) |
||
| Line 3: | Line 3: | ||
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 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 == | == ML-side workarounds == | ||
Techniques which can be applied by any mailing list operator unilaterally. | |||
=== 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 23: | Line 26: | ||
* Often impractical when footers have mandated content. | * Often impractical when footers have mandated 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 41: | Line 44: | ||
* 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. | ||
== 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 53: | Line 56: | ||
* Encourages phishing by training users that munged address is equivalent to address. | * Encourages phishing by training users that munged address is equivalent to address. | ||
== 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. | ||
| Line 67: | Line 70: | ||
* Encourages phishing by training users that modified address is equivalent to address. | * Encourages phishing by training users that modified address is equivalent to address. | ||
== 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 79: | ||
* 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 87: | ||
* 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 96: | ||
* Bounces may affect list reputation and delivery | * Bounces may affect list reputation and delivery | ||
== Shared whitelist == | == 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 103: | Line 109: | ||
* 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 | ||
| Line 112: | Line 118: | ||
* 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 == | === Original-Authentication-Results header === | ||
Remailers include a header reporting on the authentication of the incoming message | Remailers include a header reporting on the authentication of the incoming message | ||
| Line 121: | Line 127: | ||
* List operation unaffected if it works. | * List operation unaffected if it works. | ||
== Forwarding token == | === Forwarding token === | ||
Original sender includes a header with a signed token that identifies the relay. | Original sender includes a header with a signed token that identifies the relay. | ||
Revision as of 06:42, 1 June 2014
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.
ML-side workarounds
Techniques which can be applied by any mailing list operator unilaterally.
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.
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
Cooperative solutions
Techniques which need mutual cooperation in order to work.
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
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
Effects:
- Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)
- List operation unaffected if it works.
Forwarding token
Original sender includes a header with a signed token that identifies the relay.
Effects:
- A variety of bad things if the relay tries to play games.
- Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)
