On Thursday, March 28, 2013 10:56 PM [GMT+1=CET],Tim Draegen wrote:
> On Mar 28, 2013, at 5:36 PM, Al Iverson <[email protected]>
> wrote:
> > On Thu, Mar 28, 2013 at 4:18 PM, J. Gomez <[email protected]>
> > wrote:
> > > Will DMARC make it hard for outsourced marketing mail operations?
> > >
> > > I just got this email (which is not spam, I subscribed to this
> > > marketing material) in which RFC5321.MailFrom and RFC5322.From
> > > are obviously not in allignment, which is understandable as the
> > > sending party (the outsourced marketing company) will want to
> > > handle themselves the bounces for that email campaign, but
> > > nontheless the RFC5322.From address has to be a subdomain of
> > > microsoft.com to give it "authenticity" in the eyes of the final
> > > recipient as it's the RFC5322.From address what the recipient's
> > > MUA will display to the user.
> >
> > Hard? From a technical perspective, no. There are other challenges,
> > though. - DMARC is new, not everybody knows about it or is prepared
> > to, or knowledgeable enough to implement it.
> > - The outsource provider (hi!) is typically dealing with (only)
> > marketing people at the client. This is not the DMARC-savvy
> > department. It's hard to make the case to the marketing people from
> > outside. What works better is that the security people inside the
> > client organization drive it home sideways, then we help to
> > implement
> > it.
> > - Adjusting the configuration on the outsource provider side isn't
> > hard. But the client is in the driver's seat, not the provider. The
> > client would need to choose to put some proper bits in DNS to allow
> > a
> > DKIM signature that properly aligns with the PRA, then request that
> > the provider update this configuration.
>
> Hi J. Gomez,
>
> Adding to Al's list, I'd add "Yes". There are quite a few outsourced
> marketing email providers that serve customers that do not have the
> ability or desire to go mucking with DNS to "do it right".
>
> Serving those customers is hard because they really want their domain
> in the "From:" header, and until registrar and email service
> providers partner to make it easier, DMARC will likely remain beyond
> the reach of said customers.
>
> Back to your example, though. A large company that wants DMARC would
> likely delegate sub-domains for outsourced marketing providers to
> manage themselves. As Al said, controls that can be applied at the
> email domain level are relatively new, and getting organizations to
> incorporate this into their practices takes time (and effort!).
Thanks Tim for your insights on this issue.
Another outsourced email marketing approach is to use non-client-related
domains for both RFC5321.MailFrom and RFC5322.From. This way the outsourced
marketing company gets full access to make DNS customizations and therefore the
ability to easily get "Pass-results" for both SPF and DKIM, which also would
imply an easy "Pass-result" for DMARC if they chose to implement DMARC.
However, as DMARC ultimate purpose is to protect the brand of the sender, this
outsourced email marketing approach renders DMARC not that useful as the sender
is not using the client's brand domain in either RFC5321.MailFrom nor
RFC5322.From.
Consider for example this email (not spam, I subscribed to it) advertising some
SSL certificate products from Thawte. It seems they are using a company named
"rSys3" as their outsourced email marketing provider, which just use the
client's name ("thawte") as a subdomain of their own domain
("thawte.rsys3.com") for both RFC5321.MailFrom and RFC5322.From, and only in
the "Reply-To:" address they point to the thawte.com domain.
=====================sample outsourced email marketing email
begins======================
Return-Path: <[email protected]>
X-Original-To: [email protected]
Delivered-To: [email protected]
Received-SPF: pass (thawte.rsys3.com: 12.130.136.47 is authorized to use
'[email protected]' in 'mfrom' identity
(mechanism 'ip4:12.130.136.0/22' matched)) receiver=mta.example.com;
identity=mfrom; envelope-from="[email protected]";
helo=om-thawte.rsys3.com; client-ip=12.130.136.47
Received: from om-thawte.rsys3.com (om-thawte.rsys3.com [12.130.136.47])
by mta.example.com (Postfix) with ESMTP id A9F89C6A
for <[email protected]>; Wed, 27 Mar 2013 08:02:37 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=responsys; d=rsys3.com;
h=MIME-Version:Content-Type:Date:From:Reply-To:Subject:To:Message-ID;
[email protected];
bh=uLBQ69hdunDmvRob0Dz1ADlk1O4=;
b=Vdj7UvgZ5VLDzQ8MEKK4cb/oFxCF7bEXsBKlxKQdDkeEoxXVamSWDVBOACTCPMeJB1nzz97EEhQc
dKVEooG6pOCIgcghO3floRDCUuyXqU2PXbh2cLBRo9t1kfA1QyyF3hH8QlpLaVftsg0fQ+XADYp1
W2sLyrj1KlB5eIMani0=
DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=responsys; d=rsys3.com;
b=LofjjZg6YGdyZc4H5BDDK8S/5Crl8MPu0xiR+peKmLtOSpSYbwx5FjYK0sxeM2F0I+u+qYZ/tHK5
KMxcZQsmikrf+KUIp7eo+XVODgWqi17RZojqzaGFh1Zgbnr6ypqWQ9tXVmEktClL8t+mX0WoNA7U
3HsX18qrLN5Epa6Q0pc=;
Received: by om-thawte.rsys3.com id haacp0162isf for <[email protected]>;
Wed, 27 Mar 2013 00:02:35 -0700 (envelope-from <[email protected]>)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----msg_border"
Date: Wed, 27 Mar 2013 00:02:35 -0700
From: "Thawte Digital Certificates" <[email protected]>
Reply-To: "Thawte Digital Certificates" <[email protected]>
Subject: =?UTF-8?B?RG93bmxvYWQgVGhhd3Rl4oCZcyB3aGl0ZXBhcGVyIG9uIHRoZSBo?=
=?UTF-8?B?aXN0b3J5IG9mIFNTTCBlbmNyeXB0aW9uIGFuZCB3aW4gYW4gOEdCIFVTQg==?=
X-cid: thaw.1055.1
X-sgxh1: iLiLxgHtLJhQJhu
To: [email protected]
Message-ID: <[email protected]>
======================sample outsourced email marketing email
ends=========================
This approach does indeed fully authenticate the sender, but it is highly
unlikely that such a sender ("rsys3.com") would be in the recipient's (or the
recipient's mailbox provider's) domain whitelist, so all that successful
authentications could be moot in the end for practical purposes.
Also, this approach is highly suspicious to receivers, as the advertised
brand's domain is absent from both RFC5321.MailFrom and RFC5322.From, see for
example this comment:
http://proxy.org/forum/lounge/1799-email-adbrite-rsys3-com-phishing.html
My guess here is that the outsourced email marketing company had such a hard
time getting hold of someone technical at it's client (to get them to customize
some resource records in the client's DNS), that they just took the shortcut
approach of using their own domain for both RFC5321.MailFrom and RFC5322.From
in order to secure a Pass-result for both SPF and DKIM. Your opinions?
Regards,
J. Gomez
_______________________________________________
dmarc-discuss mailing list
[email protected]
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)
