[ On Tue, July 22, 1997 at 01:11:04 (-0700), John Henders wrote: ]
> Subject: IP literal - what to configure to make the local host work?
>
> I've been getting people sending mail to postmaster@[my local host's ip]
> on one of my servers and am getting this error with exim's default
> config ipliteral driver.
I've seen the same thing with Smail's new HELO/EHLO verification
features too.
The broken mailers I've encountered are MH and Netscape.
The syntax they are using is strictly against the rules of SMTP's
syntax. I've no idea why the authors of these packages thought they
could use the broken syntax they do use. The RFCs explicitly say that
additional identifying information from the client may *follow* the
domain literal but the basic syntax is clearly just "HELO host/lit".
I've managed to convince MH to use the correct hostname by fixing its
configuration which then makes it avoid using the broken HELO syntax.
For example here's my /usr/contrib/mh/lib/mtstailor (I've added the
explicit clientname setting):
mmdfldir: /var/mail
mmdflfil:
hostable: /usr/contrib/mh/lib/hosts
# this causes HELO verification to fail
#servers: localhost \01localnet
servers: mail
clientname: ns.weird.com
sendmail: /usr/sbin/sendmail
lockstyle: 0
This may not work if the MH files are shared with many hosts, but I
didn't have MH source available to fix the real problem. If anyone does
create a patch to MH I'd sure like to have it though.
Netscape's configuration can seemingly be corrected too, but I've only
had to make the unix versions of 3.01 work, and I don't think I had to
do much of anything except maybe set the SMTP server name to a FQDN.
I've heard that Netscape isn't very responsive at fixing even standards
conformance problems unless you're a big customer of theirs, but I'm
hoping to submit an official bug report to them anyway once I've had a
chance to play with the non-unix clients.
I assume exim has a way of specifying a list of addresses or hostnames
for clients which are permitted to fail the HELO/EHLO verification and
that may be your last resort if local clients cannot be configured to
operate correctly within the SMTP syntax specifications.
--
Greg A. Woods
+1 416 443-1734 VE3TCP <gwoods@???> <robohack!woods>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
