[375] in Hesiod
Re: HESIOD type=maildrop class=IN, Sendmail
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Mon Jan 26 23:05:34 1998
Date: Mon, 26 Jan 1998 23:04:39 -0500
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>
Cc: hesiod@MIT.EDU, rsw@glue.umd.edu
In-Reply-To: Michael C. Richardson's message of Sat, 24 Jan 1998 20:02:31
-0500, <199801250102.UAA08057@istari.sandelman.ottawa.on.ca>
Date: Sat, 24 Jan 1998 20:02:31 -0500
From: "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>
Russell and I have been arguing over the merits of having maildrop in the
IN classes. I feel that it isn't something I want to do. I prefer hesiod
zones, because I can make a local machine be the hesiod root (in my case,
my mail server), and can arrange to be a secondary for all domains that I
want to do remappings for. Since I'm authoritative for ./hs, I answer no
without any network traffice.
FWIW, the general design philosophy behind Hesiod, at least originally at
Athena, is that if you need the ability to do overrides, then there
should be some local file/database which the program consults first, and
the fallback to Hesiod is used only if it isn't in the local file.
Also, keep in mind that unless you're using DNS sec, Hesiod is not
secure. It would be all too easy to poison your DNS cache so that mail
to a particular user gets redirected to the wrong place. At MIT, we
have all of our client workstations route mail to a central mailhub
(this also means that we don't have to worry about mail getting stuck on
client workstation), and on the central mailhubs we use an aliases file,
not Hesiod, in order to handle the destination routing.
- Ted
