Czy cytowany wydruk jest wystarczający, aby poczta była zgodna z ograniczeniem długości linii określonym w RFC 2822?

W RFC 2822 (definiowanie wiadomości e-mail) zdefiniowano, że żadna linia NIE POWINNA być dłuższa niż 78 znaków (bez CRLF) i MUSI nie być dłuższa niż 998 znaków. Przy drukowaniu cytowanym dłuższe linie zostaną podzielone na więcej linii, kończąc każdą na „=”, aż do osiągnięcia rzeczywistego podziału linii. Zgodny z pocztą standard, jeśli zawiera wiersze dłuższe niż 78 (lub 998) znaków, ale jest zakodowany w drukowanym cudzysłowie?

Istnieją argumenty, że nie jest to zgodne, ponieważ klient poczty odbierający ma dłuższe linie po odkodowaniu wiadomości do wydrukowania w cudzysłowie.

EDYCJA : Aby wyjaśnić pytanie w sposób zadany przez Davida Cary'ego: Tak, mam na myśli, że zakodowana poczta do wydrukowania w cudzysłowie powinna być kompatybilna z drukowanymi w cudzysłowie, co oznacza, że ​​linie nie mają więcej niż 76 znaków. Ale zdekodowane wiadomości mogą mieć dłuższe linie niż ten limit. Więc moje pytanie brzmi: czy oprogramowanie klienckie implementujące RFC 1521 powinno obsługiwać nieskończenie długie linie po zdekodowaniu treści tekstowej do wydrukowania? Odpowiedź brzmi „tak” przy obu dotychczasowych odpowiedziach (dzięki) z zastrzeżeniem, że Netiquette odradza to (RFC 1855). Ale netykieta ogranicza nawet długość linii do 65 znaków, czyli limit, którego prawie nikt nie przestrzega.

Nie jestem pewien, o co pytasz:

odbierający klient poczty znajduje długie linie przed dekodowaniem do wydrukowania

Powiedz, że oprogramowanie do kodowania z zacytowanym drukiem na końcu nadawczym po prostu zacytowało litery niedrukowalne, dzięki czemu wynikowa zakodowana linia jest dłuższa niż linia oryginalna, bez dodawania „miękkich podziałów linii”, co powoduje, że zakodowana linia jest dłuższa niż limit.

Jest to niezgodne.

Wiersze zakodowanych danych do wydrukowania nie mogą być dłuższe niż 76 znaków. Aby spełnić ten wymóg bez zmiany zakodowanego tekstu, można dodać podział miękkich linii ... Te podziałki miękkich linii umożliwiają także kodowanie tekstu bez podziałów linii (lub zawierających bardzo długie linie) w środowisku, w którym rozmiar linii jest ograniczony, np. „ Limit 1000 znaków w wierszu ”niektórych programów SMTP, zgodnie z RFC 2821.

- Wikipedia: cytat do druku , parafrazowanie RFC2045 strona 21.

zakodowane linie są krótkie, ale klient poczty odbierającej znajduje długie linie po dekodowaniu do wydrukowania w cudzysłowie

Jest to zgodne z RFC2822 i RFC2045 i powinno być obsługiwane przez wszystkie programy.

Jednak tworzenia takich komunikatów odradza kilka Wytycznych netykiety, w tym Strona 3 z RFC 1855 „Wytyczne netykiety”.

Jest zdecydowanie zgodny. Chodzi o to, aby wydrukować w formie wyceny oraz pozostałe serie RFC serii MIME (od RFC 2045 do RFC 2049), aby umożliwić kodowanie danych, które w innym przypadku nie byłyby ważne w wiadomości e-mail. RFC 2822 wyraźnie (i wielokrotnie!) Wskazuje czytelnikom na te RFC, aby uzyskać informacje, jak to zrobić.

Jeśli naprawdę chcesz wiedzieć, jak skomplikowane jest zbudowanie zgodnego kompozytora i analizatora składni wiadomości e-mail, musisz obejrzeć ten film na Youtube: http://www.youtube.com/watch?v=JENdgiAPD6c

Ricardo Signes przedstawia wewnętrzne poglądy na temat różnych RFC i jaką głupotę wnoszą do prawdziwego życia.

Ma 40 minut i rysuje tylko powierzchnię złych i dobrych „treści” e-mail. Po obejrzeniu zmienisz zdanie na temat oprogramowania e-mail, które uważasz za zgodne ze standardami e-mail.