5.1.0Ogólne odrzucenie ze względu na status adresu, udokumentowane zarówno dla nadawcy, jak i odbiorcy

Ogólny kod zbiorczy IANA w rodzinie przedmiotowej adresowania to wzorzec rejestru X.1.0 („Inny status adresu”), stosowany gdy żaden bardziej szczegółowy kod statusu adresu nie ma zastosowania; kod 5.1.0 nadaje mu klasę trwałą. Mechaniczne potwierdzenie IANA dla X.1.0 w tym katalogu nie obejmuje żadnej klasy: Associated Basic Status Code w rejestrze brzmi „Not given”, a kanoniczne odwzorowanie rejestru IANA zapisuje status rozstrzygnięcia wzorca jako nierozstrzygnięty. Ten konkretny kod klasy 5 publikujemy wyłącznie na podstawie dokładnego dowodu produkcyjnego zebranego w korpusie. Dwóch dostawców (Orange, Rackspace) używa 5.1.0, by odrzucić nieprawidłowego lub nieautoryzowanego nadawcę koperty. Trzeci zapis, raport niedostarczenia przekazany przez bramę wejściową hostowaną przez Cisco (iphmx.com), używa tego samego kodu w bezpośredniej odpowiedzi na RCPT TO, by tym razem odrzucić adres odbiorcy koperty. Ponieważ sam kod szczegółowy jest ogólny i nazywa „status adresu” bez wskazania, którego adresu dotyczy, zawsze czytaj pełny tekst odpowiedzi i etap SMTP (MAIL FROM czy RCPT TO), zamiast zakładać jedno znaczenie na podstawie samego „5.1.0”.

Dokładny dowód korpusowy obejmujący dwa różne problemy adresowe uzasadnia publikację konkretnego kodu 5.1.0 (klasa 5, trwały). Orange i Rackspace zwracają „501 5.1.0” / „550 5.1.0”, by odrzucić wiadomość, której nadawca koperty (Return-Path) jest nieprawidłowy albo nieautoryzowany do wysyłki w imieniu zadeklarowanej domeny; osobny zapis pokazuje system odbiorczy za bramą wejściową hostowaną przez Cisco (iphmx.com), który w bezpośredniej odpowiedzi na polecenie RCPT TO zwraca „550 #5.1.0 Address rejected.” i odrzuca adres odbiorcy koperty, a nie nadawcy. Wzorzec X.1.0 to jawny kod zbiorczy IANA w rodzinie przedmiotowej adresowania (przedmiot 1): „coś związanego z adresem podanym w wiadomości spowodowało wysłanie tego DSN”. RFC 3463 (sekcja 3.2) definiuje schemat przedmiot/szczegół bez rozstrzygania klasy dla każdego wzorca. Dla samego X.1.0 Associated Basic Status Code w rejestrze to „Not given”, a kanoniczne odwzorowanie rejestru IANA w tym katalogu zapisuje classApplicability.resolutionStatus jako „unresolved” (podstawa: iana_missing_class_evidence). Ani klasa 4, ani klasa 5 nie mają mechanicznego potwierdzenia IANA dla tego wzorca. Sam ogólny kod szczegółowy nie rozróżnia problemów po stronie nadawcy od problemów po stronie odbiorcy; robią to polecenie SMTP, na które odpowiedziano, oraz treść odpowiedzi.

Pierwsza cyfra 5 oznacza niepowodzenie trwałe. W każdym zaakceptowanym przykładzie odrzucenie wynika ze stanu, który nie ustąpi samoistnie — nieautoryzowanej tożsamości nadawcy albo odrzuconego adresu — więc ponowne wysłanie identycznej wiadomości na identyczny adres zakończy się tym samym niepowodzeniem z tego samego powodu. Różni się to od hipotetycznego użycia tego samego szczegółu X.1.0 w klasie 4, które opisywałoby stan mogący ustąpić samoistnie. Żaden taki konkretny kod klasy 4 nie jest publikowany w tym katalogu na podstawie dostępnego dowodu.

Klasa

Niepowodzenie trwałe

Ponowienie

Nie ponawiaj bez zmian

Supresja

Sprawdź pełny kontekst

Nie ponawiaj identycznej wiadomości bez zmian: każdy zaakceptowany przykład należy do klasy 5, więc identyczna wysyłka zakończy się niepowodzeniem, dopóki nie naprawisz leżącego u podstaw problemu adresu lub uwierzytelniania. Jeśli tekst odpowiedzi wskazuje na tożsamość nadawcy (jak w przykładach Orange i Rackspace), wstrzymaj wysyłkę z niezgodnej domeny, dopóki nie poprawisz zgodności SPF/Return-Path. Jeśli tekst odpowiedzi wskazuje na adres odbiorcy (jak w przykładzie przekazanym przez Cisco), przestań ponawiać wysyłkę na ten adres i zweryfikuj go z odbiorcą inną drogą, zanim wyślesz wiadomość ponownie.

Nie wykluczaj adresu odbiorcy wyłącznie na podstawie 5.1.0 bez wcześniejszego przeczytania pełnego tekstu odpowiedzi: kod ten obejmuje w dowodach tego katalogu dwie różne sytuacje, a tylko jedna z nich (odrzucony adres odbiorcy) rzeczywiście dotyczy tego adresu. Jeśli tekst wskazuje na problem z tożsamością nadawcy albo uwierzytelnianiem, skieruj sygnał do osoby odpowiedzialnej za uwierzytelnianie domeny nadawcy, a nie do procesu higieny listy; wyklucz adres odbiorcy tylko wtedy, gdy dokładny tekst wskazuje ten adres jako odrzucony.

• Nadawca koperty (Return-Path) wiadomości używa domeny, której rekord SPF nie autoryzuje wysyłającego adresu IP, albo domena Return-Path nie jest zgodna z domeną w nagłówku From: — przyczyna wskazana wprost w zaakceptowanych przykładach Orange i Rackspace („Invalid Sender” / „Sender is not allowed to send from example.com”).
• Tożsamość HELO/EHLO systemu wysyłającego albo uwierzytelnione konto nie odpowiada domenie w nadawcy koperty, więc system odbiorcy traktuje sam adres nadawcy jako nieprawidłowy dla tego połączenia.
• System odbiorczy albo brama bezpieczeństwa umieszczona przed nim (jak hostowana przez Cisco brama iphmx.com w zaakceptowanym przykładzie) odrzuca adres odbiorcy koperty podczas RCPT TO z powodu, który dostawca klasyfikuje pod tym ogólnym kodem „statusu adresu”, a nie pod bardziej szczegółowym kodem, np. X.1.1.
• Ponieważ X.1.0 to nieokreślony kod zbiorczy IANA dla przedmiotu adresowania, poszczególni dostawcy przypisują go do dowolnego stanu związanego z adresem, który nie pasuje do bardziej szczegółowego kodu w ich własnej implementacji — to dokładny tekst odpowiedzi, nie sam kod rozszerzony, wskazuje rzeczywistą przyczynę.

1. Sprawdź surową odpowiedź SMTP lub raport doręczenia i potwierdź, że kod rozszerzony to dokładnie 5.1.0; zanotuj podstawowy kod odpowiedzi (501 w przykładzie Orange, 550 w przykładach Rackspace i przekazanym przez Cisco) oraz dokładny etap SMTP — MAIL FROM dla odrzucenia tożsamości nadawcy, RCPT TO dla odrzucenia adresu odbiorcy.
2. Przeczytaj pełny tekst odpowiedzi, zanim założysz przyczynę: jeśli wskazuje nadawcę, envelope-from, Return-Path albo mechanizm uwierzytelniania (SPF/DKIM/zgodność domen), traktuj to jako odrzucenie po stronie nadawcy; jeśli wskazuje adres odbiorcy albo pojawia się w bezpośredniej odpowiedzi na RCPT TO bez żadnych sformułowań dotyczących nadawcy, traktuj to jako odrzucenie po stronie odbiorcy.
3. Dla 5.1.0 po stronie nadawcy sprawdź rekord SPF domeny wysyłającej pod kątem adresu IP wysyłki i potwierdź zgodność Return-Path/From:; sprawdź, czy tożsamość HELO/EHLO albo uwierzytelnione konto wysyłki odpowiada domenie nadawcy koperty.
4. Dla 5.1.0 po stronie odbiorcy potwierdź, że adres odbiorcy jest poprawnie zbudowany i aktualnie istnieje, oraz sprawdź, czy odpowiedź została przekazana przez pośredniczącą bramę bezpieczeństwa (hostowany filtr antyspamowy/bezpieczeństwa umieszczony przed właściwymi serwerami pocztowymi domeny docelowej), która może odrzucać adresy niezależnie od samej skrzynki docelowej.