[Mailman-Developers] Two more DMARC mitigations

[Barry Warsaw]

On Jun 12, 2014, at 02:18 PM, John Levine wrote:

>* Forwarding signature
>
>The IETF DMARC list is discussing a mutant weak DKIM signature from a
>sending system (e.g. Yahoo and AOL) that would survive forwarding, but
>contains a list of forwarding target domains.  It's only considered
>valid if it's with a signature from the forwarding domain, i.e., the
>list.
>
>This is nice for list operators, since it requires nothing beyond
>not stripping the signature header, and signing on the way out.

How does this list of forwarding target domains get specified?  Is this
something the user has to do when they're sending the message?  Do they have
to adjust this when they send a message for the first time to a new mailing
list on a new domain?

Modulo details, +1

>* Submit and sign
>
>When a user at a p=reject signs up for a list, you demand an OAUTH API
>token if the the provider supports it, otherwise their host system
>password.  You can check it on the spot and skip the challenge email
>to confirm opt-in.
>
>When the user sends mail to the list, the list makes whatever changes
>it's going to make (subject tag, footers, whatever) and then uses the
>API or SUBMIT to resend it through the host system.  When it arrives
>back at the list, it has the host system's DKIM signature and the list
>can resend it to the subscribers with the valid signature.
>
>It also has to checks DMARC on incoming messages, and if the policy
>has changed, holds onto the message and send a notice saying go back
>to the web site and give us your credentials to stay on the list.
>
>This is less nice, it's a lot of software development.

*A lot* less nice.  It means new databases to keep the mapping of posting
domains to DMARC policies, and for mapping the OAUTH token (or password!) for
every user at that site.  It means the normal message acceptance and deliery
machinery must be diverted for these special users.  I'm not even sure how
this would work with full personalization, since the final message content
might not be constructed until it's on its way to the outgoing MTA.

Let's say Alice posts from site A, which publishes p=reject.  The message is
going to be personalized and sent to Bob and Claire.  Bob's site honors
Alice's p=reject, but Claire's does not.  Full personalization is turned on,
so some bits of the final message aren't even fully stitched together until
the message is delivered to the outgoing MTA, destined for Bob.  Does that
mean Alice and Bob's message both have to be re-delivered through site A?  How
do I know that Bob is honoring site A's p=reject, and if I can't know that, do
I have to send all personalized messages through site A?  How happy is site A
going to be about that?  Also, how does site A not become the vector for
forwarding attacks?  IOW, how does site A trust that the list's modifications
to Alice's original message is worthy of resigning and sending, and not just a
message subverted to spam?

-1

-Barry