In order to prevent spam and fraud on e-mail, companies can set SPF

records on their domains specifying whether services (and which

services/domains/IPs) can send e-mail on behalf of a user on the domain,

and DMARC records stating what should happen if an e-mail fails

verification.
This ends up breaking Review Board, RBCommons, and Splat. Companies that

have DMARC quarantine rules set see their e-mails going to

spam/moderation, and companies that have DMARC reject rule set simply

don't receive emails. This is pretty bad. While one fix would be to

simply always send using an e-mail address under our control, that can

easily end up breaking filters, and it's simply not necessary (or

desirable) when running a service within a company's own network.
This change solves the problem by making our e-mail sending code a lot

smarter. Instead of blindly accepting the From/Sender headers as-is, it

now checks DMARC records and determines whether it can send using the

specified From address. If there's any chance the e-mail would end up

being flagged by DMARC for quarantine/rejection, then the e-mail will

instead be sent using the service's name. The From address will list the

full name as "<Full Name> via <Service Name>", with a Reply-To set so

that replies will end up being directed by to the original user.
Through this, we should be able to support the various degrees of

verification and enforcement out there without dropping e-mails on the

floor at any stage.
This support is not enabled by default. It must be opted into using

enable_smart_spoofing=True when creating the message, or by setting

settings.EMAIL_ENABLE_SMART_SPOOFING.

Unit tests all pass.
Further testing in production will be needed.