WordPress wysyła maile na nieistniejący adres? Sprawdź, gdzie trafiają alerty

Co noc, kilka minut po północy, do skrzynki wpada ta sama wiadomość: Unrouteable address. Serwer pocztowy próbuje dostarczyć maila na adres admin@ w domenie strony i nie ma go dokąd zanieść, bo takiej skrzynki nigdy nie było. Taki objaw potrafi ciągnąć się tygodniami, bo mało kto łączy go z alertami strony.

Jeśli Twój WordPress wysyła maile na nieistniejący adres, a w ustawieniach witryny widzisz poprawny e-mail administratora, ten wpis jest dla Ciebie. Pokazujemy, skąd bierze się taki adres, dlaczego zwykła zmiana w panelu nic nie daje i jak jedna cyfra w bazie danych może zabrać wtyczce wszystkie ustawienia.

Objaw: zwrotka co noc o tej samej godzinie

Przykład z jednej z naszych stron technicznych na WordPressie, chronionej zaporą aplikacyjną: co noc o 00:03 serwer generował zwrotkę o niedostarczalnym adresie. Zanim ktoś powiąże takie zwrotki ze stroną, wyglądają jak zwykły szum serwerowy.

To coś poważniejszego niż śmieci w skrzynce. Alert bezpieczeństwa wysłany na nieistniejący adres to alert, którego nikt nie przeczyta. Zapora mogła w tym czasie zgłaszać cokolwiek: próby logowania, zablokowane ataki, potrzebę aktualizacji. Nikt by się o tym nie dowiedział.

Diagnoza: co sprawdzić po kolei

Hipoteza 1: zły adres administratora w WordPressie. Nie to.

Pierwszy odruch to sprawdzenie Ustawienia – Ogólne – Adres e-mail administracji, czyli opcji admin_email. Była poprawna, wskazywała naszą działającą skrzynkę. WordPress sam w sobie wysyłał więc powiadomienia tam, gdzie trzeba.

Hipoteza 2: serwer pocztowy. Też nie.

Skoro WordPress miał dobry adres, a odbitki mówiły o złym, wyglądało to na problem po stronie serwera pocztowego: przepisywanie adresów, alias, domyślny nadawca. Tyle że serwer robił dokładnie to, co powinien. Dostał maila zaadresowanego do admin@, nie znalazł takiej skrzynki i odesłał zwrotkę. Problem był w tym, kto ten adres wpisał jako odbiorcę.

Trop: stała godzina

Zwrotka przychodziła codziennie o 00:03, a nie przy konkretnych zdarzeniach na stronie. To wskazywało na zadanie zaplanowane, a takie zadania na tej stronie miały dwie wtyczki: zapora aplikacyjna NinjaFirewall i skaner plików NinjaScanner. Przejrzeliśmy ich opcje w bazie danych.

Odkrycie: wtyczka ma własny adres alertów

W bazie siedziały dwa takie miejsca: opcja nfw_options z kluczem alert_email oraz opcja nscan_options z kluczem admin_email. W obu był adres admin@ w domenie strony, wpisany kiedyś przy instalacji i nigdy niezałożony jako skrzynka.

To nie jest przypadłość tylko tych dwóch wtyczek. Wiele wtyczek bezpieczeństwa i narzędzi serwisowych ma osobne pole na adres powiadomień (na przykład Wordfence ma własne ustawienie adresu dla alertów). Zmieniasz e-mail administratora, przekazujesz stronę komuś innemu, kasujesz starą skrzynkę – a wtyczka dalej pisze tam, gdzie pisała.

Naprawa: podmiana w bazie, ale z jedną liczbą, o której łatwo zapomnieć

Najprościej zmienić adres w panelu wtyczki albo przez WP-CLI. Bywa jednak, że panel jest niedostępny, a zapora blokuje uruchamianie PHP z linii poleceń – wtedy zostaje poprawka bezpośrednio w bazie danych. I tu zaczyna się pułapka.

Serializacja: długość tekstu jest zapisana obok tekstu

Opcje wtyczek WordPress zapisuje w postaci zserializowanej. Każdy tekst ma przed sobą swoją długość w bajtach:

s:20:"admin@twojadomena.pl"

Liczba 20 to dokładna długość adresu. Jeśli podmienisz sam adres na inny, o innej długości, a liczby nie poprawisz, PHP przy odczycie nie odtworzy opcji. Dla wtyczki to wygląda jak brak ustawień – i zachowuje się, jakby była świeżo zainstalowana. W przypadku zapory oznacza to utratę reguł, wyjątków i całej konfiguracji ochrony.

Bezpieczna podmiana krok po kroku

1. Kopia obu opcji do pliku, zanim cokolwiek zmienimy.
2. Odszukanie wszystkich miejsc, gdzie występuje stary adres:

   SELECT option_name FROM wp_options
   WHERE option_value LIKE '%admin@twojadomena.pl%';

3. Podmiana adresu razem z prefiksem długości, tylko w tych dwóch opcjach:

   UPDATE wp_options
   SET option_value = REPLACE(option_value,
     's:20:"admin@twojadomena.pl"',
     's:21:"alerty@twojadomena.pl"')
   WHERE option_name IN ('nfw_options', 'nscan_options');

4. Weryfikacja, że opcje dalej się odczytują. Wartość wyciągamy z bazy w surowej postaci i sprawdzamy, czy PHP ją odtworzy:

   mysql --raw -N -e "SELECT option_value FROM wp_options WHERE option_name='nfw_options'" baza > nfw.txt
   php -r 'var_dump(is_array(unserialize(trim(file_get_contents("nfw.txt")))));'
   # oczekiwany wynik: bool(true)

Jeśli masz dostęp do panelu wtyczki albo działające WP-CLI, zmiana adresu przez interfejs wtyczki jest bezpieczniejsza, bo wtyczka sama przeliczy serializację. Podmiana SQL-em to wyjście awaryjne, gdy innej drogi nie ma.

Efekt i zasada powiadomień, którą stosujemy

Nocne zwrotki się skończyły. Obie wtyczki zachowały ustawienia, a alerty trafiają do skrzynki, którą ktoś naprawdę czyta.

Samo poprawienie adresu to połowa roboty. Alert jest wart tyle, ile szansa, że ktoś go przeczyta. Dlatego na stronach, którymi się opiekujemy, powiadomienia ustawiamy według jednej zasady:

• Jeden adres alertów, który na pewno istnieje i jest czytany – nasza skrzynka serwisowa, a nie przypadkowy adres wpisany przy instalacji.
• Tylko alerty o realnych zdarzeniach: zablokowane próby ataku (np. próba nadania komuś roli administratora) oraz informacje o aktualizacjach bezpieczeństwa.
• Raporty, powiadomienia o każdym logowaniu i inne „informacyjne” maile wyłączone. Skrzynka zalana szumem to skrzynka, w której przeoczy się ten jeden ważny alert.

Domyślna konfiguracja zapory po instalacji wysyła sporo informacyjnych maili na adres administratora strony, czyli często na prywatną skrzynkę właściciela. Dlatego ustawienie powiadomień według tej zasady jest dziś stałym krokiem po każdej instalacji zapory, a nie czymś, o czym przypominamy sobie przy pierwszym problemie.

Jeśli nie masz czasu pilnować, gdzie wtyczki na Twojej stronie wysyłają alerty, i czy ktoś je w ogóle czyta, to jest jedna z rzeczy, które robimy w ramach opieki nad stroną WordPress.

Jak sprawdzić u siebie w 10 minut

1. Sprawdź Ustawienia – Ogólne: czy adres administratora istnieje i ktoś go czyta.
2. Wejdź w ustawienia każdej wtyczki bezpieczeństwa, kopii zapasowych i SMTP i poszukaj pola „e-mail do powiadomień”. Porównaj z adresem administratora.
3. Jeśli masz dostęp do bazy, poszukaj starych adresów w opcjach: SELECT option_name FROM wp_options WHERE option_value LIKE '%@twojadomena%';
4. Przejrzyj skrzynkę pod kątem zwrotek typu „Unrouteable address”, „User unknown”, „Mailbox not found”. Godzina, o której przychodzą, podpowie, które zadanie je wysyła.
5. Zastanów się, które alerty naprawdę są Ci potrzebne. Jeśli dostajesz ich tyle, że ich nie czytasz, wyłącz te informacyjne i zostaw te o atakach.

Czego nauczyła nas ta historia

Adres e-mail administratora w WordPressie nie jest jedynym adresem, pod który strona coś wysyła. Każda wtyczka z powiadomieniami może mieć własny, i ten adres trzeba sprawdzić osobno przy instalacji, przy przekazaniu strony i przy każdej zmianie skrzynek. A gdy trzeba coś zmienić w zserializowanej opcji bezpośrednio w bazie, zmieniamy zawsze tekst razem z jego długością i sprawdzamy odczyt, zanim uznamy sprawę za zamkniętą.

FAQ

Dlaczego WordPress wysyła maile na adres, którego nie ma w ustawieniach?

Najczęściej nie wysyła ich sam WordPress, tylko wtyczka z własnym polem adresu powiadomień. Zapory, skanery, wtyczki kopii zapasowych i formularze potrafią trzymać adres wpisany przy instalacji, niezależnie od adresu administratora.

Co oznacza „Unrouteable address” w zwrotce?

Serwer pocztowy nie znalazł drogi do adresata – najczęściej dlatego, że skrzynka o takim adresie nie istnieje w danej domenie. Sam serwer działa poprawnie, problem leży w adresie, który ktoś wpisał jako odbiorcę.

Czy mogę po prostu zmienić adres w bazie danych przez REPLACE?

Tylko jeśli poprawisz też długość tekstu zapisaną przed nim (np. s:20 na s:21). Sama podmiana adresu o innej długości psuje serializację i wtyczka traci wszystkie ustawienia. Bezpieczniej zmienić adres w panelu wtyczki, jeśli jest dostępny.

Jak sprawdzić, czy serializacja po zmianie jest poprawna?

Pobierz wartość opcji z bazy w surowej postaci (mysql --raw) i sprawdź, czy funkcja unserialize() zwraca tablicę. Bez surowego trybu znaki specjalne są escapowane i test daje fałszywy wynik.

Na jaki adres powinny iść alerty bezpieczeństwa?

Na skrzynkę, która na pewno istnieje i którą ktoś regularnie czyta – właściciela strony albo firmy, która się nią opiekuje. Ważniejsze od samego adresu jest ograniczenie alertów do realnych zdarzeń, żeby ważna wiadomość nie zginęła w szumie.