Navigatie overslaan.
Start

Postfix deferred queue

Als je een mailserver hebt, is het beheer van de verschillende mailqueues zeer belangrijk. Zeker omdat steeds meer en meer bedrijven Greylisting implementeren. (Zie ook http://blog.knudde.be/spam+fighting)
Greylisting zorgt er voor dat de eerste mail tijdelijk gereject wordt voor 300 seconden, het opnieuw versturen van dergelijke mail binnen een redelijke termijn is dus zeer belangrijk.
Dit gaat over het beheren van de deferred queue in Postfix omdat ik merk dat veel bedrijven absoluut niet weten waarmee ze bezig zijn.
Mail die tijdelijk niet verstuurd kan worden, door een 4xx foutmelding, komt in de "deferred"-queue van Postfix.
Vandaar kan een bericht terug in de "active"-queue gezet worden om te versturen.
Er zijn 3 timers die belangrijk zijn hiervoor:

  • De "queue_run_delay" (Default 300 seconden)
  • De "minimal_backoff_time" (Default 300 seconden)
  • De "maximal_backoff_time" (Default 4000 seconden)

De deferred queue gaat elke "queue_run_delay" gescanned worden om te kijken of er mail aanwezig is die terug naar de active queue kan.
Indien dit het geval is, worden die mails ook terug in de active queue gezet. Indien er gelijktijdig ook berichten in de incomming queue zitten, dan wordt er om en om een bericht in de active queue gezet om geen starvation van queues te krijgen.
Als je in de deferred queue kijkt, dan zal je zien dat alle tijden in de toekomst zijn. Dit komt omdat ieder bericht dat in deze queue gezet wordt een timestamp meekrijgt dat tussen "minimal_backoff_time" en "maximal_backoff_time" ligt in de toekomst.
Enkel berichten waarvan de tijd kleiner of gelijk is aan de huidige tijd, worden terug in de active queue gezet.
Indien een bericht dat reeds in de deferred queue stond, nog steeds niet verzonden kan worden, dan wordt de "backoff_time" verdubbeld. Indien een verdubbeling ervoor zou zorgen dat de tijd groter wordt dan de "maximal_backoff_time", dan wordt deze laatste genomen.
Voorbeeld, met default waarden:
Een mail wordt tijdelijk niet geaccepteerd.
Deze wordt in de deferred queue gestopt met wachttijd tussen 300 en 4000 seconden.
Iedere 300 seconden wordt de queue gescanned
Aangezien je geen controle hebt over wanneer exact die queue gescanned wordt, gaat bij een minimum backoff_time van 300 seconden dus ergens tussen de 300 en 599 seconden de mail opnieuw naar de active queue.
Bij een maximale backoff_time (4000 seconden), gaat je mail in de active queue tussen 4200 en 4499 seconden.
4200 seconden en geen 4000, omdat de queue slechts elke 300 seconden gescanned wordt.
13 x 300 is 3900, dus pas ten vroegste de 14de keer (14 x 300 = 4200 seconden) worden de berichten geprobeerd die een backoff_time hebben van meer dan 3900 seconden.
Indien een mail ook de tweede keer niet kan afgeleverd worden, dan zal de backoff time (meestal) verdubbeld worden, dus tussen de 600 en 4000 seconden liggen.
De tweede poging wordt dus ondernomen tussen 900 (300 + 600) en 8699 (4200 + 4200 + 299) seconden na de eerste poging.
Persoonlijk vind ik meer dan een uur (worst case) een beetje lang om het bericht voor de eerste keer opnieuw te proberen indien het enkel om greylisting gaat, dus hoe kunnen we dit versnellen?
De default greylisting waarde is 5 minuten (300 seconden) het heeft daarom geen zin om de "minimal_backoff_time" kleiner te maken dan 300 seconden.
(In feite werkt dat averechts, omdat de tweede keer de tijd verdubbeld wordt.
Als je bijvoorbeeld 200 seconden zou nemen als "minimal_backoff_time", en ook de "queue_run_delay" zou aanpassen, dan zou dit toch falen de eerste keer voor alle mails met een backoff_time van minder dan 300 (200 tot 299) seconden. Deze mails worden dan opnieuw in de queue gezet worden met een backoff_time die verdubbelt (400 tot 598 seconden), in totaal zal een dergelijke mail dus pas een kans op slagen hebben na 600 tot 897 seconden, i.p.v. 300 met de default waarden.)
Om de 20 minuten een mail opnieuw proberen af te leveren meestal acceptabel, dus de "maximal_backoff_time" wordt dan 1200 seconden.
Als je genoeg IO resources hebt op je server, kan je zelfs de "queue_run_delay" verlagen tot bijvoorbeeld 150 seconden.
Op die manier wordt een bericht tussen de 300 en 1200 seconden "gedeferred" en iedere 150 seconden kunnen er brichten opnieuw geprobeerd worden.
Indien het niet om greylisting gaat, maar om een echt probleem (te weinig schijfruimte of zo), dan zullen de retry perioden als volgt zijn: 300, 600, 1200, 1200, 1200, ... seconden.
Dus met een "queue_run_delay" van 150, worden de "echte" tijden 300-449, 600-749, 1200-1349, 1200-1349, 1200-1349, ...
Bij greylisting heb dus een gegarandeerde aflevering van de email binnen 449 seconden, of iets minder dan 7,5 minuten. Iets dat zeer acceptabel is.
Nog een belangrijke parameter is "maximal_queue_lifetime" (default 5 dagen).
Als een bericht echt niet afgeleverd kan worden in 5 dagen, dan worden de pogingen gestaakt en een "undeliverable message" terug gestuurd.
Met de hoeveelheid spam van vandaag de dag, en de redundancy die heel eenvoudig met mailservers te bereiken zijn, is het aan te raden om deze tijd drastisch te verminderen. De meeste mailservers op het internet hebben 1 tot 2 dagen ingesteld.