[dmarc-discuss] How does *this* mailing list interact with dmarc?
msk at fb.com
Fri Jun 22 06:48:28 PDT 2012
The common practice right now is to develop reputation on the "d=" value
for DKIM, not the "d="/"s=" combination. So subdividing your mail streams
as you describe is done by creating different signing domains under your
main domain (e.g. "d=users.example.org" vs. "d=transactions.example.org").
You're right about how keys could be used per-user, but for any given
signing domain you have no idea whether that domain is using keys that
way. We had the same debate about use of "i=", which can contain a
userid, but can also be randomized by spammers to avoid bad reputation
Your last paragraph sums up the negative reputation avoidance problem
On 6/22/12 6:30 AM, "Brian Corrigan" <bcorrigan at majorleaguegaming.com>
>Forgive the new guy...
>One feature of DKIM that seems very interesting (and potentially
>applicable) is the ability to divide the key namespace up using
>selectors. If I understand correctly, wouldn't this address many of
>the problems being discussed here?
>For example, in the case of a single (.edu?) domain that sends both
>transactional and user-generated emails, isn't it possible to use a
>separate key for each message type?
>For that matter, if you used a key per user (granted, this would be a
>*lot* of keys) you could verify not only that the message originated
>from a specific domain, but from a specific user on that domain. On
>the issue of mail forwarding agents, conceptually, wouldn't using per
>user keys solve the issue?
>Finally, maybe a more practical approach is to have an arbitrarily
>large number of keys and just use a random one each time you sign.
>On Wed, Jun 20, 2012 at 11:24 PM, John Levine <johnl at taugh.com> wrote:
>>>Anyhow this "alias" forwarding break DKIM is common on many other
>>>platforms/configs and DMARC points where.
>>>How can we help?
>> Encourage those systems to sign their outgoing mail so recipients can
>> develop a reputation for them.
>> DMARC is not a FUSSP. It is useful for a small but significant part
>> of the mail ecosystem for domains where all the mail comes from a
>> known, controlled set of hosts, and a lot of phishing is targeted at
>> them. None of the other anti-spam and reputation techniques are going
>> away, and DMARC isn't a substitute for them.
>> dmarc-discuss mailing list
>> dmarc-discuss at dmarc.org
>> NOTE: Participating in this list means you agree to the DMARC Note Well
>dmarc-discuss mailing list
>dmarc-discuss at dmarc.org
>NOTE: Participating in this list means you agree to the DMARC Note Well
More information about the dmarc-discuss