[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Talking with myself...

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, 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 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@[@]. Yes, this is
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 ([ ...
  Subject: Delivery problems with your mail

  Transcript of the session follows:

  <smtp [] louhills@server.blaze.net.au 65535>: Trying to 
talk with myself!

  [rest of message follows]

Now, the envelope as sent was to louhills@[]. 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
"[]" to the $MAILCTL/db/localnames would get it to deliver
locally anyway, but even this failed to work. 

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.