IETF Logo Mail Archive

Re: [dmarc-ietf] Proposing an extension to DMARC to optionally requireSPF and DKIM

Franck Martin <fmartin@linkedin.com> Mon, 01 April 2013 23:28 UTC

Return-Path: <prvs=7962611cc=fmartin@linkedin.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764E211E810D for <dmarc@ietfa.amsl.com>; Mon, 1 Apr 2013 16:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Level:
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mG98acz8IZKe for <dmarc@ietfa.amsl.com>; Mon, 1 Apr 2013 16:28:09 -0700 (PDT)
Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id B9B9411E80FA for <dmarc@ietf.org>; Mon, 1 Apr 2013 16:28:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1364858889; x=1396394889; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=9Pi4D1pUC5aVPAqT5gF+u42L2ImnB+YsYbJQGyvdnrM=; b=qtGVDfueYhI5BGZ9zCPrrbgsb8K5aaqidLekXYNz49pKNNAfwgyA9EqY vpO+1AeBZO6UIMWcDxmEhjI1K70JDKikAdGQY8Clvn8pGNapL07n+MJ20 S+VZkW4gsBbkypy/bHOVLel/+vkouvPs6wuuGHj80+kFYwPkdUzWf/X+5 c=;
X-IronPort-AV: E=Sophos;i="4.87,390,1363158000"; d="scan'208";a="43783513"
Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.2.328.11; Mon, 1 Apr 2013 16:28:03 -0700
Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Mon, 1 Apr 2013 16:28:03 -0700
From: Franck Martin <fmartin@linkedin.com>
To: "J. Gomez" <jgomez@seryrich.com>, "dmarc@ietf.org" <dmarc@ietf.org>
Thread-Topic: [dmarc-ietf] Proposing an extension to DMARC to optionally requireSPF and DKIM
Thread-Index: AQHOLzCOK/oLwi2Bx0KDLQhISA58Tw==
Date: Mon, 01 Apr 2013 23:28:03 +0000
Message-ID: <77426B543150464AA3F30DF1A91365DE52EA0C4E@ESV4-MBX01.linkedin.biz>
In-Reply-To: <80FFAE6594A84EB9BDC60EA75BC91597@fgsr.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.18.46.250]
Content-Type: text/plain; charset="utf-8"
Content-ID: <160E39875DC214459A6475EAD42EB975@linkedin.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally requireSPF and DKIM
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmarc>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2013 23:28:10 -0000


On 4/1/13 4:15 PM, "J. Gomez" <jgomez@seryrich.com> wrote:

>On Monday, April 01, 2013 11:15 PM [GMT+1=CET], Terry Zink wrote:
>
>> I am proposing an extension to DMARC. Whereas today DMARC requires
>> one of a DKIM pass or SPF pass, I propose we extend DMARC so that is
>> has the *option* to require both.
>>
>> (...)
>>
>> Let's assume that BigBank.com has been dutiful and has published a
>> DMARC record. The problem occurs when Learning.edu gets compromised
>> and starts sending out spam. If a user starts sending out spam from
>> joe@learning.edu, we can detect this and shut it down. But what
>> happens if they start sending out mail as security@bigbank.com?
>> 
>> example.com ------------+
>>                         |
>> BigBank.com ------------+----> Microsoft Forefront IPs ----> Internet
>>                         |
>> Learning.edu            |
>>  security@bigbank.com --+
>>
>> (...)
>>
>> Extending DMARC this way lets brands/domains protect their outbound
>> reputation behind a shared service without worrying whether or not
>> some other customer will spoof them.
>> 
>> Make sense?
>
>I does make sense. I also like the explanation in your blog:
>
>http://blogs.msdn.com/b/tzink/archive/2012/10/18/how-should-large-financia
>l-institutions-use-hosted-filtering.aspx
>
>In a multitenant cloud environment, and/or when you are giving customers
>a MTA-smarthost service to gateway their mail to the Internet, you cannot
>be sure that they will always be signing their email with DKIM, and you
>usually will not have their private DKIM keys to sign their email
>yourself as it flows through the smarthost towards the Internet, so
>taking the DMARC oportunity to close this hole in SPF is golden.

Google apps, send grid, messagebus, (and many other ESPs) do not have
problem to create a DKIM key for each customer, to sign the emails that
pass through them. We used to have open-relays because they were easy to
setup/manage, but we moved away from them because they were insecure.

v2.23.0 | Report a Bug | By Email