Dat moet je niet doen. Als je mail gaat converteren is de kans groot dat
je mail er gaat zien als spam. Je bent dan bezig met vervalsing.

goede security vraag hoor.

Perl?

Code?

Zelf maken? Het was een suggestie. Perl is uitermate geschikt voor dit soort zaken.

HTML hoort sowieso niet thuis in e-mail en waar het
in e-mail voorkomt wordt het zelden correct gebruikt.
Meestal kun je spreken over misbruik, soms onbewust al of
niet door slordige fouten, maar ook doelbewust door
bijvoorbeeld email marketeers waarbij de markup bijvoorbeeld
sterk leunt op externe bronnen waardoor de ontvanger sterk
afhankelijk is van de grillen van die externe bronnen en dus
onnodig kwetsbaar is voor heimelijke tracking en infecties.
En dan heb ik nog niet gerept over enorme bergen onzin die
Microsoft producten meesturen, zelfs bij de meest simpele
tekst als 'tot vanavond' zonder verdere opmaak. De bron ziet
er 'erg indrukwekkend uit' maar is verder absoluut
functieloos, nutteloos.

E-mail met HTML-elementen die je zeker niet in e-mail mag
verwachten, zoals onder andere maar niet beperkt tot
(i)frame, base, object, embed, scripts, http-equiv refresh,
kun je inderdaad beter weigeren.

E-mail waarvan andere elementen in de HTML markup op een
externe bron leunen kunnen op die basis helaas niet zo
resoluut worden geweigerd omdat het een wat meer voorkomende
(beginners) fout is, die overigens wel door bijvoorbeeld
e-mail marketeers wordt uitgebuit en met succes omdat er
over het algemeen niet op wordt gecontroleerd. Deze
overlapping tussen (onbewuste) beginnersfouten en
doelbewuste uitbuiting zou een absolute weigering niet zo
gebruiksvriendelijk maken.

Doel van e-mail is dat de legitieme tekstuele boodschap
overkomt en lijkt mij conversie van HTML naar puur tekst dan
de meest gebruikersvriendelijke oplossing. De boodschap komt
immers over, maar dan zonder de foute HTML-markup en dus
zonder de daarbij behorende onnodige kwetsbaarheden voor
ontvangers die HTML-mail inderdaad door hun mailprogramma
laten interpreteren waarbij hun veiligheid mede sterk
afhangt van hun internetbrowser en lokale instellingen.

HTML e-mail wordt altijd middels MIME verzonden. Er is dan een deel wat alleen de platte tekst bevat en een deel wat de HTML is. Feitelijk gezien wordt dezelfde info 2 keer meegezonden. Er hoeft dus niets geconverteerd te worden, je zou alleen het MIME gedeelte met de HTML er uit hoeven te
slopen.

Spammers maken hier echter gebruik/misbruik van door in het platte tekst gedeelte onzin te plaatsen (t.b.v. het ontwijken van bayesian filters) en het HTML gedeelte om hun product aan te prijzen.

Bij een "normale" e-mail client zijn de twee delen (tekst) inhoudelijk hetzelfde.

Ik ben met u eens dat dit het geval zou
behoren te zijn, maar treft men tevens multipart mail met
een deel lege of nutteloze platte tekst ('de mail moet met
html worden bekeken') en een deel HTML (waar de te
overbrengen boodschap wèl aanwezig is), multipart mail met
HTML in beide delen en zijn er tevens voorkomingen van HTML
in gewoon RFC822 mail, zonder MIME.
In ideale omstandigheden klopt dit, bij
ontvangen technisch en inhoudelijk keurige mailtjes.
Na conversie kan deze inhoud
alsnog als spam herkend worden, voor zover dit anders niet
als zodanig herkend zou worden.

Daar moet de verzender rekening mee
houden, gelet op de reputatie van HTML in e-mail.
Stuur het dan gewoon (mede) in normaal tekst, waar iedereen
mee overweg kan. Je wilt toch immers dat je boodschap
overkomt? Dan moet je je email-bericht zeker niet (alleen)
in HTML opstellen.
En dat is ook precies wat
email-marketeers doen en andere onverlaten. Beter is dan de
dubieuze HTML markup te converteren naar puur tekst, de
enige manier om kwalijke code definitief onschadelijk te maken.
Dat hangt sterk af van
de boodschap die je wilt overbrengen. Je houdt namelijk
uitsluitend de tekstuele boodschap over die je wilt
communiceren. Indien die boodschap spam is, dan zal dat
terecht als zodanig worden herkend.
De verzender kan dat niet
bepalen. Het enige waar de verzender daadwerkelijk van op
aan kan is RFC822, zijnde standaard ASCII, en in geval van
MIME gevolgd door Content-Type: text/plain;.
Zoals dat uitsluitend
bij dubieuze HTML markup wordt gedaan? Anders werken de
tracking mechanismen, de cookies en andere pogingen tot
compromitteren niet. "U moet de mail in HTML bekijken,
anders hebben wij u niet heimelijk bij de veter."

Het grappige aan mailings is dat ontvangers
over het algemeen geen idee hebben van verwerpelijke HTML
markup, die aan deze mensen worden voorgeschoteld. Dat de
beste mensen hiertegen beschermd moeten worden, spreekt voor
zich.

Je kunt conditioneel HTML converteren en dit aan de
ontvanger kenbaar maken, wanneer na analyse bedenkelijke
HTML broncode is gebleken. Doorgaans zal dit bij spam en
typische mailingen het geval zijn omdat men daar met enige
regelmaat er meer toe neigt de grenzen van het betamelijke
te overschrijden. Het gebruik van voor e-mailprogramma's
duidelijke HTML kwetsbaarheden in berichten kan men beter
weigeren.
Mail waar na contrôle niets mee aan de hand lijkt, laat men
in de regel intact. Dit betekent niet per se dat de
ontvanger een HTML-bericht krijgt weergegeven zoals deze
oorspronkelijk is bedoeld. Onder andere te denken aan het in
de mail gebruikte font dat ontvanger niet op de computer
heeft staan of waarvan de grootte door ontvanger wordt
aangepast omdat het te kleine of te grote letters zijn etc.,
verschillende mailprogramma's die allen om verschillende redenen de HTML-email anders renderen dan wat de verzender op het scherm had staan. Tevens kan ontvanger in het mailprogramma hebben aangegeven te wensen HTML-berichten alsnog in tekst weer te geven, desnoods middels een conversie. Dat laatste is de aanbevolen instelling voor mailprogramma's, uit veiligheidsoogpunt maar zeker ook uit ergonomische overwegingen. Immers, bij tekstberichten bepaalt de ontvanger een persoonlijk prettig leesbaar font, bijbehorende grootte, tekst- en achtergrondkleur waarin berichten uniform worden weergegeven.

En daarmee wil je zeggen...? Ik denk dat je mijn punt mist.

Dat is jouw mening. Het is waar, in het algemeen is
multipart/alternative met text of html een goede methode, maar
onthoudt wel: de regels staan gewoon toe alleen HTML te sturen. Het
gebeurt en voor goede redenen door legitieme verzenders.


Naast deze groepen zijn er ook veel gewenste mailings die op deze
wijze worden verstuurd. Of je het daarmee eens bent of niet: het is er
en het gaat niet weg.


Welke kwalijke code? De meeste email leesprogramma's voeren geen
scripts uit. Van mij mag je script e.d. best verwijderen uit inkomende
mail, maar ga niet gemanipuleerde mails de wereld insturen.

Exploits via email zitten tegenwoordig nauwelijks in HTML, het zit veel
vaker in de bijlage of op de site waarheen verwezen wordt. Het zou
bijvoorbeeld veel effectiever zijn (voor inkomende mail) links onklaar te
maken. De laatste keer dat scripting er echt toe deed was in 2001. Ten
tijde van de fameuze MS01-020 vulnerability. Al snel daarna nam het
belang af.


Voor sommige toepassingen zijn nu eenmaal meer
formatteringmogelijkheden nodig dan met text haalbaar is. Als je
dergelijke boodschappen in zo'n geval probeert te converteren zal dat
mislukken en is het resultaat rommel.


Ik begrijp dat het je hoog zit bij je, maar er zijn vele legitieme
toepassingen van HTML. Cookies en beelden werken niet totdat de
ontvanger respectievelijk op een link klikt of de plaatjes laat ophalen
van een server. Dat laatste vinden marketeers handig voor hun
statistieken, maar dat besluit neem je als ontvanger na ontvangst.

.

Daar ging het niet over. De verzender kan zelf bepalen wat er in het text
en het HTML deel staat. Die inhoud hoeft niet aan elkaar gelijk te zijn.

Al dat geklets leidt af van wat ik wilde zeggen:
1. Je kunt niet zonder risico eisen stellen aan email zoals
SpamAssassin dat doet. SpamAssassin wordt getest op een corpus
waar weinig zakelijke mail in zit. Daardoor zijn de scores voor ongelijke
text/html verhouding of HTML only te hoog.
2. Pruts niet met uitgaande mail, de mail ziet er gemanipuleerd uit, je
riskeert detectie door anti-spam software.

De laatste betekent dat je ook spaarzaam moet zijn mijn footers (aka
disclaimers) die op een centrale plaats worden toegevoegd. Het beste
is footers toe te voegen in de mail applicatie die de mail maakt.

Inderdaad en bovendien wordt het risico van HTML in email
schromelijk overdreven. De huidige maillezers zijn redelijk veilig en het
echte risico schuilt elders: vooral in links en in mindere mate in
bijlagen (al dan niet met exploit).

Hihihi... Volgens mij gaan we van twee verschillende dingen uit..

Ik ging er vanuit dat het om het verwerken/aanpassen van ontvangen mail ging..Een van die Anoniemen heeft het volgens mij over het verwerken/aanpassen van uitgaande mail...

Subtiel verschil ;)

Dat denk ik niet, omdat
mensen regelmatig refereren aan informatie op website's.
Link's naar bekende malafide site's daarentegen kunnen beter
geweigerd voor inkomende en uitgaande mail. Door middel van
de foutmelding wordt de verzender daar direct van op de
hoogte gesteld, die mogelijk nog niet bewust was van de aard
van een gegeven site of link.
Kun je daar een voorbeeld van geven?
Bij ontvangers die hun mailprogramma nog
niet juist hebben geconfigureerd wordt dit besluit al voor
de ontvanger genomen zodra deze de mail met bedenkelijke
HTML aanklikt om te lezen, inclusief cookies, tracking,
beelden, stats en dergelijken. De ontvanger hoeft daar niet
expliciet een link voor aan te klikken.
Bijvoorbeeld het automatisch inladen van met malware geïnfecteerde reclame-banners is eveneens niet ondenkbaar.

Voordat de ontvanger een mail met bedenkelijke HTML aanklikt
om te lezen, dan weet de ontvanger nog niet dat het een mail met bedenkelijke HTML betreft.

Je moet geen berichten sturen naar de afzender tenzij je er zeker van
bent dat die niet vervalst is.

De opmerking over links maakte ik omdat dit -integenstelling tot HTML-
>text omzetting- wel een sterke invloed heeft op de veiligheid. Het is
vaak practisch niet mogelijk zoiets te doen. Merk wel op dat de impact
vele malen geringer is dan die van ruecksichtlose HTML->text
conversie.

Een voorbeeld van HTML formattering is een rekening met uitlijning,
een tabel met kleuren, etc.

Als je nu nog met een mail client werkt die standaard geen plaatjes
tegenhoudt, dan is die ofwel niet up to date of EOL (een echt
gevaar) ofwel van nature niet veilig, dus ook niet veilig te maken.

Nog een keer: er zijn geen significante directe dreigingen in HTML in
email. De echte dreigingen zijn momenteel malware distribuerende
web sites. Ze doen dat zowel met als zonder exploit.

Merk ook op dat links bij een conversie naar text veelal nog steeds
functioneren. Het gevaar heb je daarmee dus niet afgewend.

Prima, maar de OP heeft dat niet gesteld in de vraag. Daarom
behandel ik beide in het antwoord.

Vanzelfsprekend moeten spam filters onaagepaste mail te scannen
krijgen, anders zullen detectieresultaten er onder lijden, zowel door
false positives als false negatives.

Je noemt het
vervalsen, maar binnen bedrijven en instellingen worden de
mails centraal gecontroleerd en worden aan uitgaande mails
zaken toegevoegd, te denken aan een disclaimer, een
certificaat en etcetera. Ook conversie is niet uitgesloten,
soms zelfs noodzakelijk!
Een dergelijke rekening bevat
doorgaans geen bedenkelijke HTML, die bij het openen direct
met internet 'zou willen babbelen'. Dergelijke rekeningen
worden daarnaast veelal als bijlage verzonden.
Heb je niet
eerder beweerd, ik citeer: "De verzender kan zelf bepalen
wat de ontvanger te zien krijgt."
Het is goed dat je nu ook zelf bevestigd dat dit niet het
geval is.
Wat te denken van foutief geconfigureerde mailprogramma's?
En waar verwijst HTML
email met bedenkelijke markup naar? Die zijn inderdaad sterk
afhankelijk van externe bronnen, van website's om voor de
lezer toonbaar te zijn. Dezelfde kwetsbaarheden die voor de
gebruikte browser gelden, gelden voor de rendering van
HTML-email in mailprogramma's.

Bij ontvangers die hun mailprogramma nog niet juist hebben
geconfigureerd wordt direct al 'met internet gebabbeld'
zodra deze de mail met bedenkelijke HTML aanklikt om te
lezen, inclusief cookies, tracking, beelden, stats en
dergelijken, zonder dat ontvanger daarvan op de hoogte is.
De ontvanger hoeft daar niet expliciet een link voor aan te
klikken.
Bijvoorbeeld het automatisch inladen van met malware
geïnfecteerde reclame-banners is eveneens niet ondenkbaar.

Het converteren van mail met bedenkelijk HTML naar tekst
heeft dus wel degelijk een sterke positieve invloed op de
veiligheid.
Wat werd daar eerder over geschreven?
"Link's naar bekende malafide site's daarentegen kunnen beter
geweigerd voor inkomende en uitgaande mail. Door middel van
de foutmelding wordt de verzender daar direct van op de
hoogte gesteld, die mogelijk nog niet bewust was van de aard
van een gegeven site of link." Buiten dat worden link's niet
automatisch geladen bij het openen van een HTML mail en moet
de lezer de links bewust expliciet aanklikken om deze te laden.
Zo vanzelfsprekend is dat niet omdat na
conversie puur de werkelijk te communiceren informatie
overblijft om te controleren. Wat het risico op false
positives en false negatives merkbaar terugdringt.
"[html]spa<!-- spammer truck -->m tekst[/html]" wordt dan
"spam tekst".

Het ging over het vervalsen van het afzenderadres. Stuur geen mail
naar vervalste afzenderadressen.


De term "bedenkelijke HTML" is mij niet bekend.

Doe mij een voorbeeld van een email die direct met Internet kan
babbelen als het in een courante versie van Outlook met
standaardinstellingen wordt geopend.


Electronische rekeningen worden vaak in HTML verzonden. Negeren
van feiten heeft geen zin.


Je verdraait de zaak. Het is al 2 keer uitgelegd. Dit ging over de
mogelijkheid van de verzender om de inhoud van text en HTML deel te
bepalen.


Hier gebruik je weer eigen termen "bedenkelijke markup", dat zegt me
niets. Het ging overigens over links.


Nee, dat is een foute aanname. Dat al lang niet meer zo. Je kunt
bijvoorbeeld al sinds ruim 5 jaar geen iframe gebruiken in Outlook.


Dat is een herhaling en daar krijg ik geen royalties voor. :-)


Dat is wishful thinking. Zo werken anti-spam systemen niet.

Als het om inkomende mail gaat, zou ik denken aan procmail.
Die komt weliswaar na de Postfix afhandeling, maar dat geldt
voor alle procmail verwerking. Procmail staat voor 'process
mail', dus daar kun je alles mee doen wat je zou willen
doen. Je kunt dit ook nog een per user instellen of globaal
over het hele systeem.

Met procmail kun je andere scripts aanroepen, je kunt
checken op headers (dus ook op afzender) en zo kun je de
flow van het proces bepalen zodat enkel de mail wordt
hervormd dat hervormd moet worden.

Je kunt er anti-virus voor of na doen, je kunt bepalen
wanneer er gecontroleerd wordt op spam of plaatjes etc.

Niet dat ik zoiets even uit mijn mouw schud, maar het zeker
wel mogelijk.

- Unomi -

Probeer us wat te zoeken over php of asp .net kan ook nog. Maar
persoonlijk zou ik dan gaan voor php of .net.

???
RFC ?

822

Dat is irrelevant omdat je ook rekening moet houden met eventuele abusievelijk gedane instellingen door de gebruiker.
Je kunt met enkele regels code, zonder gebruik te maken van frames, zelfs een complete *externe* webpagina door Outlook laten inladen, inclusief daarin gebruikte resources, waarbij het lijkt alsof dat de inhoud is van de verstuurde mail. Aan de kant van de geladen website wordt duidelijk welke versie van MSIE men gebruikt. Dat is niet zo vreemd omdat Outlook MSIE gebruikt om HTML-email te renderen.
Laat onverlet de risico's bij gecompromitteerde externe webpagina's of resources. Laat onverlet de risico's van HTML-email waarvan de gebruikte markup op enigerlei wijze externe bronnen wenst aan te roepen, bijvoorbeeld om voor de
lezer toonbaar te zijn.
Verdiep je eens in bijvoorbeeld Bayesian en CRM114 spam filtering. Dat werkt uitstekend met puur werkelijk te communiceren informatie, die overblijft na conversie van HTML naar tekst.

Natuurlijk sluit dit andere filtermechanismen niet uit, zoals bijvoorbeeld URL filtering.

Als gebruiker kun je ook de firewall en virus scanner uitzetten en
malware downloaden en uitvoeren.

Het is nogal moeilijk voor een gebruiker om de instellingen te
veranderen. Voor een aantal opties moet je speciale administrator
tools gebruiken en voor andere moet je eerst weten waar je moet zijn.


Met jouw conversies verniel je spamberichten waardoor die niet meer
als spam worden herkend. Je gaat er gemakshalve maar van uit dat
iedereen Bayesiaanse filters gebruikt.

Gelukkig is dat niet zo. Bayesian filtering is een kale methode en die
levert op zichzelf niet voldoende houvast op om spam tegen te houden
zonder false positives. Fouten zijn ingebouwd.

Wat de kans op abusievelijk gedane instellingen in het mailprogramma verhoogt.
Dat kun je [url=http://www.pixmix.us/files/s8lmtw060lq9ev3lisop.png]hier[/url] bekijken.
Niet nodig. Bijvoorbeeld Flash is genoeg zoals we dit een kleine tijd terug [url=http://www.security.nl/article/17768/1/Malware_verspreid_via_banners_op_MySpace_en_Excite.html]hier[/url] hebben kunnen lezen. Zodra in HTML-email gebruikte markup op enigerlei wijze externe bronnen wenst aan te roepen, dan loopt men risico op compromittatie.
Welk algoritme zou moeite hebben met van HTML naar tekst geconverteerde spamberichten? Beter nog, geef gerust ter illustratie een HTML spambericht dat na conversie naar tekst niet meer als spam zou kunnen worden herkend.
Hoe bedoel je dat?
Een goed getrainde CRM114 filter is zeer accuraat met een te verwaarlozen kans op een false negative of false positive. Training van het filter is essentieel.

Als je als gebruiker al niet weet hoe je een moeilijke instelling voor elkaar kunt krijgen zal het je ook niet per
ongeluk lukken dat te doen. Je houd je vast aan stroohalmpjes.


Toon aan met code. Een plaatje is zegt niets. Zorg ervoor dat je met standaard instellingen werkt.


Dat werkt niet. Standaard security settings verbieden het laden van ActiveX.


Is geen woord Frans bij denk ik.


Je vind dat iedereen maar een door jou uitgekozen methode moet gebruiken met false positives en false
negatives die ook nog eens grote inspanningen vereist van de ontvanger (alleen omdat je het fijn vind met mail te
prutsen, want enig nut is er niet).

Feit is dat jouw conversies detectie verhinderen bij bijna alle spam filters en dat je dat daarom niet moet doen.

Welnee, omdat je rekening moet houden
met eventuele abusievelijk gedane instellingen door de
gebruiker, en dat ongeacht moeilijkheidsgraad van gegeven
instellingen is.
Overwegende
onbedoeld publiek plaats ik geen in potentie gevoelige code
die men zou kunnen misbruiken.
Wel mag volledigheidshalve worden opgemerkt dat het met de
standaard instellingen niet werkt. De gebruiker moet
daarvoor twee globale instellingen versoepelen, te weten
[url=http://www.pixmix.us/files/z3lxaeht9v6s6f5belb9.png]deze[/url].
De kans is vrij groot aanwezig dat een significant deel van
gebruikers van Outlook de globale instellingen hebben
versoepeld, bijvoorbeeld om dat 'ene leuke mailtje of
mailing' volledig te kunnen zien, waarmee de gebruiker zich
onbewust meer kwetsbaar maakt. (meer daarover in navolgende
alinea) Als je daar verder over nadenkt is het
onbegrijpelijk dat een mailprogramma gebruikers dergelijke
instelmogelijkheden aanbiedt. Anderzijds kun je bij de
mailserver al rekening houden met eventueel abusievelijk
gedane instellingen door de gebruiker, om gebruikers in
bescherming te nemen.
Globale instellingen waarvan de
kans groot is dat de gemiddelde gebruiker deze heeft
versoepeld. Dat valt mede af te leiden aan het door
zogenaamde online e-mail marketeers gebruik van HTML-email
waarvan de markup op enigerlei wijze externe bronnen wenst
aan te roepen. Blijkbaar is dat ondanks standaard
instellingen die dat zouden moeten voorkomen nog altijd
lucratief. Blijkbaar gebruikt een significant deel van
gebruikers niet de standaard instelling.

Zouden gebruikers massaal wel de standaard instelling
gebruiken, dan is het niet lucratief om HTML-email te
gebruiken waarvan de markup op enigerlei wijze externe
bronnen wenst aan te roepen.
Nou nou, dat vind ik wel een
onbehoorlijke toedichting, en die bezijden de waarheid is.
Wat ik mij wel zou kunnen wensen is dat men meer bewust
wordt van de veiligheidsaspecten inzake HTML-email.
Welke grootse
inspanningen verwacht je dat de ontvanger wil gaan
verrichten aan schone, van spam, virussen en van andere
malware gevrijwaarde e-mail?

Als dat een feit is dan kun je m'n vraag
beantwoorden, waar ik helaas nog geen antwoord op heb mogen
ontvangen over welk algoritme moeite zou hebben met van HTML
naar tekst geconverteerde spamberichten? Beter nog, geef
gerust ter illustratie een HTML spambericht dat na conversie
naar tekst niet meer als spam zou kunnen worden herkend.

Buiten dat, indien je uit gaat van conversie en
spamfiltering van inkomende èn van uitgaande mail waarbij
uitsluitend schone, van spam, virussen en van andere malware
gevrijwaarde e-mail doorgang vindt... schoner dan schoon kun
je het niet maken.