Brett,
The circumstances for Paypal are complicated because of existing
non-standards based arrangements and assertions. If it were my decision
I would go with corp.paypal.com based on the following logic.
Using a different domain opens up the cousin domain issue as you
indicated. This involves trying to educate a broad enduser constituency
and would at best result in partial success. An example of this type of
situation is when banks are acquired and there is a transition to
another domain for the customers. The best you can hope for is partial
success with the usual consequences in the face of active abuse by the
bad guys.
My personal belief is that use of subdomains presents less of an
increase in attack surface than use of analog domains.
Using a subdomain presents other issues but ones which I personally
believe are likely more controllable. The DKIM enforcement policies you
refer to are as I understand self imposed ones. We had the "tree
walking" discussion during both DKIM and ADSP development and the
decision was to have each subdomain publish it's own records. Paypal
would have to deal with those parties it has made private arrangements
with but that is the nature of changes that impact such arrangements.
This is a much more controllable (if potentially time consuming)
situation than dealing with the universe of endusers.
The other issue is the fact that an element of risk is created because
of the MLM issues related to breaking signatures. If it weren't for the
MLM issue and possibly recipient use of vanity domain forwarding, it
isn't clear how much meaningful signature breakage would occur for
outbound Paypal mail regardless of domain.
One question that comes to mind is whether the issue is centered on
mailing lists or if there are broader issues. If it is centered on
mailing lists, how broad is the need for Paypal employees to send mail
through lists in furtherance of business needs (vs personal
participation using a corporate account because it is convenient).
Spending a little time analyzing this may provide some assistance in
determining how to address the business needs.
It would obviously be important to make clear to endusers that
transactional mails are never sent from the corp.paypal.com subdomain.
There is certainly an educational component required regardless of which
approach is selected. Any time there is a change in behavior on the part
of an abused domain it opens up the potential for abuse specific to the
changes involved.
Hope this helps.
Mike
-----Original Message-----
From: dkim-ops-bounces(_at_)mipassoc(_dot_)org
[mailto:dkim-ops-bounces(_at_)mipassoc(_dot_)org]
On Behalf Of McDowell, Brett
Sent: Friday, September 03, 2010 11:32 AM
To: dkim-ops(_at_)mipassoc(_dot_)org
Subject: [dkim-ops] subdomain vs. cousin domain (when
deploying"discardable")
Hello everyone, this is my first post to the list. I am a new
subscriber.
I have been asking opinions from other DKIM deployers about "best
practice" regarding some changes we are considering/testing at PayPal.
As background:
-- We DKIM sign all mail from paypal.com (and other consumer-facing
domains) - no change planned
-- We have ADSP=discardable for paypal.com, etc. - no change planned
But, some employees need to use external mail lists so we are setting
up
an alternative sending domain:
-- paypal-inc.com does not have ADSP=discardable (but we may publish
an
ADSP=all for it, TBD)
-- corp.paypal.com is another consideration vs. paypal-inc.com... any
opinions about which is "better"?
Some considerations on my mind regarding paypal-inc.com vs.
corp.paypal.com are:
-- paypal-inc is a "cousin domain" which some feel is a bad idea to
legitimize, i.e. users should be conditioned to distrust anything
other
than your well known brand.
-- some DKIM enforcement policies require the same treatment for all
subdomains as the top domain, so having paypal.com = discardable and
corp.paypal.com = all would "break" these systems
-- there are other security and operational considerations that
benefit
from moving enterprise functions off of the consumer-facing domain and
therefore moving the mail streams along with the app servers is at
least
convenient
Anyone here have an informed opinion on which way to go? I've heard
opposing views from very savvy and experienced deployers so I thought
it
would be a good discussion topic for this mail list.
Best Regards,
---
Brett McDowell, Technology & Policy Evangelist
PayPal Information Risk Management
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops