On 7/19/2016 5:00 PM, Russ Housley wrote:
Outgoing Mailman email still has the problem. Mailman has an option we can
enable to force DMARC-spoofing sender rewriting of all outgoing Mailman email.
If we enable that option, the From: field rewriting and could be disruptive in
unknown ways.
We know that outgoing alias email still has the problem. The Secretariat is
did some experiments with some additional headers (Resent-*) to alias mail.
They were not able to determine whether this headers helped destination servers
or not.
The major issue is for mail sent through a mailing list, from authors
whose From: domain has a DMARC policy calling for dire action (reject or
quarantine) if DMARC does not validate at the final recipient's side.
To overcome this, the ad hoc convention for mailing lists is to rewrite
the From: header field, using an address belonging to the mailing list
-- ie, no longer using the author's address -- and modifying the Display
(friendly) string to /add/ something like "- via <listname>". In
addition the Reply-to: header field is set to be the original author's
address, so that direct replies from a recipient will go back to the
proper place.
When organized by author address, this means that an actual author's
mail is listed differently depending upon whether their messages are
direct to the recipient, versus whether they went through a mailing
list. It likely also means differential listing when sorted on the
Display string...
The modified display string will now have the extra visual cruft and
there is no empirical basis for justifying that cruft, in terms of user
behavior or any other safety and security. That is, it's an entirely
logical modification, but there is no basis for believing that it is
useful. (This is an unfortunate fact of usability life.)
There is an effort (ARC) to develop a capability that might let
DMARC-related messages survive transit of a mailing list, but that
effort is still nascent.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net