Nieuws:

Welkom, Gast. Alsjeblieft inloggen of registreren.
Heb je de activerings-mail niet ontvangen?

Auteur Topic: Sendmail "access from" check fail  (gelezen 126 keer)

Offline hansvl

  • Lid
Sendmail "access from" check fail
« Gepost op: 2017/08/11, 15:58:41 »
Wij gebruiken eenUbuntu 16.04.3, kernel 4.4.0-87-generic system als mail-relay-server.
De relay functie is behoorlijk traag.

Als ik get commando "telnet mail-relay-server 25" uitvoer duurt het wel 8 seconden voordat sendmail een wat laat zien.
Ik heb de indruk dat sendmail eerst "iets" gaat controleren (misschien reverse DNS) en proberen te loggen van het
IP-adres van het client systeem. Dat is dus het systeem waarvan af ik het telnet commando uit voer.

Na die +/- 8 seconden laat de sendmail server de volgende tekst zien:
$  telnet mail-relay-server 25
Trying 192.168.0.247...
Connected to mail-relay-server.network.local.
Escape character is '^]'.
220 alpha.mailstreet.nl ESMTP Sendmail 8.15.2/8.15.2/Debian-3; Fri, 11 Aug 2017 15:32:04 +0200; (No UCE/UBE) logging access from: [192.168.7.105](FAIL)-[192.168.7.105]

Is die vertraging van +/- 8 seconden weg te nemen?
Is dit een configuratie fout?
Komt die vertraging inderdaad door het controleren van het client ip-adres?
Moet ik het client ip-adres ergens opnemen in een configuratie file?
Is het ook mogelijk om die (eventuele) controle van het client ip-adres uit te schakelen?

De file /etc/mail/access bevat de onderstaande configuratie regels:
Connect:localhost               RELAY
GreetPause:localhost    0
ClientRate:localhost    0
ClientConn:localhost    0
Connect:127                             RELAY
GreetPause:127                  0
ClientRate:127                  0
ClientConn:127                  0
Connect:IPv6:::1                RELAY
GreetPause:IPv6:::1             0
ClientRate:IPv6:::1             0
ClientConn:IPv6:::1             0
GreetPause:                             5000
ClientRate:                             10
ClientConn:                             10
Spam:postmaster@        FRIEND
Spam:abuse@             FRIEND
Spam:spam@              FRIEND
reject@                 REJECT
Connect:169.254 REJECT
Connect:192.0.2 REJECT
Connect:224             REJECT
Connect:255             REJECT
192.168                 RELAY

Ik heb in /etc/mail "make" gedraaid om access.db te genereren.
Daarna het ik "service sendmail restart" gedraaid.





Offline nahjo

  • Lid
  • Steunpunt: Nee
Re: Sendmail "access from" check fail
« Reactie #1 Gepost op: 2017/08/12, 09:45:05 »
Wellicht GreetPause:192.168       0   toevoegen?
Scheelt 5000 milliseconden.
« Laatst bewerkt op: 2017/08/12, 11:38:54 door nahjo »

Offline hansvl

  • Lid
Re: Sendmail "access from" check fail
« Reactie #2 Gepost op: 2017/08/14, 09:23:02 »
De regel "GreetPause:192.168       0" heb ik toegevoegd aan de file /etc/mail/access.
Daarna heb ik in de directory /etc/mail "make" gedraaid om de nieuwe regel te verwerken in access.db
Om sendmail de nieuwe regel te laten gebruiken heb ik "service sendmail restart" gedraaid.
Het probleem van de timeout van +/- 8 seconden is echter niet opgelost.

Om te achterhalen waar de timeout vandaan komt het ik het onderstaande gedaan:
# ps -ef | grep sendmail
root     17679     1  0 07:47 ?        00:00:00 sendmail: MTA: accepting connections
# strace -f -o /tmp/strace.out -p 17679

In een andere shell op de mail-relay-server heb ik tail gestart.
# tail -f /tmp/strace.out

In een shell op een mail client systeem heb ik een verbinding naar naar de sendmail op de mail-relay-server geopend.
$ telnet mail-relay-server 25
   Trying 192.168.0.247...
Connected to alpha.mail-street.local.
Escape character is '^]'.
220 alpha.mailstreet.nl ESMTP Sendmail 8.15.2/8.15.2/Debian-3; Mon, 14 Aug 2017 08:15:57 +0200; (No UCE/UBE) logging access from: [192.168.7.105](FAIL)-[192.168.7.105]

In de output van strace (getoond door tail -f) zie ik dat sendmail enkele seconden blijft "hangen" in de system-call:
18081 connect(5, {sa_family=AF_INET, sin_port=htons(113), sin_addr=inet_addr("192.168.7.105")}, 16 <unfinished ...>

Sendmail doet dus een connect call terug naar het mail-client systeem.
In de file /etc/services staat voor poort 113 de onderstaande regel:
auth            113/tcp               authentication tap ident.

Op het mail-client systeem wordt ether niet geluisterd naar TCP poort 113.
Daardoor loop de connect call op de mail-relay-server na enkele seconden uit in een timeout.

Is sendmail zo te configureren dat er geen system-call connect terug naar de mail-client wordt gedaan?

Offline nahjo

  • Lid
  • Steunpunt: Nee
Re: Sendmail "access from" check fail
« Reactie #3 Gepost op: 2017/08/14, 09:40:56 »

Is sendmail zo te configureren dat er geen system-call connect terug naar de mail-client wordt gedaan?

Even voor je gegoogled op "port 113" en op "sendmail Disable IDENT "
Citaat
To disable ident support, set the confTO_IDENT timeout in the sendmail.mc file to zero, then rebuild sendmail.cf.

define(`confTO_IDENT', `0')
bron: http://novosial.org/sendmail/tips/index.html#s4

Offline hansvl

  • Lid
Re: Sendmail "access from" check fail
« Reactie #4 Gepost op: 2017/08/14, 16:16:31 »
Nahjo bedankt voor je hulp.

Nu wil sendmail echter niet opstarten met de onderstaande regel in file file /var/log/mail.err
Aug 14 16:11:27 angola sm-mta[7517]: NOQUEUE: SYSERR(root): /etc/mail/sendmail.cf: line 1919: unknown configuration line "define(`confTO_IDENT', `0')"

Offline nahjo

  • Lid
  • Steunpunt: Nee
Re: Sendmail "access from" check fail
« Reactie #5 Gepost op: 2017/08/14, 16:38:41 »
dnl wel toegevoegd aan de regel? Zie andere regels in sendmail.mc

define(`confTO_IDENT', `0')dnl
http://www.linuxquestions.org/questions/slackware-14/sendmail-smtp-auth-howto-224543/

Offline hansvl

  • Lid
Re: Sendmail "access from" check fail
« Reactie #6 Gepost op: 2017/08/14, 17:23:49 »
Een    define(`confTO', `0')dnl     in sendmail.mc
leverd na make een      # define(`confTO', `0')dnl     op in sendmail.cf

Dat werkt goed.
Ik zie geen connect call meer naar de mail client.

Ik zie nog wel de melding:

(No UCE/UBE) logging access from: [192.168.7.105](FAIL)-[192.168.7.105]

Maar dat levert geen probleem op.

Bedankt Nahjo