Two more DMARC mitigations

- 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.
- 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. Collecting credentials gives the mail operators heartburn, but as I told them at a meeting today, if you want all mail to be authenticated, that's what you asked for.
There is definite interest at large mail providers at least for the first one. Dunno if they're interested in the second, but since it uses features they already have, it matters less.
R's, John

John Levine writes:
Thanks, I was about to write something like this!
-1 on the password thing. It's too close to phishing, imposes serious privacy issues on Mailman hosts, and makes them targets for attack. This is too dangerous to be even an optional feature. Third party patches are OK, of course, but stock Mailman shouldn't do this.
I'm fine with annoying the hell out of Yahoo! and AOL users with an OAuth request on every post.
This is less nice, it's a lot of software development.
I don't think prototyping this is all that hard. We already have logic for checking DMARC thanks to dmarc_moderation_action. We just add the OAuth check to that, and if it fails, proceed to dmarc_moderation_action.

Honestly, Tough Noogies. Let list managers make their own security decisions. AOL and Yahoo want all mail from their users to be authenticated. Well, OK, this will do it.
I'm fine with annoying the hell out of Yahoo! and AOL users with an OAuth request on every post.
My Yahoo contact tells me they eventually plan to do OAuth submission which should have long lived tokens. But in the meantime, the submit hack should work everywhere.
Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail.

John R Levine writes:
Honestly, Tough Noogies. Let list managers make their own security decisions.
Revealing a user password is not a list security decision, it's a user security decision. Asking users for their passwords is evil, period.
I mentioned the impact on lists (becoming targets) as additional reasons not to do this in Mailman.

On Thu, Jun 12, 2014 at 10:07 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Unless I am mistaking things, the sheer irony here is that Yahoo's bastardized version of DMARC, which is necessary to stave off collateral damage from their past security breach(es?), needs to be further augmented with even less user security in order to be secure. O.o Man that boggles the mind.
-Jim P.

On Jun 13, 2014, at 12:11 AM, John R Levine wrote:
This is a really bad idea. In MM3, we've already eliminated the need for keeping clear text passwords, and almost gotten rid of any user passwords at all. OAUTH tokens are a little better, but no way do I want to hold a clear text password for users.
-Barry

I agree it's a horrible idea. But at the moment it's the only horrible idea I'm aware of that will let lists keep operating in the way the managers and users want, with no From: munging and no bounces, using existing facilities from the mail providers.
AOL and Yahoo both have OAUTH APIs, but they are not the same, and I see no likelihood that the APIs will converge, or that the next large webmail provider to DMARC us will be compatible with either. But everyone has a SUBMIT server.
At least one of the large providers has told me they plan to do OAUTH submission, presumably with long lived tokens, which would greatly mitigate the security issues. It is my impression that if word got back that lists were considering doing the submit trick, it would motivate them to get OAUTH submission working sooner.
R's, John

On 6/14/2014 5:15 PM, John Levine wrote:
For other reasons, I've poked into OAUTH for email before. I've been told that some Google employees are working on documents for dynamic client registration and endpoint discovery, but all the references I've found seem to imply that endpoint discovery is consistently being tabled for later work.
-- Joshua Cranmer Thunderbird and DXR developer Source code archæologist

On Jun 14, 2014, at 10:15 PM, John Levine wrote:
Mailman has always been about adhering to standards, preferably RFCs, but de facto standards are acceptable when it makes sense. OAUTH submission could make sense, but I'm not in favor of a supporting a proliferation of incompatible hacks. If this is going to be A Thing, then these webmail providers need to get together and agree on some standard. Otherwise, what Mailman should do IMHO, is support a framework for supporting the feature in general, and leave it to third parties to support their email providers of choice.
It's the least crappy solution (so far) to a problem of their making, but please get them to agree on some kind of common API.
-Barry

Well, yeah. They all do SUBMIT. I understand the security issue of submission with a password, but it's the only thing that consistently works.
I'm trying to track down what's actually going on here. It's SUBMIT either way, so everything in the code except the way that authorization is sent to the SUBMIT server is the same.
Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail.

After digging through a festival of acronyms, I ended up at RFC 6616.
Mail submission (port 587) is defined in RFC 4409. It refers to RFC 2554, now replaced by RFC 4954, which defines the AUTH extension to SMTP. That in turn punts to SASL, defined in RFC 4422, which describes the authorization framework and the initial schemes. RFC 6616 adds OpenID as a SASL authorization scheme. It's fairly impenetrable, but I know the guy who wrote it, so I can probably get some help, and it's definitely a standards track document so we can expect everyone who implements it to do so in the same way. OpenID tokens can be very long lived -- I've been doing programmed posts to my Twitter account using the same token for several years.
There are certainly OpenID libraries, but I don't know to what extent anyone has written the code to splice them into SASL. It (SASL) is used for many mail applications including POP and IMAP. Considering how easily malware can scrape passwords out of software on PCs, I expect that the providers have considerable incentive to replace them with OpenID tokens in MUAs.
I would propose doing the submission hack, explicitly noting that SASL has a variety of different ways to authenticate with different usability and security trade offs.
R's, John

John Levine writes:
After digging through a festival of acronyms, I ended up at RFC 6616.
Thank you!
There are certainly OpenID libraries, but I don't know to what extent anyone has written the code to splice them into SASL.
Were we (on dmarc@ietf) talking all along about OpenID when we wrote "OAuth"? They're different, although I don't know exactly how or why (and neither RFC made obvious mention of the other :-( ).
I'm not sure who you know among the authors of that RFC, but I've worked with Simon Josefsson, who would surely help if he has time, and has done a lot of implementation. (I suspect Barry knows him too.) Given that Simon is on the side of SASL/OpenID vs. OAuth, I suspect that OpenID is the more practical of the two standards.
I think that's a good starting point for discussion. With a little luck it could be quite close to eventual implementation, too. :-)
Steve

On 6/16/2014 9:28 PM, Stephen J. Turnbull wrote:
OAuth calls itself an authorization framework. I like to think of it personally as a less secure and less well-specified variant of Kerberos. :-) OpenID in contrast is more of a third-party authentication provider. It looks like OpenID is repositioning itself to work on top of OAuth 2.0 with OpenID Connect, though.
The problem with OAuth is that a lot of its details are left up to the whims of the implementor, such as the location of its various endpoints or even what elements in the query are mandatory. Figuring out how to go from "email address" to "OAuth bearer token" is currently impossible without hardcoding a lot of mapping details.
-- Joshua Cranmer Thunderbird and DXR developer Source code archæologist

On Jun 17, 2014, at 09:34 AM, Joshua Cranmer 🐧 wrote:
Not to mention that there are lots of OAuth 1.x implementations out there (client and server), and it's a fairly easy protocol to understand. At a Python conference a few years ago I spoke with someone who resigned from the committee designing OAuth 2 due to lots of problems with the new spec, essentially ill you could imagine with a designed-by-committee new version. (In the music biz, we call this the sophomore slump. Great debut album, but all the good material got used up. :)
-Barry

On Jun 17, 2014, at 11:28 AM, Stephen J. Turnbull wrote:
I haven't been keeping up with the latest OpenID and OAuth specs, but one way I think about it is that OAuth is a web-service delegation protocol, while OpenID is more of a single-sign-on protocol.
Let's say you have a web service, like, oh I don't know, Mailman 3's REST API. You want to script some interactions with this service, perhaps locally, or you want to allow some other application to do it on your behalf. Normally, you'd have to hard code your username and password in some local file, or enter it into the third party app. With OAuth, you can acquire a token from the service which is used to sign requests, so that the service knows it's coming from you. Thus you can hand the third party application your token without giving it your password, and most services provide you a way to revoke tokens if you e.g. stop using the third party app. Usually, you round-trip through a web browser (the only "trusted agent" on your system) to acquire the token, but there can be other ways.
OpenID is more like a single-sign-on technology. Let's say you want to log into Bitbucket for the first time, but you don't want to have to register yet another username and password with yet another web site. Fortunately, you have a Launchpad account, which is an OpenID provider, so on Bitbucket's login page you enter your OpenID, which is an https url pointing to your Launchpad page. After some dancing with Launchpad and Ubuntu's SSO, Bitbucket logs you in. The point is that Bitbucket doesn't have access to your Launchpad password - it delegates authentication to Ubuntu's SSO and Launchpad, which as it turns out can also be made to require two-factor auth for additional security.
Thinking about it this way, I'm not really sure what's being considered for DMARC, although either make some sense in different contexts. My guess is that it's probably OAuth based; I'd get a token to submit messages via a web service using authenticated and signed requests. But that's just a guess.
-Barry

Thinking about it this way, I'm not really sure what's being considered for DMARC, ...
Nothing specifically for DMARC. The idea is that SASL, the layer you use to log into pop, imap, and submit servers, now includes oauth as an authentication scheme and OpenID as the common way to get the token. This is all in RFC 6616, and is allegedly implemented in gsasl.
Once you have access to the subscriber's submit server, you can run the decorated message through it to get the mail providers's signature, then remail that. OAuth just avoids the need to ask the user directly for her password.
R's, John

John Levine writes:
Yeah, I got that far.
This is potentially a lot of remailing, though. Somebody who has been posting twice a day to a mailing list with 1000 subscribers suddenly goes from 10 outgoing messages a day to 2008. I suppose this is just a drop in the bucket for the MTAs, but I wonder if the mailbox providers will really go for this given their sensitivity to taking responsibility for anything (except keeping spam out of their users' mailboxes).

No, he goes from two to four. He sends the first original message to the list (1) which adds subject tags and footers or whatever, then uses OAuth to resend it back to the list to get a new DKIM signature (2), and the list then remails that to the thousand subscribers. He sends the second message (3) which is treated the same way (4).
If you have the list set to customize the message per recipient, this hack doesn't work. Do you have any idea how many lists do that?
Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail.

On 06/17/2014 06:56 PM, John R Levine wrote:
If you have the list set to customize the message per recipient, this hack doesn't work. Do you have any idea how many lists do that?
Many. Take a look at the footer in messages from this list. It contains an Unsubscribe: link to the recipient's user options page.
I have no idea exactly what fraction of Mailman lists are configured with personalized footers, but I suspect it's significant.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Mark Sapiro writes:
I have no idea exactly what fraction of Mailman lists are configured with personalized footers, but I suspect it's significant.
@John: Sorry, I definitely was assuming personalization; I should have said so.
I think personalization is quite a desirable feature in some contexts. All of my educational lists have personalized footers (subscribers min 5, max 20, mean 7 -- tiny, or "nano" if you prefer). I would guess lists with "naive" users are more likely to want to personalize.
OTOH, XEmacs lists are ancient, they don't personalize. Emacs-devel (probably by Savannah policy) doesn't have them at all. python-dev and python-ideas *do* have personalized footers (maybe somebody here knows how many subscribers?) Sourceforge's weekly ping doesn't have a footer, the monthly news letter does. (Of course those SF lists aren't discussion lists, but it's indicative of expectations among developers -- we probably don't need them. It also shows that lists with many thousands of users sometimes use personalized footers, at least if they're low-traffic.)

On Jun 12, 2014, at 02:18 PM, John Levine wrote:
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
*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

Barry Warsaw writes:
On Jun 12, 2014, at 02:18 PM, John Levine wrote:
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.
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.
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.
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.
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.

It'd typically be the list domain, on the theory that lists will sign their outgoing mail with their own domain. If lists aren't signed with the list domain, some kludge would be required at the sending end, but it's intended to be fully automated.
It is my impression, having talked to tech managers at several large web mail providers this week, that if they could do something like this without a huge amount of effort, they probably would. They'd probably only add it on mail going to legitimate forwarders (for some definitions of legitimate and forwarders) but the large web mail providers already have a pretty good idea who those are.
R's, John

John Levine writes:
Thanks, I was about to write something like this!
-1 on the password thing. It's too close to phishing, imposes serious privacy issues on Mailman hosts, and makes them targets for attack. This is too dangerous to be even an optional feature. Third party patches are OK, of course, but stock Mailman shouldn't do this.
I'm fine with annoying the hell out of Yahoo! and AOL users with an OAuth request on every post.
This is less nice, it's a lot of software development.
I don't think prototyping this is all that hard. We already have logic for checking DMARC thanks to dmarc_moderation_action. We just add the OAuth check to that, and if it fails, proceed to dmarc_moderation_action.

Honestly, Tough Noogies. Let list managers make their own security decisions. AOL and Yahoo want all mail from their users to be authenticated. Well, OK, this will do it.
I'm fine with annoying the hell out of Yahoo! and AOL users with an OAuth request on every post.
My Yahoo contact tells me they eventually plan to do OAuth submission which should have long lived tokens. But in the meantime, the submit hack should work everywhere.
Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail.

John R Levine writes:
Honestly, Tough Noogies. Let list managers make their own security decisions.
Revealing a user password is not a list security decision, it's a user security decision. Asking users for their passwords is evil, period.
I mentioned the impact on lists (becoming targets) as additional reasons not to do this in Mailman.

On Thu, Jun 12, 2014 at 10:07 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Unless I am mistaking things, the sheer irony here is that Yahoo's bastardized version of DMARC, which is necessary to stave off collateral damage from their past security breach(es?), needs to be further augmented with even less user security in order to be secure. O.o Man that boggles the mind.
-Jim P.

On Jun 13, 2014, at 12:11 AM, John R Levine wrote:
This is a really bad idea. In MM3, we've already eliminated the need for keeping clear text passwords, and almost gotten rid of any user passwords at all. OAUTH tokens are a little better, but no way do I want to hold a clear text password for users.
-Barry

I agree it's a horrible idea. But at the moment it's the only horrible idea I'm aware of that will let lists keep operating in the way the managers and users want, with no From: munging and no bounces, using existing facilities from the mail providers.
AOL and Yahoo both have OAUTH APIs, but they are not the same, and I see no likelihood that the APIs will converge, or that the next large webmail provider to DMARC us will be compatible with either. But everyone has a SUBMIT server.
At least one of the large providers has told me they plan to do OAUTH submission, presumably with long lived tokens, which would greatly mitigate the security issues. It is my impression that if word got back that lists were considering doing the submit trick, it would motivate them to get OAUTH submission working sooner.
R's, John

On 6/14/2014 5:15 PM, John Levine wrote:
For other reasons, I've poked into OAUTH for email before. I've been told that some Google employees are working on documents for dynamic client registration and endpoint discovery, but all the references I've found seem to imply that endpoint discovery is consistently being tabled for later work.
-- Joshua Cranmer Thunderbird and DXR developer Source code archæologist

On Jun 14, 2014, at 10:15 PM, John Levine wrote:
Mailman has always been about adhering to standards, preferably RFCs, but de facto standards are acceptable when it makes sense. OAUTH submission could make sense, but I'm not in favor of a supporting a proliferation of incompatible hacks. If this is going to be A Thing, then these webmail providers need to get together and agree on some standard. Otherwise, what Mailman should do IMHO, is support a framework for supporting the feature in general, and leave it to third parties to support their email providers of choice.
It's the least crappy solution (so far) to a problem of their making, but please get them to agree on some kind of common API.
-Barry

Well, yeah. They all do SUBMIT. I understand the security issue of submission with a password, but it's the only thing that consistently works.
I'm trying to track down what's actually going on here. It's SUBMIT either way, so everything in the code except the way that authorization is sent to the SUBMIT server is the same.
Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail.

After digging through a festival of acronyms, I ended up at RFC 6616.
Mail submission (port 587) is defined in RFC 4409. It refers to RFC 2554, now replaced by RFC 4954, which defines the AUTH extension to SMTP. That in turn punts to SASL, defined in RFC 4422, which describes the authorization framework and the initial schemes. RFC 6616 adds OpenID as a SASL authorization scheme. It's fairly impenetrable, but I know the guy who wrote it, so I can probably get some help, and it's definitely a standards track document so we can expect everyone who implements it to do so in the same way. OpenID tokens can be very long lived -- I've been doing programmed posts to my Twitter account using the same token for several years.
There are certainly OpenID libraries, but I don't know to what extent anyone has written the code to splice them into SASL. It (SASL) is used for many mail applications including POP and IMAP. Considering how easily malware can scrape passwords out of software on PCs, I expect that the providers have considerable incentive to replace them with OpenID tokens in MUAs.
I would propose doing the submission hack, explicitly noting that SASL has a variety of different ways to authenticate with different usability and security trade offs.
R's, John

John Levine writes:
After digging through a festival of acronyms, I ended up at RFC 6616.
Thank you!
There are certainly OpenID libraries, but I don't know to what extent anyone has written the code to splice them into SASL.
Were we (on dmarc@ietf) talking all along about OpenID when we wrote "OAuth"? They're different, although I don't know exactly how or why (and neither RFC made obvious mention of the other :-( ).
I'm not sure who you know among the authors of that RFC, but I've worked with Simon Josefsson, who would surely help if he has time, and has done a lot of implementation. (I suspect Barry knows him too.) Given that Simon is on the side of SASL/OpenID vs. OAuth, I suspect that OpenID is the more practical of the two standards.
I think that's a good starting point for discussion. With a little luck it could be quite close to eventual implementation, too. :-)
Steve

On 6/16/2014 9:28 PM, Stephen J. Turnbull wrote:
OAuth calls itself an authorization framework. I like to think of it personally as a less secure and less well-specified variant of Kerberos. :-) OpenID in contrast is more of a third-party authentication provider. It looks like OpenID is repositioning itself to work on top of OAuth 2.0 with OpenID Connect, though.
The problem with OAuth is that a lot of its details are left up to the whims of the implementor, such as the location of its various endpoints or even what elements in the query are mandatory. Figuring out how to go from "email address" to "OAuth bearer token" is currently impossible without hardcoding a lot of mapping details.
-- Joshua Cranmer Thunderbird and DXR developer Source code archæologist

On Jun 17, 2014, at 09:34 AM, Joshua Cranmer 🐧 wrote:
Not to mention that there are lots of OAuth 1.x implementations out there (client and server), and it's a fairly easy protocol to understand. At a Python conference a few years ago I spoke with someone who resigned from the committee designing OAuth 2 due to lots of problems with the new spec, essentially ill you could imagine with a designed-by-committee new version. (In the music biz, we call this the sophomore slump. Great debut album, but all the good material got used up. :)
-Barry

On Jun 17, 2014, at 11:28 AM, Stephen J. Turnbull wrote:
I haven't been keeping up with the latest OpenID and OAuth specs, but one way I think about it is that OAuth is a web-service delegation protocol, while OpenID is more of a single-sign-on protocol.
Let's say you have a web service, like, oh I don't know, Mailman 3's REST API. You want to script some interactions with this service, perhaps locally, or you want to allow some other application to do it on your behalf. Normally, you'd have to hard code your username and password in some local file, or enter it into the third party app. With OAuth, you can acquire a token from the service which is used to sign requests, so that the service knows it's coming from you. Thus you can hand the third party application your token without giving it your password, and most services provide you a way to revoke tokens if you e.g. stop using the third party app. Usually, you round-trip through a web browser (the only "trusted agent" on your system) to acquire the token, but there can be other ways.
OpenID is more like a single-sign-on technology. Let's say you want to log into Bitbucket for the first time, but you don't want to have to register yet another username and password with yet another web site. Fortunately, you have a Launchpad account, which is an OpenID provider, so on Bitbucket's login page you enter your OpenID, which is an https url pointing to your Launchpad page. After some dancing with Launchpad and Ubuntu's SSO, Bitbucket logs you in. The point is that Bitbucket doesn't have access to your Launchpad password - it delegates authentication to Ubuntu's SSO and Launchpad, which as it turns out can also be made to require two-factor auth for additional security.
Thinking about it this way, I'm not really sure what's being considered for DMARC, although either make some sense in different contexts. My guess is that it's probably OAuth based; I'd get a token to submit messages via a web service using authenticated and signed requests. But that's just a guess.
-Barry

Thinking about it this way, I'm not really sure what's being considered for DMARC, ...
Nothing specifically for DMARC. The idea is that SASL, the layer you use to log into pop, imap, and submit servers, now includes oauth as an authentication scheme and OpenID as the common way to get the token. This is all in RFC 6616, and is allegedly implemented in gsasl.
Once you have access to the subscriber's submit server, you can run the decorated message through it to get the mail providers's signature, then remail that. OAuth just avoids the need to ask the user directly for her password.
R's, John

John Levine writes:
Yeah, I got that far.
This is potentially a lot of remailing, though. Somebody who has been posting twice a day to a mailing list with 1000 subscribers suddenly goes from 10 outgoing messages a day to 2008. I suppose this is just a drop in the bucket for the MTAs, but I wonder if the mailbox providers will really go for this given their sensitivity to taking responsibility for anything (except keeping spam out of their users' mailboxes).

No, he goes from two to four. He sends the first original message to the list (1) which adds subject tags and footers or whatever, then uses OAuth to resend it back to the list to get a new DKIM signature (2), and the list then remails that to the thousand subscribers. He sends the second message (3) which is treated the same way (4).
If you have the list set to customize the message per recipient, this hack doesn't work. Do you have any idea how many lists do that?
Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail.

On 06/17/2014 06:56 PM, John R Levine wrote:
If you have the list set to customize the message per recipient, this hack doesn't work. Do you have any idea how many lists do that?
Many. Take a look at the footer in messages from this list. It contains an Unsubscribe: link to the recipient's user options page.
I have no idea exactly what fraction of Mailman lists are configured with personalized footers, but I suspect it's significant.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Mark Sapiro writes:
I have no idea exactly what fraction of Mailman lists are configured with personalized footers, but I suspect it's significant.
@John: Sorry, I definitely was assuming personalization; I should have said so.
I think personalization is quite a desirable feature in some contexts. All of my educational lists have personalized footers (subscribers min 5, max 20, mean 7 -- tiny, or "nano" if you prefer). I would guess lists with "naive" users are more likely to want to personalize.
OTOH, XEmacs lists are ancient, they don't personalize. Emacs-devel (probably by Savannah policy) doesn't have them at all. python-dev and python-ideas *do* have personalized footers (maybe somebody here knows how many subscribers?) Sourceforge's weekly ping doesn't have a footer, the monthly news letter does. (Of course those SF lists aren't discussion lists, but it's indicative of expectations among developers -- we probably don't need them. It also shows that lists with many thousands of users sometimes use personalized footers, at least if they're low-traffic.)

On Jun 12, 2014, at 02:18 PM, John Levine wrote:
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
*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

Barry Warsaw writes:
On Jun 12, 2014, at 02:18 PM, John Levine wrote:
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.
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.
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.
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.
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.

It'd typically be the list domain, on the theory that lists will sign their outgoing mail with their own domain. If lists aren't signed with the list domain, some kludge would be required at the sending end, but it's intended to be fully automated.
It is my impression, having talked to tech managers at several large web mail providers this week, that if they could do something like this without a huge amount of effort, they probably would. They'd probably only add it on mail going to legitimate forwarders (for some definitions of legitimate and forwarders) but the large web mail providers already have a pretty good idea who those are.
R's, John
participants (7)
-
Barry Warsaw
-
Jim Popovitch
-
John Levine
-
John R Levine
-
Joshua Cranmer 🐧
-
Mark Sapiro
-
Stephen J. Turnbull