[Mailman-Developers] Two more DMARC mitigations

[Stephen J. Turnbull]

Barry Warsaw writes:
 > On Jun 12, 2014, at 02:18 PM, John Levine wrote:

 > >* Forwarding signature

 > How does this list of forwarding target domains get specified?

It can be specified explicitly (to add domains that are in Bcc or to
restrict the domains allowed), but it defaults to the list of visible
addressees (To and Cc).

 > Do they have to adjust this when they send a message for the first
 > time to a new mailing list on a new domain?

No, there's nothing that needs to be done per mailing list; it's per
message.  It only needs to be done for users at "p=reject" domains.

A host or an MUA (think Gnus or VM) *could* adjust the DKIM-Delegate
header based on user request or user history (eg, the set of List-Post
headers seen in mail delivered to that user), but the default is
probably good enough in general.

 > >* Submit and sign

 > *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.

I don't think so.  DMARC policies are looked up for each message, and
the OAuth token will typically be one time, so users posting from
"p=reject" domains will have to reauthenticate for every post.
Long-lived tokens are possible, but I don't know if anyone implements
them.

I don't think I'd want to deal with passwords at all, and I certainly
wouldn't want to keep a database of them.  I would recommend if you're
going to use the password auth do it for every message separately and
wipe the memory as soon as you're done.

 > It means the normal message acceptance and deliery machinery must
 > be diverted for these special users.

Yes.

 > 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.

It would go into a "pending authorization" (from the Author Domain
publishing "p=reject" queue).  Although you'd need a separate queue, I
don't see why this would be particularly problematic.

 > 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.

Why would one care?  You submit the message to site A for all users.

 > How do I know that Bob is honoring site A's p=reject

You can't.  Bob may be silently discarding, in which case you'll only
find out if Bob notices and reports.

 > 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?

That's always site A's problem, any time they authorize their users to
post to third parties.  It's site A that published the "p=reject", and
provides OAuth(*).  But effectively it comes down to trusting their
user (who explicitly authorizes the posts).

(*) Password auth, OTOH, can be "grabbed" by the user, and for that
reason I really don't want Mailman to provide it.