Like many others here, I act as de-facto sysadmin to my partner. She wished
to have a "nice" mail via @pobox.com forwarded to here gmail account, *and*
to keep her actual gmail ID less visible.
For a limited time, this seemed to work. perhaps 6months. But inevitably,
the real underlying gmail address "leaks"
And, with the variance of policies, it is now unclear if the 'faked' @
pobox.com or @gmail.com "actual" address is the one seen. This is also a
function of Sender/From differentiation, and Envelope/Header
differentiation.
I feel sad I can't guarantee to her a specific behaviour. This feels wrong.
It feels like we've taken something out of the 822 Ecology by allowing
Sender, From, Envelope to get mashed together.
-George
On Fri, Sep 12, 2014 at 3:34 PM, Christian Huitema
<huitema(_at_)microsoft(_dot_)com>
wrote:
I've collected all of the DMARC workarounds I know on the ASRG wiki:
http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail
Two responses to that, in no particular order of importance:
1. So you said, and yet the mere existence of that page out on the
intertubez has (oddly enough) not yet spurred the secretariat into
action.
The big change with DMARC is a deprecation of the Sender/From
differentiation, effectively requiring that these two will be the same. It
seems that big systems have voted that the differentiation causes more harm
(spam, phish) than good (remailers).
Of the responses listed, the one that clearly works is to ask forwarders
to forward messages, what the wiki calls "message wrapping." It works in
the sense that the mail system sees consistent headers that pass all
verifications, and represent the actual action of the remailer while not
relying on Sender/From differences.
At that point, the issue is mostly with the UI. If my reader did recognize
the "simple forwarding" case from "authorized remailers," then the message
wrapping solution would be just fine. The good thing is that it is very
much under my control.
-- Christian Huitema