Jeśli jesteś właścicielem tej strony, możesz wyłączyć reklamę poniżej zmieniając pakiet na PRO lub VIP w panelu naszego hostingu już od 4zł!

Wybrane problemy z używaniem HTML w poczcie elektronicznej

Wbrew oczekiwaniom nie zamierzam tu prezentować poglądu, że HTML w poczcie elektronicznej zawsze jest be. Jak wszystko, HTML ma swoje zastosowania: tam gdzie wymagane jest formatowanie tekstu, umieszczenie obrazków w odpowiednich miejscach tekstu, bardziej skomplikowane tabele itp. Niestety, wiele osób wysyła pocztę w formacie HTML mimo że nie używają żadnego formatowania treści. Całość jest napisana jednym, domyślnym krojem, wielkością i kolorem czcionki. Brak w treści jakichkolwiek elementów formatowanych, których nie można przedstawić w formacie czystego tekstu. Taki list wygląda identycznie w HTML-u i w formacie tekstowym, za to jest dużo większy: zbędny nagłówek HTML plus liczne zbędne znaczniki akapitów i łamania linii dodają zbędne kilobity. Używanie HTML bez stosowania formatowania jest tożsame z brakiem szacunku do odbiorcy i jest niemądre (delikatnie mówiąc).

Pisząc w HTML należy pamiętać, że niektórzy świadomie wyłączają (z powodów podanych dalej w artykule) wyświetlanie części HTML. Z tego powodu każdy list HTML powinien zawierać część w formacie zwykłego tekstu, która niesie tę samą informację, co część HTML. Chyba każdy program do poczty elektronicznej może być tak skonfigurowany, by automatycznie generował alternatywną wersję tekstową z wersji HTML – należy zawsze pamiętać, by tak skonfigurować swój program, by poprawna część tekstowa towarzyszyła przesyłce HTML. Zaniedbanie tego powoduje, że pewna grupa odbiorców (coraz pokaźniejsza) będzie miała trudności z zobaczeniem treści. W szczególności należy tu napiętnować różne newslettery, które albo nie mają w ogóle części tekstowej, albo cała jej zawartość to bezwartościowe stwierdzenie typu „To jest wiadomość w formacie HTML, kolorowym, fantastycznym, migającym, głośno grającym, aprobowanym przez Microsoft, automatycznie uruchamiającym wszystko, co da się uruchomić, przejmującym kontrolę nad komputerem i mózgiem odbiorcy” – wyjątkowo nieprofesjonalne (czytaj: lamerskie), prawda? Zawsze upewnij się, że Twoja wiadomość jest czytelna i zawiera wszystko, co istotne, gdy wyświetlana jest jako czysty tekst.

  1. Podstawowe formatowanie, które można stosować w listach w formacie zwykłego tekstu
    1. Obsługa formatowania tekstowego w mailerach i czytnikach
  2. Zagrożenia dla bezpieczeństwa i prywatności
  3. Inne niedogodności stosowania HTML w poczcie elektronicznej
  4. Do czego nie służy HTML w poczcie
  5. Ciekawostka historyczna: format enriched text – alternatywa dla HTML

1. Podstawowe formatowanie, które można stosować w listach w formacie zwykłego tekstu

1.1. Obsługa formatowania tekstowego w mailerach i czytnikach

2. Zagrożenia dla bezpieczeństwa i prywatności

HTML w poczcie niesie za to wiele zagrożeń dla odbiorcy:

  1. Phishing – czyli uzyskanie ważnych danych osobistych odbiorcy przez oszukańcze podsunięcie mu linka rzekomo prowadzącego do strony np. banku, a tak naprawdę do kopii wykonanej przez oszusta. Dzieje się to dzięki wykorzystaniu możliwości HTML, w której adres linka jest podany w znaczniku, a w klikalnej treści można podać dowolny tekst. Na przykład fragment kodu:

    kliknij na <a href="http://www.stronaoszusta.dom/www%2Embank%2Epl/login.cgi">http://www.mbank.pl/login.cgi</a> i potwierdź swoje dane wprowadzając nazwę użytkownika i hasło dające dostęp do twojego konta

    w formacie HTML będzie pokazany tak:

    kliknij na http://www.mbank.pl/login.cgi i potwierdź swoje dane wprowadzając nazwę użytkownika i hasło dające dostęp do twojego konta
    co jak widać wygląda bardzo przekonująco i wiele osób już dało się nabrać na ten prosty trick. W formacie tekstowym nie ma możliwości takiego ukrycia odsyłacza.
    Co ciekawe, dobre programy do obsługi poczty elektronicznej mogą zostać ustawione na wyświetlanie HTML jako czystego tekstu albo na wyświetlenie tylko niektórych, bezpiecznych znaczników. W takim programie, w którym wyłączono obsługę HTML, powyższy kod zostanie przedstawiony tak:

    kliknij na http://www.mbank.pl/login.cgi <http://www.stronaoszusta.dom/www.mbank.pl/login.cgi> i potwierdź swoje dane wprowadzając nazwę użytkownika i hasło dające dostęp do twojego konta
    co jak widać dobrze zabezpiecza przed oszustwem. Adresy powyżej są użyte tylko dla demonstracji i w rzeczywistości nie są klikalne.
  2. Potwierdzenie otwarcia listu. W treści można umieścić odsyłacz do obrazka o minimalnym rozmiarze (nawet dwubarwny GIF o rozmiarach 1×1 piksel), a w odsyłaczu odpowiedzialnym za załadowanie tego obrazka umieścić informację o odbiorcy, późniejsza analiza logów serwera pozwala na ustalenie, kto otworzył odebrany list. Metoda chętnie stosowana przez spamerów, dzięki niej spamerzy zaznaczają adresy jako aktywne, na które opłaca im się słać dużo więcej spamu. Przykładowy fragment kodu będzie wyglądał tak:
    <img src="http://serwer.spamera.com/login_ofiary_domena_adresu_ofiary.gif">
  3. Kod wykonywalny: HTML używany w poczcie poza niewielkimi zmianami jest całkowicie normalnym kodem HTML, pozwalającym m.in. na uruchamianie skryptów, appletów i obiektów, np. animacji Flash. Programy pocztowe wykorzystujące engine Internet Explorera do renderowania kodu HTML w treści poczty, na przykład Outlook Express, są szczególnie narażone dzięki obsłudze przez ten ostatni groźnych skryptów VisualBasic i kontrolek ActiveX. Konieczne jest ustawienie poziomu zabezpieczeń poczty na wysoki i regularne instalowanie poprawek bezpieczeństwa dla IE, nawet gdy korzysta się na co dzień z innej przeglądarki.

3. Inne niedogodności stosowania HTML w poczcie elektronicznej

HTML w poczcie jest też niedogodny z następujących względów:

  1. Wspomniane już zbędne zwiększenie objętości, szczególnie widoczne w przypadku krótkich listów. Każdy płaci za transfer, nawet jeżeli opłata nie jest jawnie podawana na fakturze, ale przecież dostawca internetu zakłada określony transfer na użytkownika i na tej podstawie wylicza swój ryczałt.
  2. Kod generowany przez wiele programów jest w mniejszym lub większym stopniu niezgodny ze standardem W3C, niektóre programy nie obsługują też niektórych standardowych elementów HTML, przez co wygląd listu na ekranie odbiorcy odbiega od zamierzonego efektu, a nawet może się zdarzyć, że odbiorca nie będzie w stanie odczytać całości treści.
  3. Choć ich udziałw internecie stale maleje, wciąż w użytku są programy pocztowe obsługujące tylko format tekstowy. Czytanie listów w HTML z użyciem takich programów jest wyjątkowo uciążliwe, wyławianie tekstu spośród znaczników HTML znacznie spowalnia czytanie i może pociagnąć za sobą przeoczenie jakiegoś (ważnego) fragmentu.

4. Do czego nie służy HTML w poczcie

Z wyżej wymienionych względów bezpieczeństwa, estetyki i ergonomii wiele osób ma całkowicie wyłączoną obsługę HTML w odbieranej poczcie. Na stronach poświeconych konfiguracji poszczególnych programów można znaleźć również instrukcję, jak wyłączyć w nich domyślne wysyłanie w HTML i jak w razie potrzeby móc wysłać list w HTML. Generalnie logiczny wniosek z powyższego to by używać HTML jedynie wtedy, gdy jest to uzasadnione i nie ma innej sensownej możliwości przekazania istotnych informacji. W sytuacji, gdy nie można dokładnie sprecyzować, dlaczego w danych warunkach został użyty HTML i jaka informacja ważna dla odbiorcy musiała zostać w ten sposób przekazana, użycie HTML jest/było nieuzasadnione. Należy również stosować się do preferencji odbiorcy – jeżeli nie chce lub nie życzy sobie otrzymywać HTML, nie należy mu się z tym narzucać, analogicznie należy uszanować zwyczaje panujące na grupie dyskusyjnej lub w hierarchii grup. Jeżeli nie można przesłać danej informacji w treści bez użycia HTML odbiorcy, który życzy sobie otrzymywać tylko zwykły tekst, dane materiały można umieścić na serwerze ftp, na darmowej stronie www, na serwerze wymiany plików typu rapidshare.de itp.

5. Ciekawostka historyczna: format enriched text – alternatywa dla HTML

Format enriched text (czyli tekst z podstawowym formatowaniem; typ MIME text/enriched) został zaprojektowany na początku lat 90. specjalnie z myślą o stosowaniu w poczcie. Jest on znacznie bardziej przyjazny dla internetu: nie wymaga nagłówka HTML, nie ma konieczności kodowania znaku większości oraz znaku & jako encji (znak mniejszości jest kodowany przez podwojenie, czyli <<), łamanie linii oznaczane jest podwójnym Enterem, a nie znacznikiem, generalnie formatowanie wymaga znacznie mniejszej ilości znaczników. Możliwości formatowania są znacznie węższe, niż w wypadku HTML, ale w 99% całkowicie wystarczające do normalnego formatowania listów: możliwy jest podział tekstu na akapity, wyrównanie, zaznaczenie fragmentu tekstu kolorem, wcięcia, definicja czcionki, zmiana wielkości tekstu (tylko względna: tekst mniejszy od normalnego albo większy od normalnego) itp. Brak znaczników migania (<blink>) i przewijania tekstu (<marquee>), brak możliwości umieszczania skryptów i zagnieżdżania animacji, dźwięku w tle oraz kontrolek AciveX, a także brak linków tekstowych (np. kliknij tu – bez możliwości zobaczenia w prosty sposób, dokąd dany link prowadzi) powoduje, że format wydaje się niepodatny na wykorzystanie go do denerwowania lub naruszenia prywatności odbiorcy. Zaletą programu jest też traktowanie pojedynczego Entera jako spacji, co już wtedy dawało te same możliwości, które dzisiaj daje format flowed. Niestety, żaden ze znanych mi programów nie potrafi wysyłać w tym formacie, a obsługa go w odebranych listach zawiera się między całkowitym brakiem obsługi a obsługą częściową. Do grupy cechującej się częściową obsługą należą m.in Pegasus, Mozilla Thunderbird i OE. Zgodnie z danymi dostępnymi w internecie jednym z bardzo nielicznych w miarę współczesnych programów cechujących sie obsługą tego formatu jest Apple Mail 1.x, jak sama nazwa wskazuje tylko na Maca. Pegasus potrafi zinterpretować wszystkie znaczniki formatowania, ale ma drobne problemy z niektórymi kolorami deklarowanymi słownie i nie reaguje na deklarację charsetu w nagłówku maila (co skutkuje krzakami), poza tym obsługuje tylko wyświetlanie, nie ma możliwości wysyłania w tym formacie. Obsługa przez Thunderbird jest z jednej strony lepsza, bo jako jedyny z tej grupy nie ma problemów z kodowaniem, a z drugiej jest bardziej ograniczona w porównaniu z Pegasusem (brak obsługi kolorowania, wcięć, wyrównywania do obu marginesów i paru innych znaczników, są one ignorowane zgodnie ze standardem). OE cechuje się podobnymi ograniczeniami, a dodatkowo jak Pegasus nie uwzględnia deklaracji strony kodowej, ponadto zobaczenie efektów formatowania jest uwarunkowane włączeniem wyświetlania treści w formacie HTML. Format ten nigdy nie zyskał sobie popularności i najprawdopodobniej jest obecnie faktycznie martwy. Z uwagi na brak popularności format ten nie był rozwijany i może w nim brakować pewnych opcji formatujących, mimo łatwości dodania ich. Rozpowszechnienie się i powszechna akceptacja HTML w poczcie powodują, że obecnie raczej nie ma zapotrzebowania na powrót do tego formatu. Więcej informacji: RFC 1896 link do str. zewnętrznej (najnowsza wersja z 1996 r.).

Uwaga: nie mylić tego formatu z formatem RTF (Rich Text Format), to są dwa zupełnie odmienne formaty.

                  _
                 / \
                |   |
                 \ /
                  X
                 / \
                /   \
               /     \

        ASCII Ribbon Campaign
   for HTML-free e-mail and usenet

licznik