On Sep 9, 2010, at 3:10 PM, Derek Diget wrote: > > 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?) > >
Ah, right! This is also a problem for .gov organizations. I suppose clarity is the upside of having choice removed ;-) > > =>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. > I think the phrase missing from Mike's comments above is "using the same [highly phished] domain as the transactional domain". So if wmich.edu is not a target for phishing, you may not even want to advertise "discardable" as your policy. The broken-signature-equals-lost-mail problem is only for those of us advertising "discardable" (in ADSP or any other sort of arrangement. But, before we dismiss the problem you raised... .gov domains *are* highly phished and they share this TLD problem with .edu. That said, how many .gov-ers need to (or are allowed to) participate in public mail lists. Ugh! We simply have to fix the root cause of MLM's breaking DKIM signatures. > > =>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 _______________________________________________ dkim-ops mailing list [email protected] http://mipassoc.org/mailman/listinfo/dkim-ops
