First want to say that I (we - wmich.edu) don't have any real operations experience with DKIM. We also are a much much much smaller site (~50K mailboxes) that what most of you are involved. Therefore I mostly sit in the stands watching the "game" (lurking) while I take notes and learning from pros playing it. :)
On Sep 9, 2010 at 12:36 -0400, MH Michael Hammer (5304) wrote: =>> -----Original Message----- =>> From: McDowell, Brett [mailto:[email protected]] =>> Sent: Thursday, September 09, 2010 10:21 AM =>> To: MH Michael Hammer (5304) =>> Cc: [email protected] =>> Subject: Re: [dkim-ops] subdomain vs. cousin domain (when =>> deploying"discardable") =>> =>> Since Hector (rightly) didn't let me leave this thread in a state of =>> disagreement, I'll pick-up on what I think is the most important =>> concept to get right. =>> =>> On Sep 4, 2010, at 1:04 PM, MH Michael Hammer (5304) wrote: =>> > My personal belief is that use of subdomains presents less of an =>> > increase in attack surface than use of analog domains. =>> =>> That's the $64K question isn't it. Will more customers fall prey to =>> phishing attacks if norms like domain-inc.example are reinforced as =>> "trustworthy" than if criminals discover and exploit an un-protected =>> subdomain like corp.domain.example? =>> => =>There's a lot more than $64k riding on it. => =>Perhaps I need to be more specific as to why I recommend what I do. My =>general recommendation would normally be to use a very different domain =>but in the particular case of Paypal the issue is complicated by =>existing practices. What does entries that can't get a different domain in the same TLD do? i.e. .edu are restricted to one domain per entity by the registrar. (Yes, they can get a domain in a different TLD, but is that what we really want them to do?) =>The case we are discussing is a situation where the corporate users are =>using the same domain as the transactional domain and you need to do =>something to address the conflict between strict policies to protect =>against (transactional) phishing and corporate use which results in mail =>going through lists, etc. with the commensurate risk of authentication =>breakage. We see ourselves in the same place, though it will take months/years to get there. We have user and transactional (billing notices, class registration, etc) e-mail on the same domain. =>If the only issue you are trying to resolve pertains to mailing lists I =>would propose another solution vector. Don't allow employees to =>participate in mailing lists using work email addresses. A variation =>would be to require employees who participate in mailing lists to use a =>separate domain that is only used for mailing lists. You could then tell =>receivers that if the mail for that domain did not come through a list =>they should throw it away. We used to have user's spread across several domains, but have spent the last 10-12 years getting all e-mail under one domain. (The addresses in the other domains are still accepted as things like faculty publications can stay around for a while. :) -- *********************************************************************** Derek Diget Office of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ *********************************************************************** _______________________________________________ dkim-ops mailing list [email protected] http://mipassoc.org/mailman/listinfo/dkim-ops
