On Wed, Nov 18, 2015 at 11:22:32AM +1100, Trent W. Buck wrote:
Mark Trickett wrote:
It might well be that there is currently no satisfactory solution, short of working on the source code.
...can file a bug against upstream mailman, if there isn't one already.
Then it might be fixed for you next time you dist-upgrade :-)
Or there may already be a satisfactory solution. ========================================================================== TL;DR mailman 2.1.18 recommends using dmarc_moderation_action instead of from_is_list from 2.1.16 http://wiki.list.org/DEV/DMARC ========================================================================== I'd like to thank those who have already advocated (justifiably) against munging the "From:" field, allowing me to avoid the religious debate thus far. Although, since there's potentially a more widely acceptable solution, I must express that this munging can, and should be avoided. Accepting the consensus arrived at by RFC5323 §3.6.2: "In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message." – [1] Where "SHOULD NOT" as defined by RFC2119 §4 means: "there may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label." – [2] I'm not convinced there's any "valid reasons" to munge the "From:" field in either of the following circumstances. 1) DKIM signing messages sent by the mailing list Unless there's a DMARC policy for a domain, there's no requirement for any parameter in the DKIM-Signature header field to match any other header field. In particular, the DKIM "d=" domain, and the domain in the "From:" field, aren't required to match in the absence of DMARC, (and ADSP, or DK) policy. Since this list's domain doesn't currently (or presumably, intend to) publish a DMARC policy record, I don't see DKIM signing of list mail as a valid reason to munge the "From:" field. 2) Lists receiving mail from domains with a restrictive policy The real issue here is that domains like Yahoo's publish a "p=reject" DMARC policy rule, and receiving domains (like Google's) are politely enforcing that policy by, you know, rejecting the mail that doesn't pass DMARC. Although rewriting the "From:" header on those posts is an option, (such as appending .INVALID to the domain, as per RFC2606) it's an *abysmal* choice, for reasons previously enumerated on this thread. Possible Solution: mailman 2.1.18 recommends using dmarc_moderation_action, instead of from_is_list from 2.1.16 [3] * Unset the from_is_list [4] "Munge From" which causes *all* of messages sent by the list to be munged. * Set dmarc_moderation_action [5] to one of; + Munge From - rewrite the From: and Reply-To: as in from_is_list + Wrap Message - wrap the message as in from_is_list Which should *only* affect messages received from domains with a restrictive DMARC policy (p=reject,p=quarantine) It seems as though this would be palatable to more people, and is probably a reason it was even implemented in 2.1.18 I'd personally prefer the latter, which preserves the original message (and header fields) in an RFC822 MIME sub-part (attachment), much like digests. FWIW: I'd paint the bike shed the following (different) colour: * Although wrapping the post to preserve the original header fields works, it's still a kludge, with those ugly from_is_list header fields, so I'd just reject the post(s) and send (a) sensible DMARC failure report(s) instead * Rejecting the post, as has already been stated by others on this thread, may provide the feedback to signers (via failure reports) to determine a better "market solution" * Disclaimer: I'm aware this solution has been deemed inappropriate for these lists; but in my own defence, during a past life I've endured the insanity of being a large site's postmaster. [1] https://tools.ietf.org/html/rfc5322#section-3.6.2 [2] https://tools.ietf.org/html/rfc2119#section-4 [3] http://wiki.list.org/DEV/DMARC [4] http://list.org/mailman-admin/general-personality.html [5] http://list.org/mailman-admin/sender-filters.html See also; DomainKeys Identified Mail (DKIM) Signatures https://tools.ietf.org/html/rfc6376 DKIM and Mailing Lists https://tools.ietf.org/html/rfc6377 DMARC https://tools.ietf.org/html/rfc7489