On 01/23/2016 05:08, Ben Greenfield via dmarc-discuss wrote:
> My name is Ben Greenfield and I have been running a couple of smalltime mail
> servers (fewer then 200 messages a day) not accounting for an occasional
> blast from a 1,500 person listserv.
Welcome Ben, and hopefully you got a response off-list (or that I missed
it).
> 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).
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. 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.
_______________________________________________
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)
