Exim/Dovecot - Wel via roundcube en mailx, niet mailclient

[Paultje3181]

Ik heb een mailserver met exim en dovecot. Daarnaast Roundcube voor webmail. Als ik op de server via mailx mail komt de mail netjes aan. Ditzelfde geldt voor Roundcube.

Maar als ik via thunderbird, k9 of outlook wil sturen, gebeurt er niets.
/var/log/exim4/rejectlog

code:

2014-12-05 08:49:30 SMTP protocol synchronization error (input sent without waiting for greeting): rejected connection from H=[host IP] input="GET / HTTP/1.0\r\nHost: [mijnip]\r\n\r\n"

/var/log/exim4/mainlog

code:

2014-12-04 22:09:29 Start queue run: pid=525
2014-12-04 22:09:29 1Xw0AQ-000527-1y Message is frozen
2014-12-04 22:09:29 End queue run: pid=525

Dit zijn de enige stukjes die ik zo zie.
Ik wil best Exim-configs erbij zetten, maar heb geen idee welke gewenst is.

[ Voor 1% gewijzigd door Hero of Time op 05-12-2014 12:52 ]

[Hero of Time]

Nou, die reject zegt nogal wat, of niet? Blijkbaar staat Exim niet toe dat een externe host verbinding met 'm maakt.

Ps, ik heb voor de veiligheid maar je IP eruit gesloopt. Die had je in de mainlog al weggelaten, maar niet in de rejectlog.

[Paultje3181]

Ik vraag me alleen af of die rejectlog wel hierbij hoort gezien de tijdstippen.
Wat ik zo raar vind is dat mail en mailx wel werken en thunderbird niet.
DNS is ook niet het probleem, volgens mxtoolbox zit dat wel goed (behalve connection time en TLS)

[Hero of Time]

Ik had niet eens naar de tijd gekeken.

Krijg je foutmeldingen met je mailclient? Staan de poorten open en luisteren de juiste daemons ook op het juiste IP? Laat eens een tcpdump (of ngrep) draaien gefilterd op de poorten die je gebruikt voor email. Wat zie je dan allemaal langs komen?

[Killah_Priest]

Wat krijg je te zien als je via telnet verbindt en een mail wilt sturen?
(SMTP gerelateerde problemen test ik ALTIJD dmv telnet naar de mailserver, eerst telnetten naar poort 25, HELO doen etc).
Je krijg op die manier erg snel te zien in welke fase het al verkeerd gaat.

[Paultje3181]

Ik krijg van k9 de foutmelding no address associated with hostname.

/etc/host.conf
multi on

/etc/host
127.0.0.1 localhost localhost
IP VPS.mijnvps.nl

telnet ip:25
Name or service not known

[ Voor 12% gewijzigd door Paultje3181 op 06-12-2014 20:29 ]

[Paultje3181]

Telnet domain 25 = 220
Mail from: ik@domain = 250
rcpt to: ik@domain = 250

Dit lijkt dus goed te gaan

[Hero of Time]

Heb je een bepaalde guide gevolgd voor het configureren van Exim?

[Paultje3181]

http://t-machine.org/inde...-exim4-dovecot-roundcube/

heb ik gevolgd. Helaas heeft hij het niet over het versturen van mail.

[Hero of Time]

Heb je ook DNS entries voor je mailserver? Dus ipv de standaard A, ook MX records zodat je mailclient die ziet? Misschien dat daar het probleem zit.

[Paultje3181]

A en MX zijn er ook.
mail2.domein A [ip]
domein MX mail2.domein 10

Het lijkt er op dat TLS niet helemaal goed gaat volgens swaks. Hier ga ik dus even induiken... Zou het ook een firewall probleem kunnen zijn? Ik heb 25,465,143 en 993 open staan

[Paultje3181]

Ik heb even naar de firewall gekeken en die lijkt goed te staan:
iptables -L -n geeft 465 en 587 accepted
csf.conf staat 465 en 587 ook opgenomen

alleen telnet server 465 geeft connection refused en in nmap staat ie er ook niet tussen.
exim -bP geeft wel aan dat er een certificaat gelezen wordt en dergelijke, dus dit staat aan.

Als ik naar 25 telnet en een HELO en EHLO geef krijg ik 250 OK, als ik STARTTLS geef krijg ik 454 TLS currently unavailable

Ik heb nu een self-signed certificate geprobeerd en daar krijg ik wel een ok terug op mijn certificaat.

Als ik openssl s_client -starttls smtp -connect server:587 -crlf doe, krijg ik ook een connection refused.

[ Voor 19% gewijzigd door Paultje3181 op 10-12-2014 15:07 ]

[Hero of Time]

Dan moet je dus eens gaan kijken waarom je connection refused krijgt. Draait er iets op die poort (laat netstat -tln 'm zien)? Wat zie je in je logs? Welke regels heb je precies voor iptables? Want als je allow op de verkeerde plek staat, dan doet 't nogal weinig.

Owja, ik geloof nu wel dat 't een Linux ding is, dus trek 'm even naar mij toe. CSA -> NOS.

[ Voor 15% gewijzigd door Hero of Time op 10-12-2014 20:38 ]

[Paultje3181]

Ik heb het probleem gevonden... in /etc/default/exim4 wordt geconfigureerd op welke poorten geluisterd wordt. Toevoegen van 587 en 465 zorgt dat het werkt...

Welke idioot verzint dit om dit hier te zetten???

[Hero of Time]

Dat is de package maintainer. Of de software schrijver, want voor Postfix en vele andere software heb ik 't niet gezien. Daar kan je zelfs wat er in default staat overrulen met de specifieke config. Maar goed, je hebt 't gevonden en het werkt.

[syl765]

De default locatie moet je eigelijk niet bewerken.
Met je echte config overrule je de default settings. Bij een upgrade kan ik het mij voorstellen dat je default file weer word overschreven. Zorg er nog wel even voor dat je een relay test uitvoert op je server. Niets zo vervelend als je server een open relay blijkt te zijn. Niet alleen voor jou maar ook voor de mensen die weer extra spam ontvangen van jou server.

[gekkie]

Paultje3181 schreef op woensdag 10 december 2014 @ 23:23:
Ik heb het probleem gevonden... in /etc/default/exim4 wordt geconfigureerd op welke poorten geluisterd wordt. Toevoegen van 587 en 465 zorgt dat het werkt...

Welke idioot verzint dit om dit hier te zetten???

Een vooral door Debian veel gebruikte plek om veel gebruikte opties in te kunnen stellen zonder je door de volledige configs te hoeven worstelen. Tevens vaak gebruikt voor een "enable" optie voor pakketten die na installatie nog configuratie nodig hebben alvorens gestart te kunnen worden.

Wat voor exim dan opzich wel weer dubbel is, want ze hanteren ook al update-exim4.conf.conf met basis instellingen .. die tijdens het starten dan in de echte config geparsed en merged wordt.

Er zit dus wel degelijk enige logica in, odanks dat het duidelijk ook manco's kan hebben :-)

[ Voor 11% gewijzigd door gekkie op 11-12-2014 10:40 ]

[Kees]

syl765 schreef op donderdag 11 december 2014 @ 08:45:
De default locatie moet je eigelijk niet bewerken.
Met je echte config overrule je de default settings. Bij een upgrade kan ik het mij voorstellen dat je default file weer word overschreven. Zorg er nog wel even voor dat je een relay test uitvoert op je server. Niets zo vervelend als je server een open relay blijkt te zijn. Niet alleen voor jou maar ook voor de mensen die weer extra spam ontvangen van jou server.

Nee, die default file word niet overschreven (tenzij je dat zelf aangeeft uiteraard, hij vraagt er wel om) en het is juist de plek waar in debian/ubuntu veel configuratieopties staan (als zijnde de 'default' instellingen die je daar kan overschrijven).

[syl765]

Dat druist voor mij in iedergeval tegen alle logica in en ook op de systemen waar ik op gewerkt heb. Mijn excuus voor de foutieve info.

[Hero of Time]

Kijk maar eens naar Grub2. Je moet juist bepaalde parameters in /etc/default/grub zetten, want de script die draaien worden bij elke update overschreven (melding als ze afwijken van package default). En zo zijn er dus meerdere pakketten die met /etc/default werken om juist de config in /etc/[pakket] te overrulen.

[d1ng]

syl765 schreef op donderdag 11 december 2014 @ 10:59:
Dat druist voor mij in iedergeval tegen alle logica in en ook op de systemen waar ik op gewerkt heb. Mijn excuus voor de foutieve info.

Op FreeBSD klopt die logica. De files in /etc/defaults/ op FreeBSD zijn ook echt defaults die je kunt overschrijven door dezelfde optie in de 'echte' config te zetten.

Debian heeft zeg maar een andere definitie van defaults . De files op Debian in /etc/default/ zijn veelal bedoeld voor init.d scripts die deze files weer sourcen.

Zie ook /etc/init.d/skeleton die als voorbeeld kan dienen voor nieuwe init.d scripts.

code:

grep default /etc/init.d/skeleton

[Paultje3181]

Bij verder testen blijkt het toch niet allemaal even lekker te gaan. Veel servers gaan goed, maar bij sommige adressen krijg ik:

code:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  target@mail
    SMTP error from remote mail server after RCPT TO:<target@mail>:
    host mail.mail [159.253.0.125]:
    550-Verification failed for <sender@other-mail>
    550 Sender verify failed

terug.
Kan het zijn dat dit te maken heeft het feit dat er voor domein1 een ssl-certificaat staat, en dat er voor meerdere domeinen mails verstuurd worden?

[begintmeta]

Het kan best zijn dat de remote server kijkt of je reverse-dns klopt, maar allerlei andere checks kunnen ook tot zo'n error leiden.

[Paultje3181]

Daar kwam ik dus ook achter, dat die foutmelding redelijk generiek is... Een andere, makkelijkere oplossing zou zijn om voor ieder domein de mx in te stellen dat dit via het domein met het certificaat gaat of niet?
domain1 MX secure.domain2 10
Of stuit dit op hogere spam-ratings?

[gekkie]

Ik zou idd gokken op reverse DNS als probleem ipv certificaat (zelfs self signed certificaten worden over het algemeen geaccepteerd en leiden niet tot het weigeren van mail, geen reverse DNS met enige regelmaat wel).

[Sneezydevil]

Kijk ook even naar je SPF record of DKIM, want een probleem met je reverse DNS had MXToolbox normaal aangegeven:

SMTP Reverse DNS Mismatch Warning - Reverse DNS does not match SMTP Banner

Deze had je niet als melding bij mxtoolbox toch?

[Paultje3181]

Nee, alleen dat ie er wat lang over doet Maar dat is een kwestie van geheugen in de vps...

[syl765]

Met host kun je kijken of je reverse goed staat.

#host <publiek ipadres van mailserver>

In mijn geval ziet het er zo uit
host 83.167.xxx.xxx
xxx.xxx.167.83.in-addr.arpa domain name pointer mailserver.mijn-domein.com.

Als je bijvoorbeeld het volgende terug krijgt moet je nog wat handelingen uitvoeren.
xxx.xxx.167.83.in-addr.arpa domain name pointer static-xxx-xxx-167-83.provider.nl.

Meestal kun je de reverse niet zelf zetten en zul je dit aan je ISP moeten vragen.

[Paultje3181]

host 1.2.3.4
4.3.2.1.in-addr.arpa domain name pointer domain.nl

Dit staat dus goed (al is het het volledige domein en niet het subdomein voor de mailserver, maar dit maakt volgens mij niks uit toch?)

[syl765]

Ja dat maakt wel uit, Je server meld zich aan met bijvoorbeeld mailserver.domain.nl en komt van ip adres 1.2.3.4 nu doet de ontvangende server een reverse query op 1.2.3.4 om te kijken of hij ook dezelfde naam terug krijgt. Klopt dit niet dan zal de ontvangende server roepen dat er iets niet klopt. In jou geval komt dit dus niet overeen. De FQDN van de mailserver moet gelijk zijn aan de reverse lookup.

Je zag ook heel vaak toen deze check opkwam dat er heel veel exchange servers zich aanmelden met server.lokaalwindowsdomein.local en dat er dus vooral heel wat kleine bedrijven in de problemen kwamen omdat de exchange servers op de small bussines server editie van Microsoft eigenlijk nooit echt goed waren ingericht. En daarbij zaten ze ook vaak nog eens achter een DSL en dan werd het helmaal leuk want het was vrij lastig hier een reverse DNS op te zetten.

[ Voor 45% gewijzigd door syl765 op 12-12-2014 16:26 ]