Posts by jonci

    A frissítés alatt küldött leveleket nem kapod meg, mert a mail szolgáltatás is leáll.


    Emailfogadási hibákat alapvetően két nagy csoportba soroljuk:

    • négyszázas (4xx)
    • ötszázas (5xx)

    Mindegyiken belül van sokféle. A 4xx-as hiba (templary failure átmeneti hibát jelent, azaz a küldő fél egy bizonyos idő után próbálja újraküldeni a levelet. 5xx-as hiba (permanent failure) esetén azonnal eldobásra kerül a levél.


    Frissítés alatt nem tudnak kapcsolódni a szerveredhez, ez az esetek 99%-ban 4xx-as hibát generál, azaz pár perc/óra múlva újra megpróbál a küldő fél SMTP szervere csatlakozni. Általában 3-5 napig áll fenn ez az eset (queue time-tól függ) és csak utána dobják el a leveleket végleg. Azaz várható, hogy a mail szolgáltatás újraindulásával megkapod később a frissítés alatt küldött leveleket.


    Annyi lehet még, hogy megérkeztek a leveleket, de a i-MSCP-n belül volt valami, ami 5xx-as hibát generált és lokálisan lettek eldobva a leveleket, de ez kiolvasható a /var/log/mail.log fájlból.

    Az i-MSCP csak a lokális DNS szervert tudja frissíteni, viszont ha a domained hivatalos DNS szerverei a szolgáltatóé, akkor az i-MSCP hiába írja bele a lokális DNS-be az új subdomain címét, az nem jut el a szolgáltató DNS szerveréig, így senki sem fog tudni róla.


    Ha ez az eset áll fenn, akkor csak úgy lehet megoldani a dolgot, ha az i-MSCP-be beállítod a szolgáltatód DNS szervereinel IP-címeit, mint slave DNS szerverek, továbbá a szolgáltatód beállítja az adott domainhez az i-MSCP-d IP-címét, mint master DNS. Így ha az i-MSCP frissíti a zónát, akkor küld egy notify-t a slave DNS-eknek, hogy frissítsék a zónát.

    Azt tudom elképzelni, hogy az i-MSCP frissítése közben megpróbálta scannelni a szervereden futó valamelyik weboldalt a Pingdom (Website Monitoring) robotprogramja, azonban hibára futott, mert nem futott még az SQL.