wiadomość z HTML bez wersji tekstowej traktowana jako SPAM

Wiadomość HTML bez wersji tekstowej jest częściej klasyfikowana jako spam przez filtry antyspamowe.

Kontekst techniczny braku części tekstowej w strukturze MIME

Standard poczty elektronicznej w pierwotnym zamyśle opierał się wyłącznie na przesyłaniu niesformatowanego tekstu w kodowaniu ASCII. Wraz z rozwojem technologii i zapotrzebowaniem na formatowanie wprowadzono standard MIME (Multipurpose Internet Mail Extensions), który pozwala na dołączanie do wiadomości plików graficznych, dźwiękowych oraz treści zapisanej w języku znaczników HTML. Kiedy program pocztowy wysyła wiadomość z formatowaniem, domyślnie korzysta z typu zawartości określanego jako multipart/alternative. Oznacza to, że pojedyncza wiadomość przesyłana przez protokół SMTP zawiera w sobie kilka wersji tej samej treści. Prawidłowo skonstruowany e-mail posiada zarówno sekcję text/plain, czyli czysty tekst bez żadnego formatowania, jak i sekcję text/html, zawierającą kod odpowiedzialny za wygląd zewnętrzny.

Wiadomość zdefiniowana jako wyłącznie text/html łamie zaimplementowaną w środowiskach informatycznych konwencję. Zjawisko to polega na wysłaniu e-maila, w którym nadawca umieszcza jedynie sformatowany kod HTML, całkowicie pomijając blok zwykłego tekstu. Z punktu widzenia specyfikacji protokołu SMTP i samej struktury nagłówków taka wiadomość jest technicznie poprawna i zostanie przetworzona przez serwer docelowy. Brakuje jej jednak mechanizmu kompatybilności wstecznej. Aplikacje pocztowe (MUA - Mail User Agent) działające w środowiskach tekstowych, systemy analizujące tekst dla osób niedowidzących oraz urządzenia o ograniczonej przestrzeni do renderowania obrazu bazują na sekcji text/plain. Brak tego wariantu wymusza na urządzeniu końcowym próbę wyłuskania tekstu z tagów HTML, co zazwyczaj kończy się wyświetleniem kodu źródłowego lub całkowitą utratą czytelności.

Analiza mechanizmów oceny wiadomości w systemach antyspamowych

Filtry antyspamowe, takie jak SpamAssassin, Rspamd czy silniki zintegrowane w rozwiązaniach serwerowych, analizują każdą przychodzącą wiadomość na podstawie zdefiniowanych zestawów reguł. Każda reguła posiada określoną wagę punktową, a przekroczenie progu bezpieczeństwa skutkuje oznaczeniem e-maila jako spam lub jego odrzuceniem na poziomie MTA (Mail Transfer Agent). Jedną z podstawowych reguł walidacyjnych jest weryfikacja obecności części tekstowej. W oprogramowaniu SpamAssassin reguła ta nosi nazwę MIME_HTML_ONLY.

Dodatnia punktacja dla reguły MIME_HTML_ONLY, kwalifikująca wiadomość jako potencjalnie niepożądaną, wynika bezpośrednio z historycznych metod działania systemów rozsyłających spam. Kampanie reklamowe oraz ataki phishingowe często opierały się na e-mailach składających się wyłącznie z jednej grafiki osadzonej w kodzie HTML. Celowano w ominięcie filtrów analizujących słownictwo. Nadawcy spamu ukrywali słowa kluczowe, stosowali techniki zaciemniania kodu (obfuscation) lub wstrzykiwali zewnętrzne elementy śledzące (tracking pixels). Generowanie poprawnej, podwójnej struktury multipart/alternative wymagało użycia bibliotek programistycznych, dlatego proste skrypty wysyłały surowy kod HTML.

W efekcie silniki analityczne traktują brak sekcji text/plain jako wskaźnik użycia niskiej jakości skryptu automatycznego. Algorytmy klasyfikacji Bayesa znacznie szybciej analizują czysty tekst. Przetwarzanie samego kodu HTML pochłania dodatkową moc obliczeniową na usunięcie znaczników przed wykonaniem analizy lingwistycznej. Brak tekstu w postaci niesformatowanej jest klasyfikowany przez serwery filtrujące jako próba utrudnienia weryfikacji zawartości. E-mail w formacie wyłącznie HTML otrzymuje punkty karne, co w korelacji z brakami w rekordach SPF, DKIM czy DMARC prowadzi do odrzucenia przesyłki w docelowej domenie.

Błędy implementacyjne oraz wyzwania na poziomie oprogramowania

Niezgodność w strukturze MIME rzadko wynika z działania standardowych programów pocztowych dla użytkowników końcowych, takich jak Microsoft Outlook czy Mozilla Thunderbird. Aplikacje te automatycznie kompilują oba warianty wiadomości. Niezgodności generowane są przeważnie przez dedykowane skrypty, aplikacje webowe oraz moduły powiadomień w systemach ERP i CRM.

Programiści tworzący moduły powiadomień nierzadko wykorzystują natywne funkcje języków programowania, konfigurując jedynie nagłówek Content-Type: text/html. Zbudowanie poprawnej struktury MIME z odpowiednio zdefiniowanymi granicami (boundary) rozdzielającymi fragmenty tekstowe i sformatowane wymaga znajomości specyfikacji RFC 2045 oraz RFC 2046. Wybór prostszego rozwiązania skutkuje tym, że zautomatyzowane potwierdzenia rejestracji czy wygenerowane faktury są odrzucane przez serwery odbiorców.

Dodatkowym wektorem błędów bywają platformy do masowej wysyłki newsletterów. Edytory wizualne (WYSIWYG) skupiają się na generowaniu responsywnego kodu HTML. Jeśli konfiguracja serwera wysyłkowego nie wymusza automatycznej konwersji zawartości do wariantu tekstowego, wychodzące pakiety danych pozbawione są bloku text/plain. Usunięcie tego problemu polega na modyfikacji kodu źródłowego generatora wiadomości, integracji bibliotek takich jak PHPMailer lub odpowiedniej rekonfiguracji oprogramowania serwerowego odpowiadającego za routing poczty.

Diagnostyka konfiguracji lokalnych na stacjach roboczych

Błędy dostarczalności poczty uwarunkowane strukturą MIME są weryfikowane i rozwiązywane na poziomie programistycznym bądź na warstwie administracyjnej serwerów pocztowych. Tego typu interwencje nie należą do kompetencji lokalnych punktów naprawczych. Warszawskie Pogotowie Komputerowe profiluje swoją działalność ściśle w obszarze serwisowania warstwy sprzętowej. Zakres prac obejmuje diagnostykę uszkodzonych płyt głównych, naprawę sekcji zasilania, wymianę matryc czy klawiatur w laptopach i komputerach stacjonarnych, a także bezpośrednie odzyskiwanie danych z nośników magnetycznych i półprzewodnikowych. Serwis nie świadczy usług w zakresie zarządzania serwerami pocztowymi, analizy logów SMTP, audytu środowisk chmurowych ani modyfikacji skryptów aplikacyjnych.

Obecnie zgłoszenia dotyczące stricte sprzętowych usterek wywołujących błędy w komunikacji pocztowej należą do rzadkości, ponieważ architektura klient-serwer przeniosła obciążenie przetwarzania na infrastrukturę zewnętrzną. W sporadycznych sytuacjach uszkodzenie nośnika danych, objawiające się uszkodzonymi sektorami lub degradacją komórek pamięci flash, doprowadza do uszkodzenia lokalnych baz danych klientów pocztowych, takich jak pliki OST i PST. Naruszenie struktury tych plików może blokować interfejs aplikacji i powodować błędy w komunikacji lokalnej bazy z systemem operacyjnym. W tych szczególnych przypadkach rola serwisu ogranicza się do wykonania kopii posektorowej uszkodzonego nośnika, wymiany wadliwego podzespołu oraz próby wyekstrahowania uszkodzonych archiwów pocztowych w celu przywrócenia ich spójności przed ponownym zaimportowaniem na naprawiony sprzęt.