On 9/3/10 8:32 AM, McDowell, Brett wrote:
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
The discardable assertion has placed you on the horns of a dilemma.
Since less than 100 domains make the discardable assertion, out of about
20 thousand domains being phished, administrators are likely to use this
assertion to construct filtering rules that consider any sub-domain of a
domain asserting dkim=discardable to represent a type of scorched Earth,
where these domains must have an Author-Domain signature to be accepted,
and if not, they will be discarded. The alternative of using a "cousin"
domain is not good either. We have had a fair amount of trouble on the
web when "cousin" domains were used.
ADSP did not attempt to assert "unless otherwise overridden by the
existence of an MX record or ADSP policy assertion, the policy of a
higher ADSP assertion should extend to lower domains". This concept
was included in the TPA-Label draft, but was left undefined in the ADSP
RFC, so it would be anyone's guess how it might be handled. However,
not asserting some type of policy at these domains would undo
anti-phishing protections being sought. In other words, asserting
dkim=all at corp.paypal.com would likely allow any unsigned message
from this domain to be accepted. In the eyes of the recipient, this
would leave them being misled by a message they believed originated from
paypal.
On the other hand, for the more than 99% of the domains being phished
that have not yet made a dkim=discardable assertion in their ADSP
record, an alternative method could be used instead. This could be to
assert dkim=tpa-path. This would allow administrators of the domain to
then specifically specify how all sources of their From header fields
should be authenticated on a domain by domain basis. It would allow
just paypal.com to be used where stringent acceptance criteria can be
asserted for all acceptable sources of paypal.com messages. The
TPA-Label scheme should safely permit the use of most mailing-lists,
especially those that sign using DKIM.
If you are interested in obtaining a service to facilitate creation or
publication of a suitable TPA-Label list, contact me off-list.
Expressing an interest in this scheme seems the best way to get the ball
rolling, which should then off-load the work that might otherwise
confront email administrators.
-Doug
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops