> On Feb 1, 2016, at 9:53 PM, Steven M Jones <s...@crash.com> wrote:
>
>> Should one use one DKIM key for each domain or a single domain tie it to the
>> ip addresses and the DNS text records sort out whether the domain is
>> associated with the sending ip’s DKIM key.
>
> I may just not be following you, but DKIM doesn't mandate or require any
> association with IP addresses. And in fact that's a good thing, because
> it allows DKIM-signed messages to be forwarded and still be verifiable
> (provided the message isn't altered).
I guess I was a little sloppy in my phrasing. I’m wondering if I’m using
virtual hosts should I generate individual DKIM keys.
>
> DKIM signatures include information about which domain produced/attached
> the signature, and how to retrieve the public key via DNS in order to
> verify that signature. If you look at the DKIM-Signature: header in a
> message, this information is in the selector ("s=...") and signing
> domain (in full, the Signing Domain IDentifier, or SDID - the "d=...")
> fields.
>
> You might choose to only deploy a given signing key on a given host,
> thereby effectively creating that association. But DKIM allows you to
> use the same signing key on multiple hosts, and many people do this.
So really I should consider a DKIM key as quite transportable.
> You
> can deploy multiple keys under different selectors for one domain to one
> or more hosts. Or you might deploy keys for several different
> (sub-)domains to one or several hosts. There's a lot of flexibility if
> you need it.
>
> Check the DKIM RFC: https://tools.ietf.org/html/rfc6376
> The DKIM Service Overview: https://tools.ietf.org/html/rfc5585
>
> Or look for other resources on the DKIM.org site: http://dkim.org/
>
>
>> My question regarding mailman is that I see discussion of problems with
>> listserv’s but so far I haven’t seen any that seem to apply to my situation.
>
> The problems associated with mailing lists, or more generally "indirect
> mailflows," come when a message submitted to the list is forwarded out
> to the list recipients such that SPF no longer passes, and if present a
> DKIM signature no longer verifies because the message was altered in
> some way.
>
> So if the original sending domain has published a restrictive DMARC
> policy (not "p=none"), the message would fail the DMARC check and would
> likely be quarantined or rejected - if the receiver didn't know the
> message had come through a list, and chose to allow an exception for
> that list/host.
>
>
>> We have an internal staff mailing list and a public mailing list.
>> Should I look in the Maillman docs for the right configuration?
>> Is their a consensus on what to do with listservs?
>
> You might want to check the MailMan site, docs, or discussion forums.
>
> But MailMan includes an option that effectively works around the
> problems with strict DMARC policies and indirect flows by altering the
> RFC5322.From: header of the outgoing message to use the mailing list's
> address. Note that not everybody likes this approach, but it does work.
>
> If you check the "General Options" screen for the list admin interface,
> you'll see an option described as:
>
> "Replace the From: header address with the list's posting address to
> mitigate issues stemming from the original From: domain's DMARC or
> similar policies."
>
> I've used the "Munge From" setting in cases where list participants'
> strict DMARC policies (or those of their mailbox provider) were or would
> cause issues.
>
>
> One approach that would avoid this kind of workaround was announced in
> October. The Authenticated Received Chain, or ARC, would allow mailing
> lists and other intermediaries to include the email authentication
> results they observed when a message arrived, and some signatures of
> same, that the ultimate recipient might then choose to use if/when
> regular DKIM/SPF/DMARC checks fail. For more info on that head over to
> http://arc-spec.org.
>
> Hope that helps,
> —Steve.
>
Thank you for your answers,
Ben
_______________________________________________
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
