ipppd / named / sendmail

[Verwijderd]

Ik heb hier een linux-machine onder mijn beheer gekregen die met dial-on-demand via ISDN verbinding maakt met internet. Op zich werkt het allemaal prima, behalve dat er TE VAAK verbinding is, namelijk elke 5 minuten :] Leuke telefoonrekening dus.
Tis een redhat 6.1 machine. Op de machine draaien sendmail en named (oa). Elke 5 minuten processed sendmail de lokale mail (sendmail -qRmijndomein.nl). Named draait een lokale caching server.
Het probleem is enkelvoudig: stop elke 5 minuten met inbellen damnit!
Ik heb al het eea geprobeerd, en heb al flink gezocht (maar niet gevonden), en ik hoop dat jullie een oplossing weten. Wat namelijk gebeurd, is dat elke 5 minuten sendmail de lokale mail gaat processen en daarvoor een reverse dns-lookup doet naar het ip-adres dat de isdn-adapter heeft (welke wel al inmiddels heeft opgehangen ivm idle zijn). Het ip-adres is dynamisch.

Heeft iemand hier een oplossing voor? Het kan in 3 richtingen gezocht worden, ipppd, named en sendmail, alleen ik heb alle 3 bekeken en weet't ook niet meer (met deze 3 onderdelen heb ik niet al te veel ervaring).
Ik heb in sendmail.mc (geloof ik) al iets van FEATURE "nodns" en "nocanonical" gezet, maar dat haalde niks uit (moet ik dat op een of andere manier activeren? Las zoiets)..
Totaal andere oplossingen mogen ook.
ik heb ook gekeken naar de oplossing om ipchains en ip-up/ip-down te gebruiken, maar die voert die regels niet uit verdomme.. Beetje maf..
Maar goed, alle suggesties zijn welkom!

[Myrdhin]

Kun je die sendmail.mc file eens posten? En laat ook even weten hoe je /etc/named.conf eruit ziet. Ik heb heel wat mail servertjes buitengezet met een standaard config. En een aantal waren met een ISDN adapter maar dit ben ik nog niet tegengekomen. Ik denk dat je een reverse file voor named moet maken met je interne adressen. Hoe heb je achterhaald dat sendmail een reverse lookup doet naar je ISDN adapter's IP adres?

Oh ja, een

code:

define(`confDELIVERY_MODE',`deferred')

in je sendmail.mc zorgt er in iedergeval voor dat sendmail niet begint met een reverse lookup.

[Verwijderd]

Op donderdag 05 juli 2001 18:33 schreef Myrdhin het volgende:
Kun je die sendmail.mc file eens posten? En

hmm niet zo makkelijk, dan moet ik eerst naar die server toerijden enzo. Maar het kan

>laat ook even weten hoe je /etc/named.conf
Ok die zoek ik ook op dan

>aantal waren met een ISDN adapter maar dit >ben ik nog niet tegengekomen. Ik denk dat
Mjah ik heb zo'n ding met isdn nog nooit uitgeleverd en krijg dan ineens zo'n brak ding onder m'n beheer, en of ik dat maar even met spoed op wil lossen....

>je een reverse file voor named moet maken >met je interne adressen. Hoe heb je
Mjah hij doet dus het ip van je isdn-adapter

>achterhaald dat sendmail een reverse lookup >doet naar je ISDN adapter's IP adres?
named met een debug of logging mode ofzo, dan logt-ie alles in named.run.
Daar zie ik dat. Erg vreemd aangezien sendmail -qRhetdomein.nl daar toch niks mee te maken zou moeten hebben.

code:

define(`confDELIVERY_MODE',`deferred')

>in je sendmail.mc zorgt er in iedergeval >voor dat sendmail niet begint met een >reverse lookup.
Ok, stel ik zet die erin, moet ik dan nog iets doen behalve sendmail restarten om dit te laten werken? Ik las iets over die sendmail.cf en dat-ie opnieuw gemaakt moest worden...

[Verwijderd]

Weet iemand anders dat toevallig?

[Verwijderd]

Kijk eens in je /var/log/messages welk programma eigenlijk om die verbinding vraagt. Of /var/log/sendmail..... of /var/log/named..... - als je dat weet zijn wel al heel wat verder.

sendmail.cf hoef je niet opnieuw te maken geloof ik, gewoon sendmail herstaren is genoeg.

[Verwijderd]

Op vrijdag 06 juli 2001 11:24 schreef beelzebubu het volgende:
Kijk eens in je /var/log/messages welk programma eigenlijk om die verbinding vraagt. Of /var/log/sendmail..... of /var/log/named..... - als je dat weet zijn wel al heel wat verder.

uhm, tis dus alsvolgt:
10:00 sendmail -qRmijndomein.nl
10:00 named ontvangt een request vanaf het oude ip-adres van ippp0 (het packetje

edit:
wat de verbinding triggert

is ook naar de externe DNS port 53 udp)
10:00 verbinding wordt gestart
10:02 verbinding wordt verbroken
10:05 sendmail -qRmijndomein.nl
etc

Ik twijfel alleen ff welk adres-ie opvraagt, maar volgens mij ook het oude ippp0-adres (overigens ippp0 blijft "actief" cq in het overzicht van ifconfig staan als geldige adapter, maar volgens mij hoort dit (in tegenstelling tot ppp0))

sendmail.cf hoef je niet opnieuw te maken geloof ik, gewoon sendmail herstaren is genoeg.

Ok dat kan ik dan iig proberen!

Misschien dat ik'r straks nog ff langsrijd..

[Tha_Butcha]

volgens mij wel hoor, want die .mc file moet eerst nog door die m4 macro-dinges gejast worden:

code:

[user@host]m4 sendmail.mc > /etc/sendmail.cf

[Verwijderd]

ahh gezocht
m4 ${CFDIR}/m4/cf.m4 config.mc > config.cf
Ok als ik nog tijd heb rijd ik'r langs kan ik iig dit even proberen met die deffered

[Myrdhin]

Sorry voor de wat late reactie.

Kun je ook zien wat voor een request named krijgt? Wat moet ie gaan resolven? Het enige wat ik me voor kan stellen is dat ie een request doet voor mijndomein.nl.

Maar ik ben ook benieuwd of die deferred mode werkt.

[Verwijderd]

Ik hoop er maandag heen te kunnen, maar heb nog 2 problemen die ook prioriteit hebben :] damn
Beetje afhankelijk van MS en de andere van een ander bedrijf
hehe oh well

[Verwijderd]

Nou, ik ga er nu naartoe, wish me luck!

[Verwijderd]

Nou, ik ben'r geweest. Ik weet nog niet zeker of het heeft gewerkt. Ik vermoed dat't wel heeft gewerkt, maar op een gegeven moment ging-ie toch nog uitbellen terwijl niemand op internet ging ofzo, maarjah dat kan ook iets anders zijn.. Ik ga'r binnenkort nog maar ff langs :]
logcheck werkte niet, begon te zeuren over mailaccount, moet ik ook nog ff naar kijken :]
thx anyway, ik laat't hierin nog wel ff weten

[Verwijderd]

Het lijkt in orde, er wordt niet meer elke 5 minuten ingebeld (maar toch nog redelijk vaak). Helaas legt isdnctrl geen pakketjes meer vast om een of andere reden. Anyway, ik houd't ff in de gaten en merk't verder wel.
Thanks for the help. Ik heb nu dat "deferred" verhaal geprobeerd.

[jeroen|IA]

De oplossing is supersimpel, en ik snap dan ook niet dat ie niet eerder genoemd is. Het enige wat je hoeft te doen is het getal achter de -q flag van sendmail wat te verhogen (je ziet de huidige waarde als je b.v. ps -ef | grep sendmail doet). Nu staat er ws -q5m, daar moet b.v. komen te staan -q15m (geldige parameters zijn m voor minuut, h voor uur en d voor dag). Je kunt dit het handigste veranderen in het startscript: /etc/rc.d/init.d/sendmail is dat dacht ik bij Red Hat, anders /etc/init.d/sendmail

Daarnaast zou je ook de timeout van de verbinding wat "strakker" kunnen zetten zodat ie niet nog een minuut opblijft nadat alle mail al is geprocessed. Kijk daarvoor bij de parameters van ipppd.

[Myrdhin]

Op woensdag 11 juli 2001 09:40 schreef jeroen het volgende:
De oplossing is supersimpel, en ik snap dan ook niet dat ie niet eerder genoemd is. Het enige wat je hoeft te doen is het getal achter de -q flag van sendmail wat te verhogen (je ziet de huidige waarde als je b.v. ps -ef | grep sendmail doet). Nu staat er ws -q5m, daar moet b.v. komen te staan -q15m (geldige parameters zijn m voor minuut, h voor uur en d voor dag). Je kunt dit het handigste veranderen in het startscript: /etc/rc.d/init.d/sendmail is dat dacht ik bij Red Hat, anders /etc/init.d/sendmail

De oplossing is helaas niet zo supersimpel als je gedacht had. Via een crontab wordt sendmail aangeroepen om alleen de lokale mail te versturen. Dit gebeurt om de 5 min. Dit moet ook wel om de 5 min gebeuren omdat je anders nogal lang moet wachten als bv. Jan een mailtje naar Truus stuurt in hetzelfde gebouw..... Waar jij op doelt is de queuerun en die staat standaard op 1 uur (in RedHat althans). Die queuerun wordt gedaan voor uitgaande mail. Het probleem zat 'm in de lokale mail. Bij het versturen van de lokale mail ging z'n ISDN lijn open.

Daarnaast zou je ook de timeout van de verbinding wat "strakker" kunnen zetten zodat ie niet nog een minuut opblijft nadat alle mail al is geprocessed. Kijk daarvoor bij de parameters van ipppd.

Dit helpt niet echt. Je moet de verbinding ook niet te strak zetten want dan krijg je het effect dat als je de verbinding bv. na 1 minuut al verbreekt en 1 minuut daarna weer nodig hebt dat je meer aan het betalen bent aangezien de kosten om de verbinding te maken ook gebruikt kunnen worden voor het openhouden van nog +/- 2 minuten.

[jeroen|IA]

mmmokay... had het oorspronkelijke probleem ook niet echt goed doorgelezen, zo blijkt.

[Verwijderd]

Door een goede sendmail configuratie zou het zo moeten zijn zodra sendmail afhandelt voor een intern email/domein dan moet deze hen niet opengooien mits er ook een dns server intern draait die een mx record heeft die verwijsst naar een interne mail server i.p.v extern dit als er meerdere unix mail/servers zijn. let ook op wat de verbinding open gooit.

Voorbeeld

Voor een school hadden we een FreeBSD mail/inet server gebouwd we hadden in de firewall rules gedifineert wat/wie op welke poort de inet verbinding kon opengooien helemaal vergeten dat de server ook er een is. vang de smurfen af .255 .0 voor het netwerk en de machine naar buiten toe dat niet bij een broadcast de verbinding wordt opengegooid wat bij ons het geval dus was.

[Verwijderd]

Het werkt niet damnit, na die wijziging van "deferred" werkt mailen niet meer.. Ik ben nu gegevens aan't verzamelen zodat we misschien wat verder kunnen komen :]
Ga hier hopelijk vanmiddag mee aan de slag.. (ff filteren, gewoon log van telnet gemaakt)

(wat een tegenvaller zeg :])

[Myrdhin]

Wat werkt er qua mailen niet meer? Het kan zijn dat je je netwerk aan /etc/mail/access moet toevoegen. En daarna "makemap access.db < access" moet draaien om ervoor te zorgen dat sendmail de post accepteert. In /var/log/maillog komt zoiets te staan als dat de mail niet geaccepteerd is omdat het om RELAY mail gaat.

[Verwijderd]

Ik had die hele log gefiltered en mooi met commentaar hierin gezet, maar dat *$^&*$^windows liep vast
Morgen weer opnieuw doen, vandaag geen tijd meer gehad..
sigh
Nah het ging niet om relaying, hij begon te klagen over een mx-record die naar zichzelf zou verwijzen, waarvan-ie geen file kon vinden...
Maar goed, morgen meer

[Verwijderd]

Ok daar gaan we dan..

/etc/named.conf

code:

options {
      directory "/var/named";
      forwarders{
            194.109.6.66;
            194.109.9.99;
      };
};
zone "." {
      type hint;
      file "named.ca";
};
zone "hetdomein.nl" {
      type master;
      file "hetdomein.nl";
};
zone "0.0.127.in-addr.arpa" {
      type master;
      file "named.local";
};
zone "0.1.168.192.IN-ADDR.ARPA" {
      type master;
      file "192.168.1.0";
};
zone "1.1.168.192.IN-ADDR.ARPA" {
      type master;
      file "192.168.1.1";
};

/etc/sendmail.mc (ik denk dat ze deze gebruiken, ik heb alleen wel continu de oude .cf gebruikt en niet opnieuw deze aangemaakt aan de hand van de mc)

code:

divert(-1)
dnl This is the macro config file used to generate the /etc/sendmail.cf
dnl file. If you modify thei file you will have to regenerate the
dnl /etc/sendmail.cf by running this macro config through the m4
dnl preprocessor:
dnl
dnl   m4 /etc/sendmail.mc > /etc/sendmail.cf
dnl
dnl You will need to have the sendmail-cf package installed for this to
dnl work.
include(`/usr/lib/sendmail-cf/m4/cf.m4')
define(`confDEF_USER_ID',``8:12'')
OSTYPE(`linux')
undefine(`UUCP_RELAY')
undefine(`BITNET_RELAY')
define(`confAUTO_REBUILD')
define(`confTO_CONNECT', `1m')
define(`confTRY_NULL_MX_LIST',true)
define(`confDONT_PROBE_INTERFACES',true)
define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')
FEATURE(`smrsh',`/usr/sbin/smrsh')
FEATURE(mailertable)
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable')
FEATURE(redirect)
FEATURE(always_add_domain)
FEATURE(use_cw_file)
FEATURE(local_procmail)
MAILER(procmail)
MAILER(smtp)
FEATURE(`access_db')
FEATURE(`blacklist_recipients')
dnl We strongly recommend to comment this one out if you want to protect
dnl yourself from spam. However, the laptop and users on computers that do
dnl not hav 24x7 DNS do need this.
FEATURE(`accept_unresolvable_domains')
dnl FEATURE(`relay_based_on_MX')

De foutmelding nadat "confDELIVERY_MODE, deferred" is gebruikt: (hij geeft overigens de melding van permanent fatal errors al bij het source-address, dat is het eerste gedeelte)

code:

   ----- Transcript of session follows -----
554 <[e-mail]>... Local configuration error

code:

   ----- The following addresses had permanent fatal errors -----
<[e-mail]>
 
   ----- Transcript of session follows -----
451 MX list for hetdomein.nl. points back to linux.hetdomein.nl: No such file or directory
554 <[e-mail]>... Local configuration error

Dat was zo'n beetje de info die ik heb. Helaas heb ik geen named.run-info van wanneer het foutgaat.. Mocht dat nodig zijn dan ga ik die gegevens nog wel halen...
Ik hoop dat jullie hier wat mee kunnen.

[Verwijderd]

bzzzzzt, time's up!
hehe neuh, ik wacht nog met smart

[Myrdhin]

Heb je het domein waarvoor je mail wilt ontvangen ook gezet in /etc/mail/local-host-names (versie sendmail hoger dan 8.9.3. Het je sendmail 8.9.3 of lager (RH6.1) dan is het /etc/sendmail.cw). Daarin moeten de domeinnamen staan waarvoor je mail wilt ontvangen (zoiets als "hetdomein.nl"). Ik zou voor alle zekerheid de .mc file met de optie van "deferred" opnieuw een .cf laten genereren. Check ook het "hetdomein.nl" bestande van named. En let vooral goed op je MX records. Die "deferred" optie mag niet zomaar je mail blokkeren.

[alt-92]

Op vrijdag 13 juli 2001 12:15 schreef Deleon het volgende:
bzzzzzt, time's up!
hehe neuh, ik wacht nog met smart

Ehm..
Ik zie hier
/etc/named.conf

code:

options {
      directory "/var/named";
      forwarders{
            194.109.6.66;
            194.109.9.99;
      };
};
zone "." {
      type hint;
      file "named.ca";
};
zone "hetdomein.nl" {
      type master;
      file "hetdomein.nl";
};
zone "0.0.127.in-addr.arpa" {
      type master;
      file "named.local";
};
zone "0.1.168.192.IN-ADDR.ARPA" {
      type master;
      file "192.168.1.0";
};
zone "1.1.168.192.IN-ADDR.ARPA" {
      type master;
      file "192.168.1.1";
};

Geen linux.jouwdomein.nl tussen staan.
Hoe weet sendmail dat dat jouw MX is als named het niet kan vertellen?

code:

   ----- The following addresses had permanent fatal errors -----
<[e-mail]>
 
   ----- Transcript of session follows -----
451 MX list for hetdomein.nl. points back to linux.hetdomein.nl: No such file or directory
554 <[e-mail]>... Local configuration error

[Verwijderd]

Op zaterdag 14 juli 2001 10:34 schreef BackSlash32 het volgende:


(named.conf)
Geen linux.jouwdomein.nl tussen staan.
Hoe weet sendmail dat dat jouw MX is als named het niet kan vertellen?

hetdomein.nl staat er wel bij, en daarin staan de daadwerkelijke MX-records.
Toch?

[Verwijderd]

Op zaterdag 14 juli 2001 07:47 schreef Myrdhin het volgende:
Heb je het domein waarvoor je mail wilt ontvangen ook gezet in /etc/mail/local-host-names (versie sendmail hoger dan 8.9.3. Het je sendmail 8.9.3 of lager (RH6.1) dan is het /etc/sendmail.cw). Daarin moeten de domeinnamen staan waarvoor je mail wilt ontvangen (zoiets als "hetdomein.nl"). Ik zou voor alle zekerheid de .mc file met de optie van "deferred" opnieuw een .cf laten genereren. Check ook het "hetdomein.nl" bestande van named. En let vooral goed op je MX records. Die "deferred" optie mag niet zomaar je mail blokkeren.

Ok gaat ik proberen. Ik heb op't moment de tijd van mail verwerken maar even in overleg op een uur gezet, maar dit moet toch zsm aangepast worden :] Alleen ben ik nu een weekje vrij (behalve voor spoedgevallen ), en is besproken dat door het op een uur te zetten het probleem wel tot na mijn vakantie kan wachten. Het zijn gelukkig hele redelijke en aardige mensen, daar heb ik wel geluk mee... Ach ze zien dat ik me best doe..

Ik ga't zeker proberen Myrdhin! ff kijken waar ik die naam in moet vullen. Heb wel iets gezien van LocalNames ofzo, maar waar ik die nou in kan vullen, ik weet't nog niet. Zie ik wel...

Nog andere suggesties?
Btw, ik zat te denken aan een andere hoek (ipppd/ipchains), door gewoon in ip-down en ip-up een ipchains -A INPUT 1 (ofzo) met een REJECT (ip-down) en Delete bij (ip-up) vanaf het (oude) ip-adres van de ippp0... Maarjah, dat ipppd voert die k*tscripts niet uit, beetje wazig..

[alt-92]

Op zaterdag 14 juli 2001 22:07 schreef Deleon het volgende:

[..]
Ik ga't zeker proberen Myrdhin! ff kijken waar ik die naam in moet vullen. Heb wel iets gezien van LocalNames ofzo, maar waar ik die nou in kan vullen, ik weet't nog niet. Zie ik wel...

Voor exim :
http://www.exim.org/pipermail/exim-users/Week-of-Mon-20001023/021963.html

code:

> 451 MX list for mercuryfilmworks.com. points back to
> mail.mercuryfilmworks.com: No such file or directory
> 554 <[e-mail]>... Local configuration error

root@rocklines/usr/exim> grep local_domains configure
local_domains = lsearch; /usr/exim314/local.domains

Put all hosts you receive mail for into this file - mercuryfilmworks.com and
mail.mercuryfilmworks.com ought to be here.

In ieder geval heb je nu een richting om te zoeken.

[Verwijderd]

Ok dan!
Als ik van de week nog wordt opgeroepen (zal ongetwijfeld ) ga ik'r nog wel ff langs..
Thanks!
tis btw sendmail :]

[Verwijderd]

Nou, hier dan het resultaat
Ik heb't nu in de gaten gehouden, en het werkt nu gooooeed )
Nog steeds veel inbellen, maarja dat doen ze zelf eh )
Met die deferred-optie en de aliassen in sendmail.cw werkt het perfect! Zelfs logcheck werkt nu Dus ik kan't nu netjes op afstand in de gaten houden!
HEEEEEEEEEEEEL erg bedankt jongens/meisjes

DLN