prevent hostname resolving

prevent hostname resolving

Post by Marilyn Manso » Sun, 11 Nov 2001 03:40:17



I use Sendmail 8.12.0. The pppd is started at bootup in dial-on-demand mode with the dummy adress 10.64.64.64. But when sendmail is started the pppd connects to the net. In the logs I read sendmail tries to get the hostname by the dummy address pppd uses while the link is down. I couldn't prevent sendmail from this. I hope anyone can tell me a solution.

Thanks in advance...
                Robert Wappler

 
 
 

prevent hostname resolving

Post by Per Hedela » Sun, 11 Nov 2001 05:34:39




>I use Sendmail 8.12.0. The pppd is started at bootup in dial-on-demand
>mode with the dummy adress 10.64.64.64. But when sendmail is started the
>pppd connects to the net. In the logs I read sendmail tries to get the
>hostname by the dummy address pppd uses while the link is down. I
>couldn't prevent sendmail from this. I hope anyone can tell me a
>solution.

From cf/README:

confDONT_PROBE_INTERFACES  DontProbeInterfaces
                                        [False] If set, sendmail will _not_
                                        insert the names and addresses of any
                                        local interfaces into class {w}
                                        (list of known "equivalent" addresses).
                                        If you set this, you must also include
                                        some support for these addresses (e.g.,
                                        in a mailertable entry) -- otherwise,
                                        mail to addresses in this list will
                                        bounce with a configuration error.
                                        If set to "loopback" (without
                                        quotes), sendmail will skip
                                        loopback interfaces (e.g., "lo0").

--Per Hedeland


 
 
 

prevent hostname resolving

Post by Marilyn Manso » Sun, 11 Nov 2001 21:08:54


Basically this option does what I want from it, so a big thanks goes to Mr. Per Hedeland. But I don't understand what it means to "include some support for these addresses". In my mailertable there's a catch-all-key which should send outgoing mail to my ISP's smtp. Without the confDONT_PROBE_INTERFACES  macro it does so. With it I get an error-mail informing me about a denied relay at localhost.localdomain. This is an alias for the my local machine (class w as far as I know). I tried to add an OK for this
class to access.db by the line: "$=w       OK". I don't even know if this does what I think of, but sendmail don't complains. However, the behaviour is the same, relaying denied. With the README a newbie like me can't really help himself. I already read it several times. I suppose that the thing they mean is to add a line to sendmail.mc like "DAEMON_OPTIONS(`Name=<e.g. smtp>, Family=inet')dnl". But I'm not sure. So can anyone help me again?
I could also need a full documentation of the sendmail-test-mode (of course for a dummy like me). So, if anyone knows a source, please tell me.

thanks in advance ...
                Robert Wappler




>>I use Sendmail 8.12.0. The pppd is started at bootup in dial-on-demand
>>mode with the dummy adress 10.64.64.64. But when sendmail is started the
>>pppd connects to the net. In the logs I read sendmail tries to get the
>>hostname by the dummy address pppd uses while the link is down. I
>>couldn't prevent sendmail from this. I hope anyone can tell me a
>>solution.
> From cf/README:
> confDONT_PROBE_INTERFACES  DontProbeInterfaces
>                                    [False] If set, sendmail will _not_
>                                    insert the names and addresses of any
>                                    local interfaces into class {w}
>                                    (list of known "equivalent" addresses).
>                                    If you set this, you must also include
>                                    some support for these addresses (e.g.,
>                                    in a mailertable entry) -- otherwise,
>                                    mail to addresses in this list will
>                                    bounce with a configuration error.
>                                    If set to "loopback" (without
>                                    quotes), sendmail will skip
>                                    loopback interfaces (e.g., "lo0").
> --Per Hedeland


 
 
 

prevent hostname resolving

Post by Per Hedela » Sun, 11 Nov 2001 23:45:09




>Basically this option does what I want from it, so a big thanks goes to
>Mr. Per Hedeland. But I don't understand what it means to "include some
>support for these addresses".

In your case, since it's a "dummy address", it probably doesn't mean

the DontProbeInterfaces set, and no "support" added, you would get a
"mail loops back to me" error instead of local delivery. You can
probably live with that:-), if not you can just add [10.64.64.64]
(including the [brackets]) to /etc/mail/local-host-names, which will
create the "support".

In the general case it is more important though, i.e.  where you
actually want to handle mail addressed to "additional" IP addresses, or
more importantly their corresponding names (sendmail's lookup for which
was what caused your problem), you need to arrange it "manually" since
you've turned off sendmail's automatic adding of them to class w.

Quote:> In my mailertable there's a catch-all-key
>which should send outgoing mail to my ISP's smtp. Without the
>confDONT_PROBE_INTERFACES  macro it does so. With it I get an error-mail
>informing me about a denied relay at localhost.localdomain.

Ah, OK, that might be another side effect, which doesn't "normally"
occur I think. To determine exactly what is happening would require that
you be a little more precise though - i.e. in what situation does it
occur (i.e. how are you sending mail), and the *verbatim* error message
as well as ditto log entries.

Quote:> This is an
>alias for the my local machine (class w as far as I know). I tried to
>add an OK for this
>class to access.db by the line: "$=w   OK". I don't even know if this does
>what I think of, but sendmail don't complains.

No, that doesn't work, and even if it did it wouldn't have any effect,
since that "rule" is in effect anyway. Sendmail can only complain about
things it sees, and since it will never look for "$=w" in the access map
it won't complain...

Quote:> However, the behaviour is
>the same, relaying denied. With the README a newbie like me can't really
>help himself. I already read it several times. I suppose that the thing
>they mean is to add a line to sendmail.mc like
>"DAEMON_OPTIONS(`Name=<e.g. smtp>, Family=inet')dnl". But I'm not sure.

No, the DAEMON_OPTIONS isn't really relevant here.

Quote:>So can anyone help me again?

See above.

Quote:>I could also need a full documentation of the sendmail-test-mode (of
>course for a dummy like me). So, if anyone knows a source, please tell
>me.

The documentation available in the distribution is presented if you give
'?' as a command while in test mode...

--Per Hedeland

 
 
 

prevent hostname resolving

Post by Marilyn Manso » Mon, 12 Nov 2001 01:09:37


the "?" it test-mode produces a nice message: "HELP not implemented".
Thanks for the information. Before I post the next question I'll try to work it out myself. I hope this helps me to understand this stuff, someday.
 
 
 

prevent hostname resolving

Post by Per Hedela » Mon, 12 Nov 2001 11:24:25




>the "?" it test-mode produces a nice message: "HELP not implemented".

I guess you have a broken installation then, you should get something
like the below (in a standard, current, installation it will actually be
read from /etc/mail/helpfile). I never said that it was particularly
good or comprehensive, just that it was "the documentation available in
the distribution".

Quote:>Thanks for the information. Before I post the next question I'll try to
>work it out myself. I hope this helps me to understand this stuff,
>someday.

If that was intended as sarcasm, I'm afraid I have to admit that I
totally fail to see how my previous message could have provoked it.

--Per Hedeland

Help for test mode:
?                :this help message.
.Dmvalue         :define macro `m' to `value'.
.Ccvalue         :add `value' to class `c'.
=Sruleset        :dump the contents of the indicated ruleset.
=M               :display the known mailers.
-ddebug-spec     :equivalent to the command-line -d debug flag.
$m               :print the value of macro $m.
$=c              :print the contents of class $=c.
/mx host         :returns the MX records for `host'.
/parse address   :parse address, returning the value of crackaddr, and
                  the parsed address.
/try mailer addr :rewrite address into the form it will have when
                  presented to the indicated mailer.
/tryflags flags  :set flags used by parsing.  The flags can be `H' for
                  Header or `E' for Envelope, and `S' for Sender or `R'
                  for Recipient.  These can be combined, `HR' sets
                  flags for header recipients.
/canon hostname  :try to canonify hostname.
/map mapname key :look up `key' in the indicated `mapname'.
/quit            :quit address test mode.
rules addr       :run the indicated address through the named rules.
                  Rules can be a comma separated list of rules.
End of HELP info

 
 
 

1. check_mail cannot resolve hostnames, but they resolve

Hi there

I seem to have a problem with my mailserver. It started earlier today but
I've only just noticed it.

Any mails sent to domains on the machine are being rejected at the ruleset
check_mail

e.g.


delay=00:57:08, xdelay=00:00:40, mailer=virthostmail, pri=221817,
relay=mail.acksys.co.uk, dsn=4.0.0, stat=Deferred: 451 4.1.8 Domain of

They all resolve on the cmd line and host -t mx gives the expected results

Has anyone got any ideas what is going on here? I've done nothing to the
server. How do I get it to accept mails again?

tia

--
--
Darren Beale - Acksys Ltd
Office: 020 8530 1454
Fax: 07092 394822
Mobile: 07711 716197
http://www.acksys.co.uk

2. locations

3. Sendmail not resolving hostname

4. Admin help

5. Resolving Sender's hostname

6. ipsec over mpls network

7. sendmail not resolving hostname

8. Frac T1 to ISDN BRI

9. sendmail unable to resolve hostname?

10. Sendmail: Long delays while resolving hostnames

11. prevent MH adding hostname or domain name

12. New Twist on MX list for hostname points back to hostname

13. sendmail reports hostname as hostname.