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.