Email header improvements

[johnjamesjacoby]

In recent years, a number of new email headers have emerged to help protect recipients from spam and abuse. We should add support for them in the emails that are sent to forum & topic subscribers.

• Require-Recipient-Valid-Since: %user last active time%
• List-Unsubscribe: <%an unsubscribe url%>

Supporting these two headers will require a(nother) not-insignificant rethink of how user data is queried for and looped through, as bbPress now takes a very minimal approach to keep it speedy.

The first header value should probably come from user_registered, since that's the only place available to us where we can be confident that a user last verified their email address – nothing gets stored in usermeta when a user email address is changed.

The second header value is a bit of a problem because the links to toggle subscriptions have nonces on them, meaning their useful life is currently too low to be very effective in an email older than 24 hours.

To make matters worse, bbPress switched to using a new function in 2.6 to query for user email addresses in batches of 100, to address frequent complaints about user queries taking a long time on installs with large numbers of users. See: bbp_get_email_addresses_from_user_ids() and r6725, #3068.

[johnjamesjacoby]

Things to think about:

Inside of bbp_get_email_addresses_from_user_ids(), we opted to use get_users() and use all_with_meta to prime the user objects for future/immediate use, and then just pluck user_email out of the results.

This means we can reference the user object and use user_registered without hitting the database, though we would be duplicating some effort with somewhat goofy function calls.

We also switched to sending 1 email and using Bcc: headers to minimize SMTP wait time inside of a foreach() loop, which is in direct conflict with sending unique headers per-user as would be required by this enhancement.

This is not very great, as I think we'd need to revert back to sending many individual emails again, something that has already proven to be problematic for users in the forums.

[dd32]

The second header value is a bit of a problem because the links to toggle subscriptions have nonces on them, meaning their useful life is currently too low to be very effective in an email older than 24 hours.

Ideally they'd also work without logging in, so a signed url rather than a nonce would be used. I guess the url should double check their intention, but I'd check the RFC for those headers to find out the expected contents.

[dd32]

Related: #2707 (Include an unsubscribe link in emails)

[johnjamesjacoby]

I'm going to move this to 2.7, so 2.6 can be shipped sooner without it.

This continues to be a high priority IMO, but I don't think I'll get to it in time for 2.6.