[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Talking with myself...
On Sun, 31 Dec 1995, David Nugent wrote:
> Our ISP box has a troublesome user. Well, the user isn't troublesome,
> their Windows '95 configuration is. :) In any case, that problem brought
> to light a secondary problem I'm seeing with zmailer. We're running
> version 2.99.21 with a fairly stock router configuration.
>
> The problem at the user end is misconfiguration of their DNS searching.
> Our domain's (blaze.net.au) DNS is at 203.17.53.1, but the user is
> having some difficulty getting that set up (I know how to do it, the
> problem is explaining how to get this poor woman to do it! :-)). This
> same box (whose IP is 203.17.53.1) is also the mail server on which
> zmailer runs.
>
> Anyway, the result is that mail going out from her system onto the
> internet is being addressed from heraccount@[@203.17.53.1]. Yes, this is
^
typo?
Curious oddity with the router parser (showing that this above address
form is bogus):
1/48 [12:14pm skye]:~>router -i
ZMailer router (2.99.10mea #1: Sat Jan 21 13:48:32 MST 1995)
jmack@Phys.UAlberta.CA:/ZMdevel/zmailer2.99.10
Copyright 1992 Rayan S. Zachariassen
Copyright 1992,1993,1994 Matti Aarnio
z$ router louhills@[@203.17.53.1]
<jmack.interactive@skye.Phys.UAlberta.Ca>: address: louhills@[@203.17.53.1]
search_res: deferred: .17.53.1.@.in-addr.arpa: ptr (unknown server/no recovery) error
<jmack.interactive@skye.Phys.UAlberta.Ca>: deferred: NS:.17.53.1.@.in-addr.arpa/ptr: louhills@[@203.17.53.1]
(((hold NS:.17.53.1.@.in-addr.arpa/ptr louhills@[@203.17.53.1] default_attributes)))
I think it should really be:
z$ router louhills@[203.17.53.1]
<jmack.interactive@skye.Phys.UAlberta.Ca>: address: louhills@[203.17.53.1]
(((smtp [203.17.53.1] louhills@server.blaze.net.au default_attributes)))
z$ ^D
> antiquated and I realise that this should be avoided if possible.
> However, zmailer cannot deliver replies to that address, and winds up
> bouncing any mail to that address with the following:
>
> From mailer-daemon@blaze.net.au <date>
> Received: from servder.blaze.net.au ([203.17.53.1) ...
> ..
> Subject: Delivery problems with your mail
> ..
>
> Transcript of the session follows:
>
> <smtp [203.17.53.1] louhills@server.blaze.net.au 65535>: Trying to
> talk with myself!
This error diagnostic is likely not originating from ZMailer, but comes
from the Win95 machine's SMTP daemon (which machine you say IS misconfigured -
sounds as if it even thinks it's IP address is 203.17.53.1) :-0
>
> ..
> [rest of message follows]
>
>
> Now, the envelope as sent was to louhills@[203.17.53.1]. Obviously
> zmailer has resolved that itself to server.blaze.net.au, which is
> correct. However, I'm guessing that this occurs /after/ the check for
> local delivery. To get around that, I thought that adding the
> "[203.17.53.1]" to the $MAILCTL/db/localnames would get it to deliver
> locally anyway, but even this failed to work.
is there any IP mapping in your routes file?, i.e.:
server.blaze.net.au smtp!203.17.53.1
(might cause more grief, however)
Are you using the "new" form of the localnames db ( or the "traditional"
one, a la previous to ZM-2.98)? In standard.cf, the new form is:
relation -lt ordered -f $MAILVAR/db/localnames -d pathalias thishost
whereas the old behavior (which I need to use for mapping to uucp) is:
relation -lt unordered -f $MAILVAR/db/localnames -d pathalias -b thishost
(along with changes to the localnames format from 2 entries per line for
the new format to a single entry per line for the older format):
localnames (old format):
...
in.edmonton.ab.ca
iskye
iskye.uucp
skye.phys.ualberta.ca
...
You might try the older format and see if that fixes things for the
misbehavor (but best to fix the Win95 machine...)
>
> Despite being frowned upon, shouldn't this form of addressing work
> anyway? Before I go through the process of looking at the .cf files
> again has anyone been down this path before and knows of a simple fix?
> Certainly this user's configuration needs to be fixed, but given that
> I've tried several times including a painstaking Windows95-blow-by-blow
> over the phone session with the user, I'd still like to get this working
> in the meantime as I don't think the present behaviour is incorrect.
How far away is the Win95 machine? - within walking distance :-)
Cheers,
--
James S. MacKinnon Office: P-139 Avahd-Bhatia Physics Lab
Department of Physics Voice : (403) 492-8226
University of Alberta email : Jim.MacKinnon@Phys.UAlberta.CA
Edmonton, Canada T6G 2N5
WWW: http://www.phys.ualberta.ca/~jmack/jmack.html