Philip Hazel wrote the following about "Re: [EXIM] Feature request" on Thu Nov 20 04:47:47 1997
>
> On Wed, 19 Nov 1997, Chris A. Mattingly wrote:
>
> > I just started toying with exim yesterday, and find its ease of use combined
> > with lots of functionality to be a big bonus. The only thing that is
> > keeping me from testing it in a near-production environment is the lack
> > of hesiod support.
>
> As far as I know, you are the first person to raise this in connection
> with Exim.
Wow.. I'm the first at something. That's a change. :)
> > [1] A simple hes_resolve("username","pobox") returns a char ** containing
> > in it "POP mailhost.name username". Match mailhost.name against the
> > canonical name of the local machine. On a match, do local delivery, if
> > not, forward it directly to the mailhost.name returned from hesiod.
>
> In Exim terminology, all you would be doing is using hesiod as an
> alternative form of aliasing, with slightly unusual parsing of the
> output. If "hesiod" were implemented as yet another form of lookup item,
> you could use something like this
>
> hesiod:
> driver = smartuser
> new_address = "${if match{${lookup{$local_part}hesiod{pobox}{$value}{}}\
> {^POP ([^.]+)\\\\.(\S+)}{$2@$1}{fail}"
Ahhh, I love nasty regex's. :)
> However, there are questions to be asked about hesiod. I seem to recall
> that it is sort-of DNS based? Yes? In that case, there is a big problem,
> because as well as "yes" and "no", a DNS-based lookup can yield "don't
> know" - i.e. "try again later". Currently, Exim lookups of this type
> expect to succeed or fail, so some planning and thought would need to be
> done before adding anything of this kind.
hesiod is effectively just an extra .db file loaded by BIND. So, yes, it's
purely DNS based.
And, depending on which version of the hesiod library you're using (which
isn't really necessary, since you can just piece together the 'right'
DNS lookup string[1], but it makes things easier. :) ), you'll get different
error codes returned. For example, doing a hes_resolve("dfwe43a","pobox")
yields an errno of 146 (ECONNREFUSED), even though the name server did
respond with something. Older versions of the hesiod library handle this
"differently", and just always return 0 on a success or failure.
[1] - Query class of HS, query type of TXT on
<user>.<hesiod type>.ns.[domain] returns
<user>.<hesiod type>.ns.[domain] "TYPE TYPEsText user"
e.g.: host -c hs -t txt camattin.pobox.ns.eos.ncsu.edu
camattin.pobox.ns.eos.ncsu.edu TXT "POP eos00mh.eos.ncsu.edu camattin"
So, one could form the nasties to do that, and rely on the resolver libraries
on the system to be a bit more consistant than MIT code.
Or, one could see how the sendmail folks have handled it.. not to say
that they've done it perfectly, but whatever they've done has been working
quite fine in our enviroment. (Though what our nameservers return to
the hes_resolve function is formatted a little differently, so we did
have to 'fix' that with each new version of sendmail).
-Chris
--
Chris Mattingly | My views are not necessarily those of my employers
camattin@??? |
NC State University/ITECS | "Good programmers write good code; great
Systems Programmer | programmers 'borrow' good code." -- Mike Gancarz
--
*** Exim information can be found at
http://www.exim.org/ ***
