Zmierzone 2026-09-07, na zywym poleceniu:
$ node packages/zerosmtp-check/index.js --explain "553 5.7.1 Sender address rejected"
530 5.7.1 - Delivery not authorized
... the authenticated account is not allowed to send as the address in the From field
... Microsoft does document it for this one
Dopasowanie leci po 5.7.1 i trafia we wpis Microsoftu. Czytelnik dostaje odpowiedz, ktora brzmi trafnie - mowi wrecz o adresie From - i wysyla go do ustawien tenanta Exchange Online, podczas gdy odmowe wystawil nasz wlasny relay, a przyczyna jest po jego stronie hosta.
To nie jest brak odpowiedzi. To pewna zla odpowiedz, czyli gorszy przypadek: nic nie sygnalizuje czytelnikowi, ze patrzy nie tam.
Dlaczego nie naprawilem tego od reki
data/errors.json jest korpusem bledow Microsoftu - wszystkie 17 wpisow. 553 ... not owned by user to blad naszego przekaznika. Wepchniecie go tam zmienia zakres korpusu, ktory zasila rowniez strony bledow i llms.txt. To decyzja projektowa, nie poprawka przy okazji zmiany w dokumentacji.
Znalezione przy okazji PR #422, gdzie pierwotny szkic obiecywal wlasnie to polecenie jako sposob sprawdzenia. Obietnica zostala wycieta po uruchomieniu - nie po przeczytaniu kodu.
Do rozstrzygniecia
Trzy drogi, kazda ma koszt:
- Osobne zrodlo dla bledow msgwing obok korpusu Microsoftu, laczone przy dopasowaniu. Czysto, ale to nowy plik danych i nowa sciezka w generatorach.
- Pole
vendor w istniejacym korpusie i dopisanie naszych wpisow. Mniej plikow, ale zmienia znaczenie kazdego istniejacego wpisu.
- Nic nie dodawac, a jedynie nie zgadywac: gdy ciag zawiera kod odpowiedzi (
553), ktorego nie ma w korpusie, odmowic dopasowania po samym kodzie rozszerzonym (5.7.1). Najtansze, i samo w sobie usuwa pewna zla odpowiedz.
Wariant 3 da sie zrobic i przetestowac niezaleznie od tego, ktory z pozostalych zostanie kiedys wybrany.
Warunek odbioru
--explain "553 5.7.1 Sender address rejected" nie zwraca strony o Microsoft 365. Test w packages/zerosmtp-check/test/ sprawdza to wprost, i pada, jesli ktos przywroci dopasowanie po samym 5.7.1.
Zmierzone 2026-09-07, na zywym poleceniu:
Dopasowanie leci po
5.7.1i trafia we wpis Microsoftu. Czytelnik dostaje odpowiedz, ktora brzmi trafnie - mowi wrecz o adresie From - i wysyla go do ustawien tenanta Exchange Online, podczas gdy odmowe wystawil nasz wlasny relay, a przyczyna jest po jego stronie hosta.To nie jest brak odpowiedzi. To pewna zla odpowiedz, czyli gorszy przypadek: nic nie sygnalizuje czytelnikowi, ze patrzy nie tam.
Dlaczego nie naprawilem tego od reki
data/errors.jsonjest korpusem bledow Microsoftu - wszystkie 17 wpisow.553 ... not owned by userto blad naszego przekaznika. Wepchniecie go tam zmienia zakres korpusu, ktory zasila rowniez strony bledow illms.txt. To decyzja projektowa, nie poprawka przy okazji zmiany w dokumentacji.Znalezione przy okazji PR #422, gdzie pierwotny szkic obiecywal wlasnie to polecenie jako sposob sprawdzenia. Obietnica zostala wycieta po uruchomieniu - nie po przeczytaniu kodu.
Do rozstrzygniecia
Trzy drogi, kazda ma koszt:
vendorw istniejacym korpusie i dopisanie naszych wpisow. Mniej plikow, ale zmienia znaczenie kazdego istniejacego wpisu.553), ktorego nie ma w korpusie, odmowic dopasowania po samym kodzie rozszerzonym (5.7.1). Najtansze, i samo w sobie usuwa pewna zla odpowiedz.Wariant 3 da sie zrobic i przetestowac niezaleznie od tego, ktory z pozostalych zostanie kiedys wybrany.
Warunek odbioru
--explain "553 5.7.1 Sender address rejected"nie zwraca strony o Microsoft 365. Test wpackages/zerosmtp-check/test/sprawdza to wprost, i pada, jesli ktos przywroci dopasowanie po samym5.7.1.