E-mail HTML - HTML email

E-mailul HTML este utilizarea unui subset de HTML pentru a oferi capacități de formatare și marcare semantică în e-mail care nu sunt disponibile cu text simplu : Textul poate fi legat fără a afișa o adresă URL sau a diviza adresele URL lungi în mai multe bucăți. Textul este înfășurat pentru a se potrivi lățimii ferestrei de vizionare, mai degrabă decât a rupe uniform fiecare linie la 78 de caractere (definit în RFC 5322, care era necesar pe terminalele de text mai vechi ). Permite includerea în linie de imagini, tabele , precum și diagrame sau formule matematice ca imagini, care sunt altfel dificil de transmis (de obicei folosind arta ASCII ).

Adopţie

Majoritatea clienților grafici de e-mail acceptă e-mailurile HTML, iar mulți sunt în mod implicit. Mulți dintre acești clienți includ atât un editor GUI pentru compunerea e-mailurilor HTML, cât și un motor de redare pentru afișarea e-mailurilor HTML primite.

De la concepția sa, o serie de oameni s-au opus vocal tuturor e-mailurilor HTML (și chiar MIME-ului în sine), din mai multe motive. De exemplu, ASCII Ribbon Campaign a susținut că toate e-mailurile trebuie trimise în format text ASCII . Campania nu a avut succes și a fost abandonată în 2013. Deși este considerată încă necorespunzătoare în multe postări de grupuri de știri și liste de corespondență, adoptarea acesteia pentru mesaje personale și de afaceri a crescut doar în timp. Unii dintre cei care s-au opus puternic atunci când a apărut pentru prima dată, îl văd ca fiind în mare parte inofensiv.

Potrivit sondajelor realizate de companiile de marketing online , adoptarea clienților de e-mail compatibili cu HTML este acum aproape universală, mai puțin de 3% raportând că utilizează clienți numai text. Majoritatea utilizatorilor preferă să primească e-mailuri HTML peste text simplu.

Compatibilitate

Software-ul de e-mail care respectă RFC 2822 este necesar doar pentru a accepta text simplu, nu formatarea HTML. Prin urmare, trimiterea de e-mailuri formatate HTML poate duce la probleme dacă clientul de e-mail al destinatarului nu îl acceptă. În cel mai rău caz, destinatarul va vedea codul HTML în loc de mesajul dorit.

Printre acei clienți de e-mail care acceptă HTML, unii nu o redă în mod consecvent cu specificațiile W3C și nici multe e-mailuri HTML nu sunt conforme, ceea ce poate cauza probleme de redare sau de livrare.

În special, <head> eticheta, care este utilizată pentru a găzdui reguli de stil CSS pentru un întreg document HTML, nu este bine acceptată, uneori dezbrăcată în întregime, ceea ce face ca declarațiile de stil în linie să fie standardul de facto , chiar dacă declarațiile de stil în linie sunt ineficient și nu reușesc să profite la maximum de capacitatea HTML de a separa stilul de conținut. Deși soluțiile de rezolvare au fost dezvoltate, acest lucru nu a provocat lipsă de frustrare în rândul dezvoltatorilor de buletine informative, generând proiectul de standarde de e-mail de bază , care clasifică clienții prin e-mail în ceea ce privește efectuarea unui test acid, inspirat de cele ale proiectului de standarde web , iar lobby-urile dezvoltatorilor trebuie îmbunătățite. produsele lor. Pentru a convinge Google să îmbunătățească redarea în Gmail , de exemplu, au publicat un montaj video de dezvoltatori web care se grimasă, rezultând în atenția unui angajat.

„Proiectul standardelor de e-mail” Compararea testului acidului (începând din ianuarie 2013) [1]
Clienți Rezultat (începând cu)
AOL Webmail Suport solid (13 iulie 2011)
Apple iPhone Suport solid (13 iulie 2011)
Apple iPad
Apple iPod Touch
Apple Mail Sprijin solid (28 noiembrie 2007)
Apple MobileMe Suport solid (15 august 2008)
Eudora
Eudora OSE cu numele de cod „Penelope” 		Sprijin solid (28 noiembrie 2007)
Microsoft Entourage Sprijin solid (28 noiembrie 2007)
Mozilla Thunderbird Sprijin solid (28 noiembrie 2007)
Windows Live Mail Sprijin solid (28 noiembrie 2007)
Windows Mail Sprijin solid (28 noiembrie 2007)
Yahoo! Mail Beta Suport solid (8 iulie 2011)
Windows Live Hotmail Se recomandă unele îmbunătățiri (8 iulie 2011)
Google Gmail Îmbunătățire recomandată (13 iulie 2011)
Lotus Notes 8 Îmbunătățire recomandată (28 noiembrie 2007)
Microsoft Outlook 2007 Îmbunătățire recomandată (28 noiembrie 2007)

Stil

Unii expeditori se pot baza excesiv pe fonturi mari, colorate sau distractive , ceea ce face ca mesajele să fie mai greu de citit. Pentru cei deranjați în mod special de această formatare, unii agenți de utilizator permit cititorului să suprascrie parțial formatarea (de exemplu, Mozilla Thunderbird permite specificarea unei dimensiuni minime a fontului); cu toate acestea, aceste capacități nu sunt disponibile la nivel global. Mai mult, diferența de aspect optic dintre expeditor și cititor poate ajuta la diferențierea autorului fiecărei secțiuni, îmbunătățind lizibilitatea.

Formate cu mai multe părți

Multe servere de e-mail sunt configurate pentru a genera automat o versiune text simplă a unui mesaj și a-l trimite împreună cu versiunea HTML, pentru a se asigura că acesta poate fi citit chiar și de clienții de e - mail numai text , utilizând , așa cum se specifică în RFC 1521. Mesajul el însuși este de tip și conține două părți, prima de tip , care este citită de clienți numai text și a doua cu , care este citită de clienți compatibili cu HTML. Cu toate acestea, în versiunea text simplu pot lipsi informații importante de formatare. (De exemplu, o ecuație matematică poate pierde un indicativ și poate lua un sens complet nou.) Content-Type: multipart/alternativemultipart/alternativetext/plaintext/html

Multe liste de corespondență blochează în mod deliberat e-mailurile HTML, fie eliminând partea HTML pentru a părăsi doar partea simplă, fie respingând întregul mesaj.

Ordinea pieselor este semnificativă. RFC1341 afirmă că: În general, agenții de utilizator care compun entități multiple / alternative ar trebui să plaseze părțile corpului în ordinea crescândă a preferințelor, adică cu formatul preferat ultima. Pentru e-mailurile cu mai multe părți cu versiuni html și text simplu, aceasta înseamnă listarea versiunii text simplu mai întâi și a versiunii html după aceasta, altfel clientul poate afișa implicit versiunea text simplu, chiar dacă este disponibilă o versiune html.

Dimensiunea mesajului

E-mailul HTML este mai mare decât textul simplu. Chiar dacă nu se folosește o formatare specială, va exista cheltuielile generale de pe etichetele utilizate într-un document HTML minim și, dacă formatarea este intens utilizată, aceasta poate fi mult mai mare. Mesajele cu mai multe părți, cu copii duplicate ale aceluiași conținut în diferite formate, măresc și mai mult dimensiunea. Secțiunea de text simplu a unui mesaj cu mai multe părți poate fi recuperată singură, totuși, utilizând comanda FETCH a IMAP .

Deși diferența de timp de descărcare între text simplu și mesaje de mesaje mixte (care poate fi un factor de zece sau mai mult) a fost îngrijorătoare în anii 1990 (când majoritatea utilizatorilor accesau servere de e-mail prin modemuri lente ), la o conexiune modernă diferența este neglijabil pentru majoritatea oamenilor, mai ales în comparație cu imagini, fișiere muzicale sau alte atașamente obișnuite.

Vulnerabilități de securitate

HTML permite afișarea unui link ca text arbitrar, astfel încât, mai degrabă decât afișarea adresei URL complete, un link poate afișa doar o parte din acesta sau pur și simplu un nume țintă ușor de utilizat. Acest lucru poate fi folosit în atacurile de phishing , în care utilizatorii sunt păcăliți să creadă că un link indică site-ul web al unei surse autorizate (cum ar fi o bancă), vizitând-l și dezvăluind neintenționat detalii personale (cum ar fi numerele de cont bancar) către un escroc .

Dacă un e-mail conține erori web (conținut în linie de pe un server extern, cum ar fi o imagine ), serverul poate avertiza o terță parte că e-mailul a fost deschis. Acesta este un risc potențial de confidențialitate , dezvăluind faptul că o adresă de e-mail este reală (astfel încât să poată fi vizată în viitor) și dezvăluie când a fost citit mesajul.

Conținutul HTML necesită programe de e-mail pentru a utiliza motoare pentru a analiza, reda și afișa documentul. Acest lucru poate duce la mai multe vulnerabilități de securitate, refuzul de serviciu sau performanță scăzută pe computerele mai vechi.

În perioadele de amenințări crescute ale rețelei, Departamentul Apărării din SUA convertește toate e-mailurile HTML primite în e-mailuri text.

Tipul multipart este destinat să arate același conținut în moduri diferite, dar acesta este uneori abuzat; unele spam-uri de e-mail profită de format pentru a păcăli filtrele de spam în a crede că mesajul este legitim. Acestea fac acest lucru incluzând conținut inofensiv în partea de text a mesajului și plasând spamul în partea HTML (cea care este afișată utilizatorului).

Majoritatea mesajelor spam de e-mail sunt trimise în HTML din aceste motive, astfel încât filtrele de spam oferă uneori scoruri mai mari de mesaje HTML.

În 2018 a fost dezvăluit EFAIL , o vulnerabilitate severă care ar putea dezvălui conținutul real al e-mailurilor HTML criptate unui atacator.

Vezi si

Referințe