[371] in Hesiod
Re: HESIOD type=maildrop class=IN, Sendmail
daemon@ATHENA.MIT.EDU (Russell McOrmond)
Fri Jan 23 13:03:38 1998
From: Russell McOrmond <russell@flora.ottawa.on.ca>
To: rsw@Glue.umd.edu (Randall S. Winchester)
Date: Fri, 23 Jan 1998 13:00:21 -0500 (EST)
Cc: russell@flora.ottawa.on.ca, hesiod@MIT.EDU, maildomain@flora.org
In-Reply-To: <Pine.SOL.3.95q.980123022300.6992F-100000@atlantis.csc.umd.edu> from "Randall S. Winchester" at "Jan 23, 98 02:33:37 am"
Randall S. Winchester wrote:
> OPPS that was class=hs. We plan to migrate to class=in when we do some cell
> merging. Hesiod is supported (being integrated...) in BIND 8.8.x in the form
> of class=IN. This will be the long term future of hesiod most likely (IMO).
Bind 8, and even the 4.9.5 I am using also directly supports the use of
class=HS as well, which is what I am doing on FLORA. I am suggesting,
however, that there are problems with the migration to class=IN that
needs to be fully looked into before HESIOD moves that direction.
The migration to class=IN, if you query any DNS servers other than your
own servers, is going to cause you problems. What we are trying to do
with the HESIOD type=maildrop information is to create a network of sites
that could share the load in addressing community-based domains which are
comprised completely of 'forwarded' email addresses. The more sites that
participate in this mapping, the more shortcuts in Email delivery that
can be done, leaving the MX listed sites to only have to handle Email
delivery for those sites not participating, or for the bouncing of
invalid Email addresses.
In this scenario, the more participating sites the more robust the
community Email addressing becomes.
What we are doing in Sendmail is the following:
--cut from http://www.flora.org/flora/server/hes-sendmail-mc.html --
LOCAL_CONFIG
# Declare mbt as a hash-lookup database:
Kmbt hash /etc/mbt.db
# Hesiod Database - look it up in the 'maildrop' hesiod type
Khesmail hesiod maildrop
LOCAL_RULE_0
# Use mailboxtable-database:
R$+ < @ $+ . > $: $1 < @ $2 > .
R$+ < @ $+ > $* $: $(mbt $1@$2 $: $1 < @ $2 > $3 $)
R$+ < @ $+ > $* $: $(hesmail $1@$2 $: $1 < @ $2 > $3 $)
R$+ < @ $+ > $* $: $(mbt $2 $: $1 < @ $2 > $3 $)
RERROR $* $#error $: $1
R$+ < @ $+ > . $: $1 < @ $2 . >
--cut--
Essentially, this is having Sendmail do the equivalent of:
hesinfo $EMAIL maildrop
on any $EMAIL address that sendmail is sending out. The 'maildrop' type
essentially, when given an email address, will just return another
SINGLE email address (No pipes, multiple-addresses, or anything else
supported).
This construct causes HESIOD to look up information in any domain. If
one restricts themselves to class=HS , then through their use of a
private root-server, they can restrict which domains they will do this
mapping for. If they allow their hesiod to query class=IN, then they
will be making use of the regular Internet root-servers and will run into
various problems with other DNS sites that do not understand that query.
Your comment about publishing Email addresses via HESIOD, in a world of
SPAMMERS, is noted: If this became more universal, then HESIOD tables
could be used to collect Email addresses. I guess I see that as
security through obscurity as there are so many easier ways to collect
Email addresses. SPAM problems are going to need to be addressed in
other ways: PGP signature filtering of Email, authenticated SMTP, secured
DNS (Only allow participating sites to copy the zone?), and so on. We
cannot continue to hide ourselves from the public view in order to avoid
what should be an illegal act. Maybe the Bit tax, with the SENDER
charged for the transmission as with phone calls, will deal with that
problem eventually (Let's not follow that thread now ;-).
I remember reading that BIND does have a method of restricting zone
transfers and lookups. I suspect that this will be the appropriate way
to deal with SPAMMERS. Being able to lookup is not the problem as a SPAMMER
could do that by firing Email at your SMTP server with random Email
addresses, most of which you would try to bounce-back to their BOGUS
addresses - being able to transfer the zone and then build a list of
legitimate Email addresses from it is a problem.
--
Russell McOrmond, Internet Consultant: <http://www.flora.org/russell/work/>
Community Network Comments http://www.flora.org/russell/papers/newyears98.html
Ice storm press & links http://www.flora.org/russell/ice/
First Nations? - Attacked by MAI? http://news.flora.org/flora.perc/340
