https://wiki.asrg.sp.am/api.php?action=feedcontributions&user=Jrlevine&feedformat=atomASRG - User contributions [en]2024-03-28T13:05:27ZUser contributionsMediaWiki 1.41.0https://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1737Mitigating DMARC damage to third party mail2016-11-02T22:22:14Z<p>Jrlevine: </p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
* Many mail systems reject mail if the From: address domain doesn't resolve.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.fail></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].<br />
<br />
== Recipient workarounds ==<br />
<br />
Techniques that can be applied unilaterally by receipient systems and users.<br />
<br />
=== Forwarder whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Lets forwarders work the way they always have.<br />
* A lot of work for recipient systems or users.<br />
* Unsophisticated users could mistakenly whitelist malicious senders.<br />
<br />
== Cooperative solutions ==<br />
<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay. See this<br />
[https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ conditional DKIM signature draft] for a possible implementation.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature or something similar on the message.<br />
<br />
=== Authenticated Received Chain (ARC) ===<br />
<br />
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 <br />
[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].<br />
<br />
''Effects:''<br />
<br />
* No changes to user-visible parts of messages. If it works, mailing lists and other forwarders can continue working as they always have,<br />
* Proposed by large mail systems so they are likely to implement it.<br />
* ARC headers are easy to forge, so recipients have to track forwarder reputation before believing ARC headers<br />
* Forwarders depend on recipients to implement it.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list operator.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the list operators.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that copy<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume issues<br />
* Only works if all recipients get the same message, not customized per-recipient</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1736Mitigating DMARC damage to third party mail2016-11-02T22:11:34Z<p>Jrlevine: </p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
* Many mail systems reject mail if the From: address domain doesn't resolve.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.fail></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].<br />
<br />
== Recipient workarounds ==<br />
<br />
=== Forwarder whitelist ===<br />
<br />
The recipient system or perhaps each individual recipient maintains a list of IPs or DKIM signatures for mailing lists and other non-hostile forwarders.<br />
<br />
''Effects:''<br />
<br />
* Lets forwarders work the way they always have.<br />
* A lot of work for recipient systems or users.<br />
* Unsophisticated users could mistakenly whitelist malicious senders.<br />
<br />
== Cooperative solutions ==<br />
<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay. See this<br />
[https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ conditional DKIM signature draft] for a possible implementation.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature or something similar on the message.<br />
<br />
=== Authenticated Received Chain (ARC) ===<br />
<br />
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 <br />
[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].<br />
<br />
''Effects:''<br />
<br />
* No changes to user-visible parts of messages. If it works, mailing lists and other forwarders can continue working as they always have,<br />
* Proposed by large mail systems so they are likely to implement it.<br />
* ARC headers are easy to forge, so recipients have to track forwarder reputation before believing ARC headers<br />
* Forwarders depend on recipients to implement it.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list operator.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the list operators.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that copy<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume issues<br />
* Only works if all recipients get the same message, not customized per-recipient</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1735Mitigating DMARC damage to third party mail2016-11-02T22:07:10Z<p>Jrlevine: /* Authenticated Received Chain (ARC) */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
* Many mail systems reject mail if the From: address domain doesn't resolve.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.fail></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].<br />
<br />
== Cooperative solutions ==<br />
<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay. See this<br />
[https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ conditional DKIM signature draft] for a possible implementation.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature or something similar on the message.<br />
<br />
=== Authenticated Received Chain (ARC) ===<br />
<br />
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 <br />
[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].<br />
<br />
''Effects:''<br />
<br />
* No changes to user-visible parts of messages. If it works, mailing lists and other forwarders can continue working as they always have,<br />
* Proposed by large mail systems so they are likely to implement it.<br />
* ARC headers are easy to forge, so recipients have to track forwarder reputation before believing ARC headers<br />
* Forwarders depend on recipients to implement it.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list operator.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the list operators.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that copy<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume issues<br />
* Only works if all recipients get the same message, not customized per-recipient</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1734Mitigating DMARC damage to third party mail2016-11-02T22:03:42Z<p>Jrlevine: /* Rewrite addresses to forwarding addresses */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
* Many mail systems reject mail if the From: address domain doesn't resolve.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.fail></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].<br />
<br />
== Cooperative solutions ==<br />
<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay. See this<br />
[https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ conditional DKIM signature draft] for a possible implementation.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature or something similar on the message.<br />
<br />
=== Authenticated Received Chain (ARC) ===<br />
<br />
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<br />
[https://datatracker.ietf.org/doc/draft-andersen-arc/ in draft form] with a [https://datatracker.ietf.org/doc/draft-jones-arc-usage/ draft usage guide].<br />
<br />
''Effects:''<br />
<br />
* No changes to user-visible parts of messages. If it works, mailing lists and other forwarders can continue working as they always have,<br />
* Proposed by large mail systems so they are likely to implement it.<br />
* ARC headers are easy to forge, so recipients have to track forwarder reputation before believing ARC headers<br />
* Forwarders depend on recipients to implement it.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list operator.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the list operators.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that copy<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume issues<br />
* Only works if all recipients get the same message, not customized per-recipient</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1733Mitigating DMARC damage to third party mail2016-02-07T21:22:28Z<p>Jrlevine: /* Authenticated Received Chain (ARC) */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
* Many mail systems reject mail if the From: address domain doesn't resolve.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].<br />
<br />
== Cooperative solutions ==<br />
<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay. See this<br />
[https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ conditional DKIM signature draft] for a possible implementation.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature or something similar on the message.<br />
<br />
=== Authenticated Received Chain (ARC) ===<br />
<br />
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<br />
[https://datatracker.ietf.org/doc/draft-andersen-arc/ in draft form] with a [https://datatracker.ietf.org/doc/draft-jones-arc-usage/ draft usage guide].<br />
<br />
''Effects:''<br />
<br />
* No changes to user-visible parts of messages. If it works, mailing lists and other forwarders can continue working as they always have,<br />
* Proposed by large mail systems so they are likely to implement it.<br />
* ARC headers are easy to forge, so recipients have to track forwarder reputation before believing ARC headers<br />
* Forwarders depend on recipients to implement it.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list operator.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the list operators.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that copy<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume issues<br />
* Only works if all recipients get the same message, not customized per-recipient</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1732Mitigating DMARC damage to third party mail2016-02-07T21:21:21Z<p>Jrlevine: /* Authenticated Received Chain (ARC) */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
* Many mail systems reject mail if the From: address domain doesn't resolve.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].<br />
<br />
== Cooperative solutions ==<br />
<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay. See this<br />
[https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ conditional DKIM signature draft] for a possible implementation.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature or something similar on the message.<br />
<br />
=== Authenticated Received Chain (ARC) ===<br />
<br />
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<br />
[https://datatracker.ietf.org/doc/draft-andersen-arc/ in draft form] with a [https://datatracker.ietf.org/doc/draft-jones-arc-usage/ draft usage guide].<br />
<br />
''Pros:''<br />
<br />
* No changes to user-visible parts of messages. If it works, mailing lists and other forwarders can continue working as they always have,<br />
* Proposed by large mail systems so they are likely to implement it.<br />
<br />
''Cons:''<br />
<br />
* ARC headers are easy to forge, so recipients have to track forwarder reputation before believing ARC headers<br />
* Forwarders depend on recipients to implement it.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list operator.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the list operators.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that copy<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume issues<br />
* Only works if all recipients get the same message, not customized per-recipient</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1731Mitigating DMARC damage to third party mail2016-02-07T21:19:41Z<p>Jrlevine: /* Authenticated Received Chain (ARC) */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
* Many mail systems reject mail if the From: address domain doesn't resolve.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].<br />
<br />
== Cooperative solutions ==<br />
<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay. See this<br />
[https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ conditional DKIM signature draft] for a possible implementation.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature or something similar on the message.<br />
<br />
=== Authenticated Received Chain (ARC) ===<br />
<br />
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 in draft form at<br />
https://datatracker.ietf.org/doc/draft-andersen-arc/ with a draft usage guide at https://datatracker.ietf.org/doc/draft-jones-arc-usage/<br />
<br />
''Pros:''<br />
<br />
* No changes to user-visible parts of messages. If it works, mailing lists and other forwarders can continue working as they always have,<br />
* Proposed by large mail systems so they are likely to implement it.<br />
<br />
''Cons:''<br />
<br />
* ARC headers are easy to forge, so recipients have to track forwarder reputation before believing ARC headers<br />
* Forwarders depend on recipients to implement it.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list operator.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the list operators.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that copy<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume issues<br />
* Only works if all recipients get the same message, not customized per-recipient</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1730Mitigating DMARC damage to third party mail2016-02-07T21:17:22Z<p>Jrlevine: /* Authorization approaches */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
* Many mail systems reject mail if the From: address domain doesn't resolve.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].<br />
<br />
== Cooperative solutions ==<br />
<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay. See this<br />
[https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ conditional DKIM signature draft] for a possible implementation.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature or something similar on the message.<br />
<br />
=== Authenticated Received Chain (ARC) ===<br />
<br />
ARC applies 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 in draft form at<br />
https://datatracker.ietf.org/doc/draft-andersen-arc/ with a draft usage guide at https://datatracker.ietf.org/doc/draft-jones-arc-usage/<br />
<br />
''Pros:''<br />
<br />
* No changes to user-visible parts of messages. If it works, mailing lists and other forwarders can continue working as they always have,<br />
* Proposed by large mail systems so they are likely to implement it.<br />
<br />
''Cons:''<br />
<br />
* ARC headers are easy to forge, so recipients have to track forwarder reputation before believing ARC headers<br />
* Forwarders depend on recipients to implement it.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list operator.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the list operators.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that copy<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume issues<br />
* Only works if all recipients get the same message, not customized per-recipient</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1729Mitigating DMARC damage to third party mail2016-02-07T20:29:27Z<p>Jrlevine: /* Add fixed string such as .invalid to addresses */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
* Many mail systems reject mail if the From: address domain doesn't resolve.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].<br />
<br />
== Cooperative solutions ==<br />
<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay. See this<br />
[https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ conditional DKIM signature draft] for a possible implementation.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature on the message.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list operator.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the list operators.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that copy<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume issues<br />
* Only works if all recipients get the same message, not customized per-recipient</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=BCP_for_DNSBLs&diff=1728BCP for DNSBLs2015-12-17T18:24:09Z<p>Jrlevine: </p>
<hr />
<div>This document has now been published as RFC 6471.</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Greylisting&diff=1725Greylisting2015-03-04T22:48:24Z<p>Jrlevine: </p>
<hr />
<div>{{ast<br />
|date=early 2000s<br />
|difficult=Medium<br />
|popular=Low, increasing<br />
|effective=Medium<br />
|where=MTA<br />
|harm=Low<br />
}}<br />
<br />
Greylisting (AKA graylisting) is an extremely effective method against illegitimate spammers who use cracked PCs (botnets, for example) to send the spam. It is utterly ineffective against spamers sending from conforming conventional MTAs.<br />
<br />
SMTP requires clients to maintain a queue of outgoing messages. During a delivery attempt, a 4xx response code indicates a temporary failure. The client system must then retry the message. See RFC 2821 Section 4.5.4. Clients can immediately try another host listed in an MX record for the target domain, or re-queue the message and try again later. When the message is re-queued, the RFC says the client SHOULD wait at least 30 minutes before the next delivery attempt, and generally should use progressively larger delays for each subsequent retry attempt.<br />
<br />
Greylisting attempts to detect SMTP client systems that are not true SMTP servers and do not maintain a message queue, instead using a "blast and dump" approach.<br />
<br />
Greylisting operates by initially deferring incoming messages by giving a 4xx (temporary failure) response during the smtp protocol dialogue. The receiving MTA stores information about the attempted delivery, at minimum the client SMTP system's IP address, but in some implementations also the envelope sender address and envelope recipient address, and in a few cases a hash of the message body. Some systems remember (IP, to, from), sometimes known as a ''triplet''.<br />
<br />
If a new delivery attempt matching the stored client information (that is, the same IP address or the same triplet) arrives within the minimum delay time enforced by the receiving MTA, the retry is also rejected and the minimum delay time reset. If the retry arrives after the minimum delay time, the message is accepted and the saved data is marked so that subsequent attempts which match the saved data are immediately accepted with no delay. Depending on the implementation, subsequent attempts need only match the IP address of the client SMTP system, or the entire triplet.<br />
<br />
While effective against certain kinds of spam, the technique has its drawbacks:<br />
* greylisted messages are initially delayed, possibly for hours or days<br />
* problems with outbound server pools that retry with different IPs<br />
* problems with inbound server pools that accept connections on multiple IPs<br />
* problems when the retry time of the sending system is smaller than the minimum retry time enforced by the receiving system (note that RFC 2821 says that the 30 minute delay is a SHOULD, not a MUST)<br />
* long delays when the retry time of the sending system is too long - some big ISPs set this value to values bigger than 4 hours and even a day.<br />
* unwanted interactions with servers doing callbacks<br />
* extra burden on the sending MTAs<br />
<br />
A few legitimate mail clients don't work with greylisting, either because they don't retry, or they retry in a way that the greylisting server doesn't recognize. Often, whitelist tables of such hosts need to be maintained.<br />
<br />
=== References ===<br />
<br />
* M. Kucherawy and D. Crocker, Email Greylisting: An Applicability Statement for SMTP", RFC 6647</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Greylisting&diff=1724Greylisting2015-03-04T22:47:53Z<p>Jrlevine: </p>
<hr />
<div>{{ast<br />
|date=early 2000s<br />
|difficult=Medium<br />
|popular=Low, increasing<br />
|effective=Medium<br />
|where=MTA<br />
|harm=Low<br />
}}<br />
<br />
Greylisting (AKA graylisting) is an extremely effective method against illegitimate spammers who use cracked PCs (botnets, for example) to send the spam. It is utterly ineffective against spamers sending from conforming conventional MTAs.<br />
<br />
SMTP requires clients to maintain a queue of outgoing messages. During a delivery attempt, a 4xx response code indicates a temporary failure. The client system must then retry the message. See RFC 2821 Section 4.5.4. Clients can immediately try another host listed in an MX record for the target domain, or re-queue the message and try again later. When the message is re-queued, the RFC says the client SHOULD wait at least 30 minutes before the next delivery attempt, and generally should use progressively larger delays for each subsequent retry attempt.<br />
<br />
Greylisting attempts to detect SMTP client systems that are not true SMTP servers and do not maintain a message queue, instead using a "blast and dump" approach.<br />
<br />
Greylisting operates by initially deferring incoming messages by giving a 4xx (temporary failure) response during the smtp protocol dialogue. The receiving MTA stores information about the attempted delivery, at minimum the client SMTP system's IP address, but in some implementations also the envelope sender address and envelope recipient address, and in a few cases a hash of the message body. Some systems remember (IP, to, from), sometimes known as a ''triplet''.<br />
<br />
If a new delivery attempt matching the stored client information (that is, the same IP address or the same triplet) arrives within the minimum delay time enforced by the receiving MTA, the retry is also rejected and the minimum delay time reset. If the retry arrives after the minimum delay time, the message is accepted and the saved data is marked so that subsequent attempts which match the saved data are immediately accepted with no delay. Depending on the implementation, subsequent attempts need only match the IP address of the client SMTP system, or the entire triplet.<br />
<br />
While effective against certain kinds of spam, the technique has its drawbacks:<br />
* greylisted messages are initially delayed, possibly for hours or days<br />
* problems with outbound server pools that retry with different IPs<br />
* problems with inbound server pools that accept connections on multiple IPs<br />
* problems when the retry time of the sending system is smaller than the minimum retry time enforced by the receiving system (note that RFC 2821 says that the 30 minute delay is a SHOULD, not a MUST)<br />
* long delays when the retry time of the sending system is too long - some big ISPs set this value to values bigger than 4 hours and even a day.<br />
* unwanted interactions with servers doing callbacks<br />
* extra burden on the sending MTAs<br />
<br />
A few legitimate mail clients don't work with greylisting, either because they don't retry, or they retry in a way that the greylisting server doesn't recognize. Often, whitelist tables of such hosts need to be maintained.<br />
<br />
== References __<br />
<br />
* M. Kucherawy and D. Crocker, Email Greylisting: An Applicability Statement for SMTP", RFC 6647</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Greylisting&diff=1723Greylisting2015-03-04T22:47:22Z<p>Jrlevine: </p>
<hr />
<div>{{ast<br />
|date=early 2000s<br />
|difficult=Medium<br />
|popular=Low, increasing<br />
|effective=Medium<br />
|where=MTA<br />
|harm=Low<br />
}}<br />
<br />
Greylisting (AKA graylisting) is an extremely effective method against illegitimate spammers who use cracked PCs (botnets, for example) to send the spam. It is utterly ineffective against spamers sending from conforming conventional MTAs.<br />
<br />
SMTP requires clients to maintain a queue of outgoing messages. During a delivery attempt, a 4xx response code indicates a temporary failure. The client system must then retry the message. See RFC 2821 Section 4.5.4. Clients can immediately try another host listed in an MX record for the target domain, or re-queue the message and try again later. When the message is re-queued, the RFC says the client SHOULD wait at least 30 minutes before the next delivery attempt, and generally should use progressively larger delays for each subsequent retry attempt.<br />
<br />
Greylisting attempts to detect SMTP client systems that are not true SMTP servers and do not maintain a message queue, instead using a "blast and dump" approach.<br />
<br />
Greylisting operates by initially deferring incoming messages by giving a 4xx (temporary failure) response during the smtp protocol dialogue. The receiving MTA stores information about the attempted delivery, at minimum the client SMTP system's IP address, but in some implementations also the envelope sender address and envelope recipient address, and in a few cases a hash of the message body. Some systems remember (IP, to, from), sometimes known as a ''triplet''.<br />
<br />
If a new delivery attempt matching the stored client information (that is, the same IP address or the same triplet) arrives within the minimum delay time enforced by the receiving MTA, the retry is also rejected and the minimum delay time reset. If the retry arrives after the minimum delay time, the message is accepted and the saved data is marked so that subsequent attempts which match the saved data are immediately accepted with no delay. Depending on the implementation, subsequent attempts need only match the IP address of the client SMTP system, or the entire triplet.<br />
<br />
While effective against certain kinds of spam, the technique has its drawbacks:<br />
* greylisted messages are initially delayed, possibly for hours or days<br />
* problems with outbound server pools that retry with different IPs<br />
* problems with inbound server pools that accept connections on multiple IPs<br />
* problems when the retry time of the sending system is smaller than the minimum retry time enforced by the receiving system (note that RFC 2821 says that the 30 minute delay is a SHOULD, not a MUST)<br />
* long delays when the retry time of the sending system is too long - some big ISPs set this value to values bigger than 4 hours and even a day.<br />
* unwanted interactions with servers doing callbacks<br />
* extra burden on the sending MTAs<br />
<br />
A few legitimate mail clients don't work with greylisting, either because they don't retry, or they retry in a way that the greylisting server doesn't recognize. Often, whitelist tables of such hosts need to be maintained.<br />
<br />
== References __<br />
<br />
* M. Kucherawy and D. Crocker, Email Greylisting: An Applicability Statement for SMTP", {{RFC 6647| rfc6647}}</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Indirect_mail_flows_and_DMARC&diff=1722Indirect mail flows and DMARC2014-09-18T08:37:39Z<p>Jrlevine: Created page with "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 add..."</p>
<hr />
<div>DMARC is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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. A variety of long standing mail practices often create unaligned mail.<br />
<br />
== Forwarding ==<br />
<br />
* discussion mailing lists<br />
* annotating forwarders<br />
* annotating anti-virus<br />
<br />
== Third party origination ==<br />
<br />
* Newspaper mail-an-article<br />
* Small clients at ESPs<br />
* Notifications from devices</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Main_Page&diff=1721Main Page2014-09-18T08:32:31Z<p>Jrlevine: /* Projects */</p>
<hr />
<div>= The Anti Spam Research Group wiki =<br />
<br />
== Projects ==<br />
<br />
* [[Taxonomy of anti-spam techniques]]<br />
* [[Taxonomy of spamming techniques]]<br />
* [[Description of DNSBLs]]<br />
* [[BCP for DNSBLs]]<br />
* [[Assessing anti-spam techniques]]<br />
* [[Adding a junk button to MUAs]]<br />
* [[Indirect mail flows and DMARC]]<br />
* [[Mitigating DMARC damage to third party mail]]<br />
<br />
== Events and Notes ==<br />
<br />
* [[ASRG at IETF 71]]<br />
<br />
* [[ASRG at IETF 72]]<br />
<br />
* [[Interesting Papers]] mentioned in ASRG discussions<br />
<br />
== Mailing List ==<br />
<br />
Like all IRTF groups, the ASRG operated primarily by e-mail. There is still an ASRG mailing list, although it's no longer at the IRTF.<br />
<br />
== Access ==<br />
<br />
ASRG members can edit this wiki. Send a request by e-mail to [[mailto:chair@asrg.sp.am chair@asrg.sp.am]] to get an account. <br />
<br />
If you want to edit this wiki, please also join the [[http://lists.services.net/cgi-bin/mj_wwwusr/domain=lists.gurus.org ASRG mailing list]].</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1720Mitigating DMARC damage to third party mail2014-07-21T02:50:31Z<p>Jrlevine: /* Add fixed string such as .invalid to addresses */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
* Some mail systems (Yahoo) reject mail if the From: address domain doesn't resolve.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].<br />
<br />
== Cooperative solutions ==<br />
<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay. See this<br />
[https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ conditional DKIM signature draft] for a possible implementation.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature on the message.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list operator.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the list operators.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that copy<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume issues<br />
* Only works if all recipients get the same message, not customized per-recipient</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1719Mitigating DMARC damage to third party mail2014-07-21T02:50:18Z<p>Jrlevine: /* Add fixed string such as .invalid to addresses */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
* Some mail systems (Yahoo) reject mail if the From: address domain doesn't resolve. That can be avoided by using a suffix domain with a wildcard, but then you have the issue of what to do with the mail sent to it.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].<br />
<br />
== Cooperative solutions ==<br />
<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay. See this<br />
[https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ conditional DKIM signature draft] for a possible implementation.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature on the message.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list operator.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the list operators.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that copy<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume issues<br />
* Only works if all recipients get the same message, not customized per-recipient</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1718Mitigating DMARC damage to third party mail2014-07-21T02:47:59Z<p>Jrlevine: </p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].<br />
<br />
== Cooperative solutions ==<br />
<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay. See this<br />
[https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ conditional DKIM signature draft] for a possible implementation.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature on the message.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list operator.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the list operators.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that copy<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume issues<br />
* Only works if all recipients get the same message, not customized per-recipient</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1717Mitigating DMARC damage to third party mail2014-06-19T16:20:35Z<p>Jrlevine: </p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].<br />
<br />
== Cooperative solutions ==<br />
<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.) O<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay. See this<br />
[https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ conditional DKIM signature draft] for a possible implementation.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature on the message.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list operator.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the list operators.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that copy<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume issues<br />
* Only works if all recipients get the same message, not customized per-recipient</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1716Mitigating DMARC damage to third party mail2014-06-19T16:19:58Z<p>Jrlevine: /* Replace address with a generic one */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
* Breaks S/MIME signatures<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].<br />
<br />
== Cooperative solutions ==<br />
<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.) O<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay. See this<br />
[https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ conditional DKIM signature draft] for a possible implementation.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature on the message.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list operator.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the list operators.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that copy<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume issues<br />
* Only works if all recipients get the same message, not customized per-recipient</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1715Mitigating DMARC damage to third party mail2014-06-19T16:16:40Z<p>Jrlevine: /* Forwarding token */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].<br />
<br />
== Cooperative solutions ==<br />
<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.) O<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay. See this<br />
[https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ conditional DKIM signature draft] for a possible implementation.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature on the message.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list operator.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the list operators.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that copy<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume issues<br />
* Only works if all recipients get the same message, not customized per-recipient</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1714Mitigating DMARC damage to third party mail2014-06-16T19:18:25Z<p>Jrlevine: /* Relay one copy through author domain server */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].<br />
<br />
== Cooperative solutions ==<br />
<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.) O<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature on the message.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list operator.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the list operators.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that copy<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume issues<br />
* Only works if all recipients get the same message, not customized per-recipient</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1713Mitigating DMARC damage to third party mail2014-06-10T07:47:58Z<p>Jrlevine: </p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].<br />
<br />
== Cooperative solutions ==<br />
<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.) O<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature on the message.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list operator.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the list operators.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that copy<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume issues</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1712Mitigating DMARC damage to third party mail2014-06-10T07:46:03Z<p>Jrlevine: /* Relay one copy through author domain server */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
== Cooperative solutions ==<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.) O<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature on the message.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the lists.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that copy<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume issues<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1711Mitigating DMARC damage to third party mail2014-06-10T07:45:11Z<p>Jrlevine: /* Signing key delegation */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
== Cooperative solutions ==<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.) O<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature on the message.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the lists.<br />
* Scales poorly since each list operator needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume <br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1710Mitigating DMARC damage to third party mail2014-06-10T07:24:15Z<p>Jrlevine: </p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
== Cooperative solutions ==<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.) O<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
== Authorization approaches ==<br />
<br />
Ways to get a DKIM author signature on the message.<br />
<br />
=== Signing key delegation ===<br />
<br />
The author domain delegates a signing key to the list.<br />
<br />
''Effects:''<br />
<br />
* Requires that mail providers trust the lists.<br />
* Scales poorly since each list needs to get a key from each sending domain.<br />
<br />
=== Relay through author domain server ===<br />
<br />
Use API or SUBMIT to send mail through the author domain's server<br />
<br />
''Effects:''<br />
<br />
* Requires a a password at each author domain<br />
* Web submission (mail and article) could use API and oauth to avoid disclosing password<br />
* Otherwise need users' password for SUBMIT<br />
* Author domain likely to force its own bounce address<br />
* Author domain likely to limit volume<br />
<br />
=== Relay one copy through author domain server ===<br />
<br />
As above, but send one copy back to the list to get signed, then remail that<br />
<br />
''Effects:''<br />
<br />
* As above but avoids bounce address and volume <br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1709Mitigating DMARC damage to third party mail2014-06-04T03:30:10Z<p>Jrlevine: /* Original-Authentication-Results header */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
== Cooperative solutions ==<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.) O<br />
* List operation unaffected if it works.<br />
* Doesn't help mail-an-article.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1708Mitigating DMARC damage to third party mail2014-06-04T03:29:48Z<p>Jrlevine: /* Original-Authentication-Results header */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
== Cooperative solutions ==<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.) O<br />
* List operation unaffected if it works.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1707Mitigating DMARC damage to third party mail2014-06-03T00:28:48Z<p>Jrlevine: /* Third Party Access */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
== Cooperative solutions ==<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
Remailers include a header reporting on the authentication of the incoming message<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.) OAR header is intended to detect spear-phishing if the remailer doesn't.<br />
* List operation unaffected if it works.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
=== Third Party Authorization ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/html/draft-otis-tpa-label the Internet Draft].</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1706Mitigating DMARC damage to third party mail2014-06-02T23:05:16Z<p>Jrlevine: /* Cooperative solutions */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
== Cooperative solutions ==<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
Remailers include a header reporting on the authentication of the incoming message<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.) OAR header is intended to detect spear-phishing if the remailer doesn't.<br />
* List operation unaffected if it works.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)<br />
<br />
=== Third Party Access ===<br />
<br />
TPA is intended to replace RFC 6541 third-party signatures<br />
<br />
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.<br />
<br />
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). <br />
<br />
See [http://tools.ietf.org/id/draft-otis-tpa-label-03.html the Internet Draft].</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1705Mitigating DMARC damage to third party mail2014-06-02T00:33:39Z<p>Jrlevine: </p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Sending side workarounds ==<br />
Techniques which can be applied unilaterally by any operator that sends unaligned mail.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF.<br />
* Doesn't help mail-an-article.<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have required content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for Marissa mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
== Cooperative solutions ==<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
Remailers include a header reporting on the authentication of the incoming message<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)<br />
* List operation unaffected if it works.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay is compromised or tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1704Mitigating DMARC damage to third party mail2014-06-01T15:43:26Z<p>Jrlevine: </p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== ML-side workarounds ==<br />
Techniques which can be applied by any mailing list operator unilaterally.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have mandated content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
== Cooperative solutions ==<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
Remailers include a header reporting on the authentication of the incoming message<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)<br />
* List operation unaffected if it works.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1703Mitigating DMARC damage to third party mail2014-06-01T15:42:32Z<p>Jrlevine: /* Rewrite addresses to forwarding addresses */</p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== ML-side workarounds ==<br />
Techniques which can be applied by any mailing list operator unilaterally.<br />
<br />
=== Exclude domains that require alignment ===<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
=== Turn off all message modifications ===<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have mandated content.<br />
<br />
=== Replace address with a generic one ===<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
<br />
=== Add fixed string such as .invalid to addresses ===<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
=== Rewrite addresses to forwarding addresses ===<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* 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.)<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
=== Message wrapping ===<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
=== Mandatory digests ===<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
=== Ignore DMARC bounces ===<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
== Cooperative solutions ==<br />
Techniques which need mutual cooperation in order to work.<br />
<br />
=== Shared whitelist ===<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
=== Per sender whitelist ===<br />
<br />
Senders publish list of DKIM signatures allowed to send for them, like in RFC 6541.<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
=== Original-Authentication-Results header ===<br />
<br />
Remailers include a header reporting on the authentication of the incoming message<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)<br />
* List operation unaffected if it works.<br />
<br />
=== Forwarding token ===<br />
<br />
Original sender includes a header with a signed token that identifies the relay.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1700Mitigating DMARC damage to third party mail2014-06-01T04:32:16Z<p>Jrlevine: </p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Exclude domains that require alignment ==<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
== Turn off all message modifications ==<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have mandated content.<br />
<br />
== Replace address with a generic one ==<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
<br />
== Add fixed string such as .invalid to addresses ==<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
== Rewrite addresses to forwarding addresses ==<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
== Message wrapping ==<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
== Mandatory digests ==<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
== Ignore DMARC bounces ==<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
== Shared whitelist ==<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligible senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
== Per sender whitelist ==<br />
<br />
Senders publish list of DKIM signatures allowed to send for them<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
== Original-Authentication-Results header ==<br />
<br />
Remailers include a header reporting on the authentication of the incoming message<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)<br />
* List operation unaffected if it works.<br />
<br />
== Forwarding token ==<br />
<br />
Original sender includes a header with a signed token that identifies the relay.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1699Mitigating DMARC damage to third party mail2014-06-01T04:25:13Z<p>Jrlevine: </p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Exclude domains that require alignment ==<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
== Turn off all message modifications ==<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have mandated content.<br />
<br />
== Replace address with a generic one ==<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
<br />
== Add fixed string such as .invalid to addresses ==<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
== Rewrite addresses to forwarding addresses ==<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
== Message wrapping ==<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
== Mandatory digests ==<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
== Ignore DMARC bounces ==<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
== Shared whitelist ==<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligble senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
== Per sender whitelist ==<br />
<br />
Senders publish list of DKIM signatures allowed to send for them<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
== Original-Authentication-Results header ==<br />
<br />
Remailers include a header reporting on the authentication of the incoming message<br />
<br />
''Effects:''<br />
<br />
* Since the header is trivially forgable, recipients have to know who to trust. (See whitelist above.)<br />
* List operation unaffected if it works.<br />
<br />
== Forwarding token ==<br />
<br />
Original sender includes a header with a signed token that identifies the relay.<br />
<br />
''Effects:''<br />
<br />
* A variety of bad things if the relay tries to play games.<br />
* Senders will probably only want to include them in mail to trustworthy relays. (See whitelist above.)</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1698Mitigating DMARC damage to third party mail2014-06-01T04:18:28Z<p>Jrlevine: </p>
<hr />
<div>[http://www.dmarc.org DMARC] is an anti-phishing technology. It has recently been repurposed by large mail providers for public webmail domains.<br />
<br />
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.<br />
<br />
== Exclude domains that require alignment ==<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
== Turn off all message modifications ==<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have mandated content.<br />
<br />
== Replace address with a generic one ==<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
<br />
== Add fixed string such as .invalid to addresses ==<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
== Rewrite addresses to forwarding addresses ==<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
== Message wrapping ==<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
== Mandatory digests ==<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
== Ignore DMARC bounces ==<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
== Shared whitelist ==<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligble senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
== Per sender whitelist ==<br />
<br />
Senders publish list of DKIM signatures allowed to send for them<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.<br />
<br />
== Original-<br />
<br />
Domains with policies include a header</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1697Mitigating DMARC damage to third party mail2014-06-01T04:14:59Z<p>Jrlevine: </p>
<hr />
<div>[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.<br />
<br />
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.<br />
<br />
== Exclude domains that require alignment ==<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
== Turn off all message modifications ==<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have mandated content.<br />
<br />
== Replace address with a generic one ==<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
<br />
== Add fixed string such as .invalid to addresses ==<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
== Rewrite addresses to forwarding addresses ==<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
== Message wrapping ==<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.<br />
<br />
== Mandatory digests ==<br />
<br />
Require all users, or users on recipient systems that enforce DMARC, to get list mail as digests<br />
<br />
''Effects:''<br />
<br />
* 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.<br />
<br />
== Ignore DMARC bounces ==<br />
<br />
Check for DMARC codes in bounce messages and disregard them for list management.<br />
<br />
''Effects:''<br />
<br />
* Recipients lose mail<br />
* Bounces may affect list reputation and delivery<br />
<br />
== Shared whitelist ==<br />
<br />
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.<br />
<br />
''Effects:''<br />
<br />
* Someone has to do it.<br />
* Eligble senders need to find out about it and apply, if not seeded.<br />
* Could allow more spam or phish depending on how careful forwarders are.<br />
<br />
== Per sender whitelist ==<br />
<br />
Senders publish list of DKIM signatures allowed to send for them<br />
<br />
''Effects:''<br />
<br />
* A lot of work for each sender<br />
* Large senders unlikely to know all of the third parties that their users use.</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1696Mitigating DMARC damage to third party mail2014-06-01T03:56:18Z<p>Jrlevine: </p>
<hr />
<div>[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.<br />
<br />
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.<br />
<br />
== Exclude domains that require alignment ==<br />
<br />
Check the DMARC policy on incoming mail, and refuse mail from domains with quarantine or reject polcies.<br />
<br />
''Effects:'' <br />
<br />
* Users in affected domains have to get new addresses or leave.<br />
* Operation otherwise unaffected.<br />
<br />
== Turn off all message modifications ==<br />
<br />
Disable subject tags, message footers, and anything else that might break a DKIM signature.<br />
<br />
''Effects:''<br />
<br />
* Still doesn't work for domains that validate mail with SPF<br />
* Users can't recognize list mail by subject tags or anything else.<br />
* Sorting by subject tags doesn't work.<br />
* Often impractical when footers have mandated content.<br />
<br />
== Replace address with a generic one ==<br />
<br />
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.<br />
<br />
Address may be moved into address comment, e.g.<br />
<br />
<code>From: foo list for mmeyer-at-yahoo.com <foo@list.org></code><br />
<br />
Author's address may be placed in a Reply-To: header, give or take the usual issues about lists and Reply-To.<br />
<br />
''Effects:''<br />
<br />
* Reply to author unavailable without Reply-To:<br />
* Address book techniques based on recognizing From: address don't work or work differently.<br />
* Author not visible in MUA message list.<br />
* Mail sorting rules don't work the same.<br />
* Encourages phishing by training users that address in the comment is equivalent to address.<br />
<br />
== Add fixed string such as .invalid to addresses ==<br />
<br />
Add a suffix to From: line addresses with policies.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.invalid></code><br />
<br />
''Effects:''<br />
<br />
* Sorting rules might break depending on match details<br />
* Reply to author requires usenet-style demunging<br />
* Encourages phishing by training users that munged address is equivalent to address.<br />
<br />
== Rewrite addresses to forwarding addresses ==<br />
<br />
Rewrite addresses to a valid address that will forward to the original address, either using a wildcard domain suffix or a pseudorandom address.<br />
<br />
<code>From: Marissa <mmeyer@yahoo.com.dmarc.email></code><br />
<code>From: Marissa <hash123@fwd.list.org></code><br />
<br />
''Effects:''<br />
<br />
* List function largely unchanged<br />
* Requires list operator to run a forwarder, which must be managed to avoid relaying spam<br />
* Encourages phishing by training users that modified address is equivalent to address.<br />
<br />
== Message wrapping ==<br />
<br />
Wrap each message in an outer message, similar to single-message digests.<br />
<br />
''Effects:''<br />
<br />
* Looks like digests to users unless they have (so far nonexistent) MUA unwrapping extensions<br />
* May encourage phishing depending on how MUA displays message.</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Mitigating_DMARC_damage_to_third_party_mail&diff=1695Mitigating DMARC damage to third party mail2014-06-01T03:18:57Z<p>Jrlevine: Created page with "[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 th..."</p>
<hr />
<div>[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.<br />
<br />
DMARC <i>alignment</i> requires that the From: line address in a mail message match either a DKIM signature d= domain, or an SPF-validated bounce address domain. 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.</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Main_Page&diff=1694Main Page2014-06-01T03:08:24Z<p>Jrlevine: /* Projects */</p>
<hr />
<div>= The Anti Spam Research Group wiki =<br />
<br />
== Projects ==<br />
<br />
* [[Taxonomy of anti-spam techniques]]<br />
* [[Taxonomy of spamming techniques]]<br />
* [[Description of DNSBLs]]<br />
* [[BCP for DNSBLs]]<br />
* [[Assessing anti-spam techniques]]<br />
* [[Adding a junk button to MUAs]]<br />
* [[Mitigating DMARC damage to third party mail]]<br />
<br />
== Events and Notes ==<br />
<br />
* [[ASRG at IETF 71]]<br />
<br />
* [[ASRG at IETF 72]]<br />
<br />
* [[Interesting Papers]] mentioned in ASRG discussions<br />
<br />
== Mailing List ==<br />
<br />
Like all IRTF groups, the ASRG operated primarily by e-mail. There is still an ASRG mailing list, although it's no longer at the IRTF.<br />
<br />
== Access ==<br />
<br />
ASRG members can edit this wiki. Send a request by e-mail to [[mailto:chair@asrg.sp.am chair@asrg.sp.am]] to get an account. <br />
<br />
If you want to edit this wiki, please also join the [[http://lists.services.net/cgi-bin/mj_wwwusr/domain=lists.gurus.org ASRG mailing list]].</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Main_Page&diff=1692Main Page2014-01-06T21:02:54Z<p>Jrlevine: </p>
<hr />
<div>= The Anti Spam Research Group wiki =<br />
<br />
== Projects ==<br />
<br />
* [[Taxonomy of anti-spam techniques]]<br />
* [[Taxonomy of spamming techniques]]<br />
* [[Description of DNSBLs]]<br />
* [[BCP for DNSBLs]]<br />
* [[Assessing anti-spam techniques]]<br />
* [[Adding a junk button to MUAs]]<br />
<br />
== Events and Notes ==<br />
<br />
* [[ASRG at IETF 71]]<br />
<br />
* [[ASRG at IETF 72]]<br />
<br />
* [[Interesting Papers]] mentioned in ASRG discussions<br />
<br />
== Mailing List ==<br />
<br />
Like all IRTF groups, the ASRG operated primarily by e-mail. There is still an ASRG mailing list, although it's no longer at the IRTF.<br />
<br />
== Access ==<br />
<br />
ASRG members can edit this wiki. Send a request by e-mail to [[mailto:chair@asrg.sp.am chair@asrg.sp.am]] to get an account. <br />
<br />
If you want to edit this wiki, please also join the [[http://lists.services.net/cgi-bin/mj_wwwusr/domain=lists.gurus.org ASRG mailing list]].</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Postage&diff=1689Postage2013-12-04T18:47:06Z<p>Jrlevine: </p>
<hr />
<div>{{ast<br />
|date=1980s<br />
|difficult=Difficult to impossible<br />
|popular=Low<br />
|effective=Unknown<br />
|where=MTA or gateway<br />
|harm=High<br />
}}<br />
Spam is possible because the costs are asymmetrical. Sending mail costs much less than receiving it, so that receivers willingly subsidize legitimate senders, and unwillingly subsidize spammers. If it were possible to transfer some of the costs from receivers back to senders, that would presumably deter spammers, few of whom would be willing to pay the actual costs of their mail.<br />
<br />
Some early proprietary closed mail systems such as MCI Mail and Compuserve charged per message, but charging disappeared when they became linked into the Internet's flat rate mail system. None ever handled inter-system settlements; for example MCI would charge its users for messages sent to the Internet, but would receive Internet messages for its users for free.<br />
<br />
Postage on electronic mail is a highly contentious topic. Typical proposals involve providing stamps to senders which are collected by recipients, or by intermediate post offices on behalf of recipients. Often, recipients can decline payment for mail from known or preferred senders. All assume strong enough sender authentication to prevent spammers from avoiding paying postage by pretending to be someone else.<br />
<br />
Some argue that it's flatly impractical to implement across the Internet, due to the costs and complexities of handling the enormous volume of mail, most of which is spam that won't pay anything, of operating the banks or post offices that would manage the payments, and of handling the range of errors and frauds that would arise. See the white paper referenced below for a longer analysis.<br />
<br />
Goodmail Systems' Certified Email used a form of postage to provide preferred delivery of mail to some ISPs and mailbox providers.<br />
<br />
=== References ===<br />
*[http://www.taugh.com/epostage.pdf J. Levine's e-postage white paper]</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Cryptographic_signatures&diff=1687Cryptographic signatures2012-11-08T20:42:16Z<p>Jrlevine: Created page with "{{ast |date=late 1990s |difficult=High |popular=Medium |effective=High |harm=Low |where=MTA/MUA }} Cryptographic signatures associate a forgery-resistant identity with an e-ma..."</p>
<hr />
<div>{{ast<br />
|date=late 1990s<br />
|difficult=High<br />
|popular=Medium<br />
|effective=High<br />
|harm=Low<br />
|where=MTA/MUA<br />
}}<br />
Cryptographic signatures associate a forgery-resistant identity with an e-mail message. They are not directly useful as anti-spam technique, but can be used in connection with reputation systems, so that a message signed with an identity that has a good reputation can be whitelisted or otherwise handled differently.<br />
<br />
Some signatures such as S/MIME and PGP use an e-mail address as the identity and sign the body of the message. DKIM and its predecessor DomainKeys sign the entire message using a domain name as the identity.</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Sender-ID&diff=1686Sender-ID2012-11-08T19:45:40Z<p>Jrlevine: </p>
<hr />
<div>{{ast<br />
|date=2005<br />
|difficult=Medium<br />
|popular=Low<br />
|effective=Medium<br />
|harm=Low<br />
|where=MTA<br />
}}<br />
Sender-ID is a path management technique that assigns a set of permitted IP addresses to the domain in a message's From: or Sender: header, selected by a Purported Responsible Address (PRA) algorithm. The Sender-ID record is a TXT record published in the DNS under the name of the domain, in a complex format. If the IP address from which a message is sent matches the domain's record, Sender-ID succeeds. If not, there are various levels of hard and soft failure.<br />
<br />
Sender-ID has its own TXT message format but will fall back to using SPF records.<br />
<br />
Sender-ID is similar to [[SPF]] with similar advantages and disadvantages. Its primary user and proponent was Microsoft. The PRA algorithm in RFC 4407 is patented, which turned out to be an impediment to adoption, even though Microsoft offered a free public license.<br />
<br />
<br />
= References =<br />
* RFC 4406<br />
* RFC 4407</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Sender-ID&diff=1685Sender-ID2012-11-08T19:38:16Z<p>Jrlevine: Created page with "{{ast |date=2005 |difficult=Medium |popular=Low |effective=Medium |harm=Low |where=MTA }} Sender-ID is a path management technique that assigns a set of permitted IP addresses..."</p>
<hr />
<div>{{ast<br />
|date=2005<br />
|difficult=Medium<br />
|popular=Low<br />
|effective=Medium<br />
|harm=Low<br />
|where=MTA<br />
}}<br />
Sender-ID is a path management technique that assigns a set of permitted IP addresses to the domain in a message's From: or Sender: header. The Sender-ID record is a TXT record published in the DNS under the name of the domain, in a complex format. If the IP address from which a message is sent matches the domain's record, Sender-ID succeeds. If not, there are various levels of hard and soft failure.<br />
<br />
Sender-ID has its own TXT message format but will fall back to using SPF records.<br />
<br />
Sender-ID is similar to [[SPF]] with similar advantages and disadvantages. Its primary user and proponent was Microsoft. Purported Responsible Address algorithm in RFC 4407 is patented, which turned out to be an impediment to adoption.<br />
<br />
<br />
= References =<br />
* RFC 4406<br />
* RFC 4407</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=SPF&diff=1684SPF2012-11-08T19:32:29Z<p>Jrlevine: </p>
<hr />
<div>{{ast<br />
|date=2003<br />
|difficult=Easy<br />
|popular=Medium<br />
|effective=Medium<br />
|harm=High<br />
|where=MTA<br />
}}<br />
<br />
SPF (originally Sender Permitted From, now Sender Policy Framework) is a path management technique that assigns a set of permitted IP addresses to the domain in a message's bounce (MAIL FROM) address. The SPF record is a TXT record published in the DNS under the name of the domain, in a complex format. If the IP address from which a message is sent matches the domain's record, SPF succeeds. If not, there are various levels of hard and soft failure.<br />
<br />
Like all path validation schemes, SPF does not deal well with mail that does not all come from a fixed source.<br />
In practice, it works well for bulk mailers that send from a small set of servers, somewhat well for organizations where most users use the organization's own mail system, and not at all for courtesy forwarders, and "permanent" mail addresses at universities and professional societies.<br />
<br />
[[SRS]] is intended to make forwarded mail more compatible with SPF.<br />
<br />
= References =<br />
* RFC 4408<br />
* [http://www.openspf.org/ SPF Project Overview]</div>Jrlevinehttps://wiki.asrg.sp.am/index.php?title=Subject_keywords&diff=1683Subject keywords2012-11-08T19:26:27Z<p>Jrlevine: Created page with "{{ast |date=late 1990s |difficult=Medium |popular=Low |effective=Low to medium |harm=Low to medium |where=MUA }} Correspondents put a particular word in the subject line of ma..."</p>
<hr />
<div>{{ast<br />
|date=late 1990s<br />
|difficult=Medium<br />
|popular=Low<br />
|effective=Low to medium<br />
|harm=Low to medium<br />
|where=MUA<br />
}}<br />
Correspondents put a particular word in the subject line of mail. Then the recipient sets up a mail filter to discard or sideline mail without that word.<br />
<br />
For individual correspondents, it's rarely effective since there are few people whose correspondents are willing to jump through hoops to send them mail. It has been somewhat effective on submission addresses for mailing lists and newsgroups.<br />
<br />
It wouldn't be hard to adjust MUA address books to include a subject keyword, but as far as we know nobody's done that.</div>Jrlevine