Jaki jest limit długości tematu wiadomości e-mail?

227

Ile znaków może znajdować się w temacie e-maila internetowego? Miałem skan RFC do wiadomości e-mail, ale nie widziałem dokładnie, jak długo może to trwać. Mam kolegę, który chce programowo sprawdzić to.

Jeśli nie ma formalnego limitu, co w praktyce sugerować dobrą długość?

email limit

— Scott Ferguson
źródło

17

255 jest limitem dla niektórych produktów biletowych (na przykład Jira) i wydaje się być limitem dla perspektyw, thunderbird i gmail wydają się obcinać po 130.

— recbot 12.01.11

1

RFC2047 lepiej nadaje się do sprawdzania poprawności, widzę mnóstwo oprogramowania do masowej wysyłki, które produkuje nieprawidłowe treści RFC2047.

— Jasen

3

W bazach danych bardzo często (tradycję można powiedzieć) definiowanie długości niezbyt długich lub krótkich pól tekstowych jako VARCHAR (255) lub podobnych równoważnych nazw. Jeśli zostanie przedstawiony dłuższy ciąg, wygeneruje błąd lub po prostu zostanie obcięty do limitu. Dlatego Jira i Outlook, jak wspomniano tutaj, nie obsługują więcej znaków. Ze względu na kompatybilność nie poleciłbym 255+ Dodanie kremu do 5-letniego ciasta;)

— Alph.Dev

195

Aby rozpocząć, patrz RFC 2822 , sekcja 2.1.1.

Istnieją dwa ograniczenia, które ten standard nakłada na liczbę znaków w linii. Każda linia znaków MUSI mieć nie więcej niż 998 znaków i MUSI mieć nie więcej niż 78 znaków, z wyłączeniem CRLF.

Jak później stwierdza RFC, możesz obejść ten limit (nie że powinieneś), składając obiekt na wiele linii.

Każde pole nagłówka jest logicznie pojedynczym wierszem znaków zawierającym nazwę pola, dwukropek i treść pola. Jednak dla wygody i w celu ograniczenia liczby znaków 998/78 na linię część pola pola nagłówka może być podzielona na reprezentację wielu linii; nazywa się to „składaniem”. Ogólna zasada jest taka, że wszędzie tam, gdzie ten standard zezwala na składanie białych znaków (nie tylko znaków WSP), przed dowolnym WSP można wstawić CRLF. Na przykład pole nagłówka:
       Subject: This is a test
może być reprezentowany jako:
       Subject: This
        is a test

Zalecenia dotyczące nie więcej niż 78 znaków w nagłówku tematu brzmią rozsądnie. Nikt nie chce przewijać, aby zobaczyć cały wiersz tematu, a po prawej stronie może zostać odcięte coś ważnego.

— Michael Petrotta
źródło

8

Aktualna wersja specyfikacji MFW, RFC 5322, można znaleźć tutaj: tools.ietf.org/html/rfc5322#section-2.1.1

— james.garriss

6

Ta odpowiedź dotyczy tylko limitu długości linii, a nie ogólnego limitu długości.

— Chalky,

1

Istnieje RFC i użyteczność. Artykuł Jakoba Nielsena Linie tematyczne wiadomości e-mail: 5 wskazówek, które przyciągają czytelników, podsumowują: „Skoncentruj się na pierwszych 40 znakach. Opisowe i dobrze napisane wiersze tematyczne pozwalają odbiorcom podjąć świadomą decyzję, aby uzyskać więcej szczegółów lub przejść dalej”.

— Édouard Lopez

3

Aby to wyjaśnić, nie ma limitu długości dla wierszy tematu, ponieważ standardy zezwalają na nagłówki dłuższe niż 998 bajtów poprzez zawijanie jednego nagłówka na tyle wierszy, ile chcesz. Rekomendacja ~ 80 znaków jest rzeczywiście rozsądna. Jeśli piszesz klienta poczty e-mail, musisz być w stanie poradzić sobie z absurdalnie długimi tematami, nie psując się w okropny sposób, najlepiej przez obcięcie podczas wyświetlania jako części listy.

— thomasrutter

1

... Tak też byłoby w przypadku każdego innego pola nagłówka (np. „From”). PS, jeśli zastanawiasz się, dlaczego 78 zamiast 80 lub dlaczego 998 zamiast 1000, to dlatego, że standard e-mail określa CRLF (\ r \ n) jako separator, czyli dwa bajty, co daje 1000 bajtów na wiersz, z czego 998 to sam nagłówek. Zauważ też, że nazwa nagłówka i dowolna spacja po dwukropku, np. „Temat:” również muszą się do tego zmieścić.

— thomasrutter

20

RFC2322 stwierdza, że nagłówek tematu „nie ma ograniczenia długości”

ale aby utworzyć długie nagłówki, ale musisz podzielić je na wiele linii, proces zwany „składaniem”.

podmiot jest zdefiniowany jako „nieustrukturyzowany” w RFC 5322

oto kilka cytatów ([...] wskazuje rzeczy, które pominąłem)

3.6.5. Informational Fields
  The informational fields are all optional.  The "Subject:" and
  "Comments:" fields are unstructured fields as defined in section
  2.2.1, [...]

2.2.1. Unstructured Header Field Bodies
  Some field bodies in this specification are defined simply as
  "unstructured" (which is specified in section 3.2.5 as any printable
  US-ASCII characters plus white space characters) with no further
  restrictions.  These are referred to as unstructured field bodies.
  Semantically, unstructured field bodies are simply to be treated as a
  single line of characters with no further processing (except for
  "folding" and "unfolding" as described in section 2.2.3).

2.2.3  [...]  An unfolded header field has no length restriction and
  therefore may be indeterminately long.

— Jasen
źródło

@jasen Czy znasz narzędzie do składania?

— mahdi,

zrobi to każda dobrze napisana biblioteka e-mail. moim ulubionym jestc-client

— Jasen

To jest poprawna odpowiedź. Druga część pytania „dobra długość w praktyce” całkowicie zależy od Twojej aplikacji. Jeśli zapisujesz otrzymane wiadomości e-mail, musisz obsługiwać nieograniczoną długość.

— Rob

4

po pewnym teście: jeśli wyślesz wiadomość e-mail do klienta programu Outlook, a temat ma> 77 znaków, i musi on zostać użyty "=?ISO"w temacie (w moim przypadku z powodu akcentów), wówczas OutLook „wycina” temat w środku i siatki to wszystko, co nastąpi później, w tym tekst, załączniki itp. ... wszystko siatka!

Mam kilka takich przykładów:

Subject: =?ISO-8859-1?Q?Actas de la obra N=BA.20100154 (Expediente N=BA.20100182) "NUEVA RED FERROVIARIA.=

TRAMO=20BEASAIN=20OESTE(Pedido=20PC10/00123-125),=20BEASAIN".?=

Do:

Jak widać, w wierszu tematu wycięto znak char 78 ze znakiem „=”, a następnie 2 lub 3 wiersze, a następnie kontynuowano z resztą tematu źle.

Zgłoszono mi to od kilku klientów, którzy korzystali z OutLook, inni klienci poczty e-mail dobrze sobie z nimi radzą.

Jeśli nie masz na nim ISO, to nie zaszkodzi, ale jeśli dodasz go do swojego przedmiotu, aby był miły dla RFC, otrzymasz niespodziankę od OutLook. Bit, jeśli nie dodasz ISO, wtedy iPhone nie zrozumie go (a załączanie plików o nazwach przy użyciu takich znaków nie będzie działać na iPhone'ach).

— Sergio
źródło

5

Istnieje wiele problemów z ustawionym przedmiotem: 1. Spacje powinny być kodowane za pomocą „_”, 2. „Słowo zakodowane” (=? Charset? Q / B? Data? =) Nie może mieć więcej niż 75 znaków (rfc2047). 3. Nie można uciec nowej linii za pomocą znaku „=” na końcu linii (kodowanie QP nagłówka jest inne niż QP treści). Podsumowując: nie jest to wina Outlooka.

— Paweł Lesnikowski

2

Nie wierzę, że istnieje tutaj formalny limit i jestem prawie pewien, że nie ma żadnego sztywnego limitu określonego w RFC, jak odkryłeś.

Myślę, że niektóre dość powszechne ograniczenia dla tematów w ogóle (nie tylko e-mail) to:

80 znaków
128 znaków
256 znaków

Oczywiście chcesz wymyślić coś rozsądnego. Jeśli piszesz klienta poczty e-mail, możesz użyć czegoś takiego jak 256 znaków i oczywiście dokładnie przetestować na dużych serwerach komercyjnych, aby upewnić się, że prawidłowo obsługują twoją pocztę.

Mam nadzieję że to pomoże!

— Ed Altorfer
źródło

13

Nie ma szczególnego powodu, dla którego 256 jest lepsze niż 250, 300 lub 372. Już dawno używamy bajtów dla długości łańcucha.

— Greg Hewgill,

4

255 to faktyczny limit niektórych produktów (na przykład Jira i perspektywy)

— Rebbot

5

Ta odpowiedź jest zła. RFC 5322, aktualna wersja specyfikacji MFW, wyraźnie określa maksymalną długość linii. Zobacz odpowiedź @ Michaela.

— james.garriss

2

+1 Ograniczenie długości linii dotyczy wszystkich wierszy wiadomości, ale nie widzę nic, co mówi, że nie możesz mieć tematu obejmującego wiele linii (co nie oznacza ograniczenia liczby znaków dla tematu). Patrz 2.2.3 i przykład, który następuje bezpośrednio potem.

— Cypher

1

VARCHAR 255 jest prawdopodobnie najczęstszą (i bardziej wydajną) długością kolumny danych w MySQL / MariaDB. Bajty są z pewnością nadal aktualne. MySQL użyje 1 bajtu do przechowywania długości, jeśli jest ona mniejsza niż 256 lub w inny sposób większa. Spójrz, jak C ++ implementuje std :: string, jeśli uważasz, że długości łańcucha nie są bardzo ważne i są liczone w bajtach.

— ebyrob,

0

Ważne jest, którego mechanizmu używasz do wysyłania wiadomości e-mail. Większość współczesnych bibliotek (tj. System.Net.Mail) ukryje przed Tobą składanie. Po prostu wstawiłeś bardzo długi temat wiadomości e-mail bez (CR, LF, HTAB). Jeśli zaczniesz próbować samodzielnie spasować, wszystkie zakłady są wyłączone. Rozpocznie się zgłaszanie błędów. Więc jeśli masz ten problem, po prostu odfiltruj CR, LF, HTAB i pozwól bibliotece wykonać pracę za Ciebie. Zazwyczaj można również ustawić typ tekstu kodowania jako osobne pole. Nie ma potrzeby kodowania ISO w wierszu tematu.

— kariato
źródło