[exim] Geen mail meer naar buiten (routing defer)

[Fl4sh3r]

Sinds enkele dagen is het me opgevallen dat ik vanaf mijn Debian (Woody) servertje geen mail meer naar buiten kan sturen. Ik krijg dan mailtjes terug met zo'n leuke melding "A message that you sent has not yet been delivered to one or more of its
recipients after more than 24 hours on the queue on server.nl."

In /var/log/exim/mainlog vond ik een relevante opmerking (denk ik):
2005-04-27 22:13:20 1DQsuO-0002is-00 == [e-mail] routing defer (-42): retry time not reached

Google heeft voor mij niets nuttigs opgeleverd, wel wat vage omschrijvingen die ook iets met 'routing defer' te maken hebben. Ik heb exim al opnieuw gestart, hier kon ik nergens errors bij vinden (syslog en exim-log bekeken)

Het zou kunnen zijn dat het probleem is sinds ik zelf DNS ben gaan doen.

Als iemand suggesties heeft, heel graag.
Een oplossing zou fantastisch zijn.

[TrailBlazer]

klinkt alsof je dns brak is. exim probeert een mx record te vinden voor je mail en dat gaat mis denk ik

[Coen Rosdorff]

Zoek de relevante gegegevens eens op in de main log van exim.
Daar staat 99 van 100 keer in klare taal wat het probleem is.

offtopic:
waarom doen ts'ers dat niet standaard

[Fl4sh3r]

ik las ergens "exim -qff" dit lijkt het opgelost te hebben...

Als lijktme dat niet, maar goed, het werkt weer (even).

Beide bedankt voor jullie reactie

[FiscBiker]

-q is enkel om een queue run te beginnen (boodschappen die op bezorging staan te wachten weer eens een keertje te proberen)

de 'ff' erbij wil enkel zeggen dat ALLE boodschappen geprobeerd moeten worden en niet alleen die, die in aanmerking komen om opnieuw geprobeerd te worden (Ja, exim denkt daarover na).

Dus als je boodschappen nu wel werden verstuurd wil dat gewoon zeggen dat wat er eerst dan ook fout was, nu weer (even) goed is.

met dank aan:

man exim

[ Voor 5% gewijzigd door FiscBiker op 29-04-2005 00:19 ]

[Verwijderd]

Ja, en -qff betekent ook dat als ze nog steeds niet afgeleverd kunnen worden, hij ze gewoon uit de queue verwijderd. Dus grote kans dat je nu een heleboel mail naar /dev/null verwezen hebt.
routing defer (-42): retry time not reached wil gewoon zeggen dat het nog geen tijd is om de message te retryen, de echte error staat eerder in je log.
Tail -f je log eens terwijl je een mail probeert te versturen.
Exigrep doet ook wonderen voor het opzoeken van errors in grote logs.

[Fl4sh3r]

Als ik met tail -f kijk krijg ik gewoon netjes "Completed" te zien bij mails die ik nu verstuur...

Het zal dus wel weer werken :-) hoe en waarom? geen idee, helaas. Dus als het probleem zich weer voordoet zal ik het weer moeten uitzoeken, maar voor nu vind ik het wel best. Bovendien is het lastig de oorzaak te vinden nu het 'altijd' goed gaat.

[Verwijderd]

Fl4sh3r schreef op vrijdag 29 april 2005 @ 13:41:
Als ik met tail -f kijk krijg ik gewoon netjes "Completed" te zien bij mails die ik nu verstuur...

Het zal dus wel weer werken :-) hoe en waarom? geen idee, helaas. Dus als het probleem zich weer voordoet zal ik het weer moeten uitzoeken, maar voor nu vind ik het wel best. Bovendien is het lastig de oorzaak te vinden nu het 'altijd' goed gaat.

Meestal, 9 van de 10 keer, wacht Exim met versturen van de mail omdat hij geen lookup kan doen op het domein waar de mail heen moet. Dat kan zijn omdat de lokale DNS niet werkt, of omdat de DNS verantwoordelijk voor het domein niet werkt. Dit geldt zowel bij het accepteren als versturen van mail.

Je kan het uitzetten, maar het is een heel handig middel tegen virussen en spam aangezien die vaak van niet bestaande domeinen komen. Maar ik dwaal af, wat je zag zou dus goed kunnen kloppen met jouw dns verhaal, als Exim geen lookups kan doen worden alle mails gedeferred tot een later tijdstip.