HTML e-post - HTML email

HTML-e-post er bruken av et delsett av HTML for å gi formatering og semantiske markeringsfunksjoner i e-post som ikke er tilgjengelig med ren tekst : Tekst kan lenkes uten å vise en URL , eller bryte lange URL-er i flere deler. Tekst er pakket inn for å passe bredden på visningsvinduet, i stedet for å jevnlig bryte hver linje med 78 tegn (definert i RFC 5322, som var nødvendig på eldre tekstterminaler ). Det gjør det mulig å inkludere bilder, tabeller , i tillegg til diagrammer eller matematiske formler som bilder, som ellers er vanskelige å formidle (vanligvis ved bruk av ASCII-kunst ).

Adopsjon

De fleste grafiske e-postklienter støtter HTML-e-post, og mange er standard. Mange av disse klientene inkluderer både en GUI- editor for å komponere HTML-e-post og en gjengivelsesmotor for visning av mottatte HTML-e-post.

Siden oppfatningen har en rekke mennesker motsatt seg all HTML-e-post (og til og med MIME selv) av en rekke årsaker. For eksempel foreslo ASCII Ribbon Campaign at all e-post skulle sendes i ASCII- tekstformat. Kampanjen mislyktes og ble forlatt i 2013. Selv om den fremdeles ble ansett som upassende i mange nyhetsgruppeposteringer og adresselister, har adopsjonen av den for personlig og forretningspost bare økt over tid. Noen av dem som motsatte seg det da det først kom ut, ser det nå som mest ufarlig.

I følge undersøkelser fra online markedsføringsfirmaer er adopsjon av HTML-kompatible e-postklienter nå nesten universelle, med mindre enn 3% som rapporterer at de bruker kun tekstklienter. De fleste brukere foretrekker å motta HTML-e-post fremfor ren tekst.

Kompatibilitet

E-postprogramvare som samsvarer med RFC 2822 er bare nødvendig for å støtte ren tekst, ikke HTML-formatering. Å sende HTML-formaterte e-poster kan derfor føre til problemer hvis mottakerens e-postklient ikke støtter det. I verste fall vil mottakeren se HTML-koden i stedet for den tiltenkte meldingen.

Blant de e-postklientene som støtter HTML, gjengir noen det ikke i samsvar med W3C- spesifikasjonene, og mange HTML-e-postmeldinger er heller ikke kompatible, noe som kan forårsake gjengivelse eller leveringsproblemer.

Spesielt er ikke <head> taggen, som brukes til å huse CSS-stilregler for et helt HTML-dokument, ikke godt støttet, noen ganger strippet fullstendig, noe som fører til at in-line stilerklæringer er de facto- standarden , selv om in-line stilerklæringer er ineffektiv og unnlater å utnytte HTMLs evne til å skille stil fra innhold. Selv om løsninger er utviklet, har dette ikke forårsaket mangel på frustrasjon blant nyhetsbrevutviklere, som gyter grasrotprosjektet for e-poststandarder , som vurderer e-postklienter på deres gjengivelse av en syretest, inspirert av de fra Web Standards Project , og lobbyer utviklere for å forbedre produktene deres. For å overtale Google til å forbedre gjengivelse i Gmail , for eksempel, publiserte de en videomontasje av grimaserende webutviklere, noe som resulterte i oppmerksomhet fra en ansatt.

"E-poststandarder prosjektet" Acid test sammenligning (per januar 2013) [1]
Kunder Resultat (pr.)
AOL Webmail Solid støtte (13. juli 2011)
Apple iPhone Solid støtte (13. juli 2011)
Apple iPad
Apple iPod Touch
Apple Mail Solid støtte (28. november 2007)
Apple MobileMe Solid støtte (15. august 2008)
Eudora
Eudora OSE med kodenavnet "Penelope" 		Solid støtte (28. november 2007)
Microsoft Entourage Solid støtte (28. november 2007)
Mozilla Thunderbird Solid støtte (28. november 2007)
Windows Live Mail Solid støtte (28. november 2007)
Windows Mail Solid støtte (28. november 2007)
Yahoo! Mail Beta Solid støtte (8. juli 2011)
Windows Live Hotmail Noen forbedringer anbefales (8. juli 2011)
Google Gmail Forbedring anbefales (13. juli 2011)
Lotus Notes 8 Forbedring anbefales (28. november 2007)
Microsoft Outlook 2007 Forbedring anbefales (28. november 2007)

Stil

Noen avsendere kan i stor grad stole på store, fargerike eller distraherende skrifter , noe som gjør meldinger vanskeligere å lese. For de som spesielt er plaget av denne formateringen, gjør noen brukeragenter det mulig for leseren å delvis overstyre formateringen (for eksempel tillater Mozilla Thunderbird å angi en minimum skriftstørrelse); disse funksjonene er imidlertid ikke tilgjengelig globalt. Videre kan forskjellen i optisk utseende mellom avsender og leser bidra til å skille forfatteren av hver seksjon, noe som forbedrer lesbarheten.

Formater med flere deler

Mange e-postservere er konfigurert for automatisk å generere en tekstversjon av en melding og sende den sammen med HTML-versjonen, for å sikre at den kan leses selv av kun e-postklienter ved hjelp av , som spesifisert i RFC 1521. Meldingen selve er av typen , og inneholder to deler, den første av typen , som leses av kun tekstklienter, og den andre med , som leses av HTML-kompatible klienter. Klart tekstversjon kan imidlertid mangle viktig formateringsinformasjon. (For eksempel kan en matematisk ligning miste et overskrift og få en helt ny betydning.) Content-Type: multipart/alternativemultipart/alternativetext/plaintext/html

Mange adresselister blokkerer bevisst HTML-e-post, enten fjerner du HTML-delen for å bare forlate ren tekstdel eller avviser hele meldingen.

Delenes rekkefølge er betydelig. RFC1341 sier at: Generelt bør brukeragenter som komponerer flerdelt / alternative enheter plassere kroppsdelene i økende rekkefølge, det vil si med det foretrukne formatet sist. For e-post med flere deler med html- og ren tekstversjoner, betyr det å oppføre ren tekstversjon først og html-versjonen etter den, ellers kan klienten som standard vise standardtekstversjonen selv om en html-versjon er tilgjengelig.

Meldingsstørrelse

HTML-e-post er større enn ren tekst. Selv om ingen spesiell formatering brukes, vil det være overhead fra kodene som brukes i et minimalt HTML-dokument, og hvis formatering er mye brukt, kan det være mye høyere. Flerdelt meldinger, med duplikater av samme innhold i forskjellige formater, øker størrelsen ytterligere. Seksjonen med ren tekst i en flerdelt melding kan hentes av seg selv ved å bruke IMAPs FETCH-kommando.

Selv om forskjellen i nedlastingstid mellom vanlig tekst og blandet e-post (som kan være en faktor på ti eller mer) var bekymringsfullt på 1990-tallet (da de fleste brukere hadde tilgang til e-postservere gjennom sakte modemer ), er forskjellen på en moderne forbindelse ubetydelig for folk flest, spesielt når de sammenlignes med bilder, musikkfiler eller andre vanlige vedlegg.

Sikkerhetsproblemer

HTML tillater at en lenke vises som vilkårlig tekst, slik at en lenke i stedet for å vise hele URL-en kan vise bare en del av den eller bare et brukervennlig målnavn. Dette kan brukes i phishing- angrep, der brukere blir lurt til å tro at en lenke peker til nettstedet til en autoritativ kilde (for eksempel en bank), besøker den og utilsiktet avslører personlige detaljer (som bankkontonumre) til en svindler .

Hvis en e-post inneholder nettfeil (innebygd innhold fra en ekstern server, for eksempel et bilde ), kan serveren varsle en tredjepart om at e-posten er åpnet. Dette er en potensiell personvernrisiko , som avslører at en e-postadresse er reell (slik at den kan målrettes i fremtiden) og avslører når meldingen ble lest.

HTML-innhold krever e-postprogrammer for å bruke motorer til å analysere, gjengi og vise dokumentet. Dette kan føre til flere sikkerhetsproblemer, tjenestenekt eller dårlig ytelse på eldre datamaskiner.

I perioder med økte nettverkstrusler konverterer det amerikanske forsvarsdepartementet all innkommende HTML-e-post til tekst-e-post.

Multipart-typen er ment å vise det samme innholdet på forskjellige måter, men dette misbrukes noen ganger; noen e-post-spam utnytter formatet for å lure spam-filtre til å tro at meldingen er legitim. De gjør dette ved å inkludere uskadelig innhold i tekstdelen av meldingen og plassere spam i HTML-delen (det som vises for brukeren).

Mest e-post spam sendes i HTML av disse grunnene, så spamfiltre gir noen ganger høyere spam score til HTML-meldinger.

I 2018 ble EFAIL avduket, et alvorlig sårbarhet som kunne avsløre det faktiske innholdet i krypterte HTML-e-post til en angriper.

Se også

Referanser