On Tue, Oct 26, 2010 at 8:03 AM, Gary Mills <mills_at_cc.umanitoba.ca> wrote:
> 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?
You need to be able to identify the degree of trust and sign (or not
sign) accordingly. Your description below was pretty good.
> Certainly the central MTA should sign e-mail messages when the user
> has authenticated with SMTP.
Yes, there is a direct connection between the user and the email, smtp
auth is a very good signing decision maker.
> Messages originating on the server
> itself should also be signed.
Cronjobs, what else is there that will be generated on the server?
> 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.
But it is a lesser degree of trust. So you might be better off
signing it with a different subdomain.
> 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.
I'd agree with you on that one.
> 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.
Yeah, opendkim is pretty smart about that.
In general, you need to segment logically:
1. Relay for IPs, always sign
2. Relay for IPs, sign depending on sender.
3. Relay for IPs, never sign (not in InternalHosts file).
4. SMTP Auth, sign
5. From localhost, always sign
6. Determine which, if any, of the the above requires separate
keys/signing domains.
I'm sure there are more, but I feel most cases will be covered by the above.
> 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?
I can't think of any disadvantages, but I can think of one advantage
in particular: making $BIG_ISP a little less likely to blacklist you.
Since we started signing with (first DomainKey, then now) DKIM, we
have had no issues with deliverabilty to Yahoo in over 2 years. (We
are a webhoster by the way, so our user base is simply using either
webmail, or smtp auth to send through us, or they are just forwarding
their email to a real aol or gmail mailbox and handling sending from
there).,
Note that my email specifically does not talk about ADSP. You should
really investigate ADSP before you use it because it can cause
deliverability issues (for example, from a mailing list). It's not
guaranteed to cause problems, but it _can_.
--
Regards... Todd
I seek the truth...it is only persistence in self-delusion and
ignorance that does harm. -- Marcus Aurealius
Received on Tue Oct 26 2010 - 15:38:16 PST