er det en mailliste du har kan du eventuel bede modtagerne vælge om de vil have emailen som tekst eller som HTML. Jeg har personligt intet imod at modtage HTML-emails. Fordelen er jo at du kan sætte det lækkert op i stedet for at det bare er kedelig tekst.
halifax--> Kan folk lave ondsindet kode som uopdaget udfører diverse ondsindede handlinger? Hvis bare man sørger for ordentligt sikkerhedsniveau i browseren må den slags vel kunne stoppes? Jeg har i hvert fald aldrig (så vidt jeg ved) oplevet ondsindet kode, der ødelagde noget for mig.. man hører ganske vist om mange onde tilfælde, men så vidt jeg har forstået er der altid tale om naive modtagere der siger ja til at downloade og åbne ukendte filer..
..og så er der jo størrelsen på din email... den er klart mindre når der ikke følger en masse HTML-tags med... men om man sender emails på 5 eller 20 kb er efter min mening ligegyldigt.. det vigtige er at man sørge for ordentlig behandling af evt. billeder. Modtog engang en mail fra en mailliste, hvor billederne tilsammen fyldte 1,2 MB... det var ikke særlig smart.. ;-)
Synes godt om
Slettet bruger
26. juli 2004 - 15:40#5
Ved HTML formatering; i bedste fald bliver formateringen ignoreret, i værste fald gør mailen :)
Det er helt klart langt hen af vejen et spørgsmål om hvad formålet med e-mailen er. En hel del mennesker vil foretrække at få e-mail i ren tekst, da de desværre har oplevet alt for mange uheldige situationer med HTML baserede e-mails, der ikke ser ud som de skal og indeholder ondsindede intentioner (spam, ulovlig tracking osv).
En ofte lige så stor del mennesker er fløjtende ligeglade med den slags og vil helst have en e-mail der præsenterer sig pænt, indeholder billeder og layout og er overskuelig at læse i deres standardopsætning af deres MUA (Mail User Agent). Det er ofte nemmest at gøre med HTML med vore dages MUA'er.
At disse to folkefærd er vidt forskellige persontyper er der vist ingen tvivl om. Derfor handler det hele vejen igennem om "målgruppe".
Hvis man ikke vil vælge det ene frem for det andet, så er det lige så anbefalelsesværdigt at udsende e-mailen som multipart, med både en tekst og en html udgave. Derefter er det op til brugeren selv at vælge. Nogle vil i dette tilfælde så klage over ekstra forsendelse af data, men da e-mails ofte er kortere beskeder end komplette romaner er mængden af bytes der skal sendes ekstra for at opnå større brugervenlighed yderst begrænset. Det er i hvert tilfælde resultatet af de undersøgelser vi har foretaget i forbindelse med opbygningen af vores nyhedsbrevsservice "eBrev".
De umidelbare klare fordele med tekst er som nævnt, mindre data og mindre risiko for at spamfiltre og virusfiltre går amok på e-mailen. Spørgsmålet er så hvad de klare ulemper er ved rene tekstmails, hvilket afhænger af formålet
halifax> html til mail er som sådan ikke noget "der er skabt". Det er bare en naturlig model for at formatere et dokument, der er "flyttet over på mailprotokollen". HTML e-mails er for det meste simple multipart forsendelser. Hvorvidt den part, der indeholder html, kan læses og udnyttes afhænger af klienten der fortolker den og har egentlig ikke noget med mail-teknologi at gøre.
Sat helt på spidsen så kan tekst forsendelser sagtens indeholde ondsindet kode. Det afhænger udelukkende af hvordan MUA'en håndterer og parser e-mail'en.
avlund>
> "Du sikrer dig, at alle er i stand til at læse din mail korrekt."
Det er ikke en garanti. Der kan være bunker af problemer med tegnsæt, encodning osv. Det er lidt mere komplekst end bare det.
> "Og at den ikke fylder mere end højst nødvendigt."
Det må siges at være en subjektiv vurdering der ikke kan påføres som et fakta. En HTML/tekst multipart e-mail fylder heller ikke mere end højest nødvendig. Det afhænger helt af hvad der er nødvendigt ;)
pacr00n> "Ved HTML formatering; i bedste fald bliver formateringen ignoreret, i værste fald gør mailen :)"
Taler du her om dit eget personlig setup, eller forsøger du at henvise til et generelt MUA setup? Det er fint muligt at HTML formatere en e-mail der bliver vist ganske pænt i størstedelen af udbredte MUA'er i deres standard indstilling.
rune.osterdal.com> "den er klart mindre når der ikke følger en masse HTML-tags med."
Ikke nødvendigvis. Hvis jeg vil lave en tydelig adskillelseslinie imellem to afsnit i en tekst e-mail kan jeg benytte:
hvis man benytter sig af ASCII, skulle det kunne være muligt at klart størstedelen af modtagerne er i stand til at se mailen som den skulle opleves. Vi kan da forhåbentligt blive enige om at sandsynligheden for at modtagerne har valgt HTML fra og/eller bruger en klient som ikke understøtter det helt efter bogen, samt at HTML'en i mailen er fejlbehæftet, er større end at en ASCII-mail bliver ulæselig.
Hvad dit <hr>-eksempel angår, så er jeg særdeles tilbøjelig til at mene at dette er et enestående tilfælde. Der er sikkert flere situationer hvor en HTML-løsning er mere pladsbesparende, men igen er der nok hundrede gange så mange hvor det modsatte er tilfældet. Det er nemlig tit sådan, at folk lige pludselig får travlt med at sætte en masse lir på når de har HTML til rådighed, og så har vi balladen.
Så selv om dine punkter teoretisk set er valide, frygter jeg at situationen er en anden når vi ser på det i den virkelige verden. Med al respekt.
avlund> Mine kommentarer er baseret på, at en sandhed ikke er mere end sandhed end at der formodentlig findes undtagelser. Det var disse jeg gjorde opmærksom på. Det skyldes formodentlig at jeg ikke bryder mig specielt meget om "endegyldigde sandheder", der egentlig ikke er det.
Det samme gælder skrønen om, at hvis man laver sin websites efter w3c's anbefalinger så er den hellige grav velforvaret. ;)
"Det er nemlig tit sådan, at folk lige pludselig får travlt med at sætte en masse lir på når de har HTML til rådighed, og så har vi balladen."
Jeg er ganske enig i, at teknologien kan misbruges, men jeg prøver at indtage den holdning at ikke alle er komplette idioter, som udgangspunkt. Nogle er måske uvidende, men det er bare et spørgsmål om at hjælpe hinanden med at lære i stedet for at begrænse mulighederne, med halvsande postulater. :)
Et andet byte eksempel vil være at de fleste rene tekstbaserede e-mail ofte er layoutet ved hjælp af gentagende mellemrumstegn flere steder (ved f.eks lister, tabulær data m.v.). Med en ordentlig html fortolker i en MUA ville man kunne spare en pæn del af dem i samarbejde mellem html og CSS. Det er dog igen "teori" om du vil (jeg har nu dog benyttet det i praksis fra tid til anden).
Pointen er såmænd bare, at alting ikke er så sort på hvidt, og medmindre der ligger fakta bag "at folk _altid_ putter lir på når det er html", så er det vel en temmelig subjektiv indgangsvinkel til problematikken. ;)
Derfor tillod jeg mig at kommentere postulatet om at det er en fordel ved rene tekst e-mails, hvilket jeg ikke mener det er. Medmindre man kender flere faktorer, som f.eks e-mailens udforming, målgruppen, udsendelsesmetode osv., så er det forholdsvist vanskeligt at udlede (IMHO) noget brugbart og en endelig sandhed, som man bør ligge til grund for produktionssystemer.
Det var da noget af en debat, tak for dén. Jeg kan se det med målgrupper og formål, måske burde jeg have været mere konkret.
Nogen bruger html mail til alskens smagløst junk i lange baner, men her mener jeg at mailideen bliver ødelagt fordi en mail efter min mening bør være kort præcist og meningsfyldt. Ingen har tid til andet.
For mit vekommende er ideen med at bruge HTML mail, at man i det mindste kan lave en signatur der ser fornuftig ud, og der er mulighed for at indsætte et lille billed til information når der er brug for det. Og det er jo rigtig nok, at selvom det fylder lidt mere er det uden betydning. Jeg bilder mig også ind, at designet betyder noget for alle mennesker og at en "smagfuld" skrivelse vækker mere troværdighed end det en tekstmail kan tilbyde.
Med mit spørgsmål mente jeg om der ER nogen sikkerhedsrisiko ved bruge HTML i stedet for tekst ???, for hvis der ikke er det, er der vel ingen mening i at bruge tekst.
Hvis disse betragtninger holder er det vel rune.osterdal og osaka san der skal deles om pointene?
Som udgangspunkt er den primære sikkerhedsrisiko for afsenderen ved at bruge HTML formaterede e-mails, at nogle modtagere ganske enkelt afviser HTML baserede e-mails. De kan også risikere at blive fanget i spamfiltre, der kan være forholdsvis strikse. Det er dog ikke et problem jeg har oplevet specielt meget til hverdag og jeg har efterhånden haft en finger med i spillet omkring en hel del HTML- og tekstbaserede udsendelser :)
For modtageren er der en hel del risici, hvis man ikke tager sine forholdsregler. Man bør umiddelbar som minimum, blokkere hentningen af eksterne elementer, fra servere man ikke har godkendt, samt skimme en HTML e-mail's kildekode igennem før man viser den, hvis den ikke kommer fra en adresse man ved er trovædig. Ligeledes bør man lade være med at have slået preview-pane til i sin MUA, hvis man benytter et system hvor det er forholdsvist enkelt at udføre en handling som systemadministrator (F.eks en stor del af windows O.S'erne og MS' MUA'er). På Linux og Unixbaserede systemer er automatisk preview sjældent specielt slemt, da det er begrænset hvad der kan skades i systemet.
Generelt handler det bare om at have lidt mere end 2 hjerneceller slået til og en lille smule viden i baggagen når man betjener sin computer, så er det faktisk begrænset hvor galt det kan gå. :)
De fleste problemer opstår når brugeren betjener sin computer med hovedet under armen, samtidig med at man passer 3 unger, drikker kaffe, indbetaler sine regninger og forsøger at læse avisen. ;)
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.