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 [email protected] http://mipassoc.org/mailman/listinfo/dkim-ops
