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:bmcdowell(_at_)paypal-inc(_dot_)com]
=>> Sent: Thursday, September 09, 2010 10:21 AM
=>> To: MH Michael Hammer (5304)
=>> Cc: dkim-ops(_at_)mipassoc(_dot_)org
=>> 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
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops