DKIM

Joshua Judson Rosen rozzin at hackerposse.com
Fri Jul 31 02:31:46 EDT 2015


On 07/29/2015 07:50 PM, Lloyd Kvam wrote:
> On Wed, 2015-07-29 at 14:56 -0400, Joshua Judson Rosen wrote:
> DKIM fouled up a list I manage when the sender was @comcast.com or
> @yahoo.com.  mailman broke the signatures and people using comcast and
> yahoo could not receive the messages.
> 
> My fix in /etc/mailman/mm_cfg.py
> #~ DKIM Handling
> #~ set up allow author is list
> REMOVE_DKIM_HEADERS = 1
> ALLOW_FROM_IS_LIST = Yes
> DEFAULT_FROM_IS_LIST = 1
> 
> Now all the emails are getting delivered.  I do NOT claim this is better
> than the earlier advice, merely that this got email flowing again.

Right, that's what Yahoo! does on their lists--has the mailing lists
pretend that they're writing the e-mails themselves as they `forward'
them through, so mail that you get from the list has headers like:

	From: "Bob Dobbs <bob at subgenius.com>" <the-list at slackers.com>

Check out the "dmarc_moderation_action" option in Mailman 2.1.18,
which at least lets you narrow the scope on that behaviour to
affect only the messages that require it.

To be fair to Yahoo! (which may actually make them look worse...),
IIRC, the reason they prefer that mailing-list configuration
(and the reason for Yahoo! becoming (in)famous again) was more because
outbound mail from Yahoo! user accounts was using DMARC with *SPF*,
and not so much because of DKIM (and Mailman's docs IIRC referred
to this as "DMARC mitigation").

I think you should be able to deal with even broad-scoped DKIM
signature by just not munging the signed content as it passes
through; SPF+DMARC, on the other hand, is basically impossible
to deal with without completely changing the model of mailing
lists--from relaying, to forwarding under the list's own
authorship claim.

The DMARC FAQ actually has an item for this:

	https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F

	1. Operate strictly as a "forwarder," where the
	RFC5321.RcptTo field is changed to send the message
	to list members, but the RFC5322 message headers and body
	are not altered.

	Pros: Receiving systems can validate the DKIM signature of
	the message author, if one was present.

	Cons: Senders that depend solely on SPF for authentication
	will still fail. Precludes many customary features of
	mailing lists, such as "Subject:" tags, list footers/disclaimers,
	etc.

(though note that *digest* delivery should `just work' in either case,
 with no changes [though the DMARC FAQ doesn't mention that])


-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."


More information about the gnhlug-discuss mailing list