Interesting point for the discussion on whether MLMs are allowed to modify the from header is in the section 3.6.2 of rfc 2822: http://tools.ietf.org/html/rfc2822#section-3.6.2. The intended meaning of the from field is to indicate the author of a message which is explicitly allowed to be different than the sender. Thus list-originated communication like digest messages should be sent with the from header of the list, but messages forwarded by the MLM should be sent with the from header indicating the original author. In the absence of the sender header it can be assumed to be the same as the from header. Thus, DMARC could use the sender header instead of the from header and fall back to the from header only when sender is absent. This way MLMs would have a way of avoiding the issue by supplying the sender header. Unfortunately, DMARC chose not to use the sender header citing abuse and bugs in some MUAs which don't display the sender header to the user correctly: http://www.ietf.org/mail-archive/web/dmarc/current/msg00064.....
Interesting point for the discussion on whether MLMs are allowed to modify the from header is in the section 3.6.2 of rfc 2822: http://tools.ietf.org/html/rfc2822#section-3.6.2. The intended meaning of the from field is to indicate the author of a message which is explicitly allowed to be different than the sender. Thus list-originated communication like digest messages should be sent with the from header of the list, but messages forwarded by the MLM should be sent with the from header indicating the original author. In the absence of the sender header it can be assumed to be the same as the from header. Thus, DMARC could use the sender header instead of the from header and fall back to the from header only when sender is absent. This way MLMs would have a way of avoiding the issue by supplying the sender header. Unfortunately, DMARC chose not to use the sender header citing abuse and bugs in some MUAs which don't display the sender header to the user correctly: http://www.ietf.org/mail-archive/web/dmarc/current/msg00064.....
As for the "Original Authentication Results" it doesn't solve the problem for most lists since it requires the destination domain to explicitly trust the list, see http://www.dmarc.org/pipermail/dmarc-discuss/2012-February/0... and http://tools.ietf.org/id/draft-kucherawy-original-authres-00.... Few list admins could afford getting a trust explicitly established with every domain where the members happen to have mailboxes.