I realize that these are site-specific, but I'd like some suggestions
and guidance on DKIM signing policies. In general, it must be based
on trust, so that an MTA should only sign messages from trusted
senders. Of course, there are degrees of trust.
I'm responsible for the central e-mail server, available to everyone
at this university, but some departments operate their own e-mail
servers. Both e-mail clients and other e-mail servers reside on the
same IP networks. How does the trust relationship apply in this
environment?
Certainly the central MTA should sign e-mail messages when the user
has authenticated with SMTP. Messages originating on the server
itself should also be signed. We also have some Unix workstations
where mutt, for example, invokes /usr/lib/sendmail directly. It's the
sendmail daemon on the client that relays the message to the central
MTA, doing this without user authentication. I believe that these
messages should be signed as well. This leaves all of the other
workstations that use SMTP to connect to the central MTA. The users
are trusted to an extent because they are employees or students, but
they may not authenticate to the MTA. I'd be inclined have it sign
only authenticated messages in this case.
Of course, messages from both internal and external e-mail servers
should have their signatures verified. As a reasonable policy, that
should apply to all messages that are not signed by the MTA.
Are there any disadvantages to DKIM-signing? Does this affect e-mail
forwarding, for example? How about cases where a user sends messages
through their ISP's e-mail server but sets the sender to their
university address? Will anything stop working when I enable signing?
--
-Gary Mills- -Unix Group- -Computer and Network Services-
Received on Tue Oct 26 2010 - 15:03:17 PST