Archief - De topics van lang geleden

Tekst (pre)processor voor Postfix

15-01-2008, 16:49 door Anoniem, 30 reacties
Wie kan een goede snelle 'lichtgewicht' text (pre)processor
voor Postfix aanbevelen die HTML e-mail converteert naar
plain vanilla tekst, BASE64 tekst decodeert e.d.
Reacties (30)
15-01-2008, 17:09 door Anoniem
Door Anoniem
Wie kan een goede snelle 'lichtgewicht' text (pre)processor
voor Postfix aanbevelen die HTML e-mail converteert naar
plain vanilla tekst, BASE64 tekst decodeert e.d.

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.
15-01-2008, 21:45 door Anoniem
goede security vraag hoor.
16-01-2008, 08:39 door SirDice
Perl?
16-01-2008, 09:04 door Anoniem
Door SirDice
Perl?

Code?
16-01-2008, 10:34 door SirDice
Door Anoniem
Door SirDice
Perl?

Code?
Zelf maken? Het was een suggestie. Perl is uitermate geschikt voor dit soort zaken.
16-01-2008, 14:12 door Anoniem
Door Anoniem
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.
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.
16-01-2008, 14:36 door SirDice
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.
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.
16-01-2008, 15:07 door Anoniem
Door SirDice
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.
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.
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.
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.
In ideale omstandigheden klopt dit, bij
ontvangen technisch en inhoudelijk keurige mailtjes.
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.
Na conversie kan deze inhoud
alsnog als spam herkend worden, voor zover dit anders niet
als zodanig herkend zou worden.
16-01-2008, 17:41 door Anoniem
Door SirDice
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.

MIME mails kunnen ook alleen HTML bevatten. Er is geen regel die
bepaald dat er een HTML mail ook alternatief in text zou moeten
bevatten.

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.

Doe dit niet, hiermee vervals je de opmaak van het mailbericht. Er is
duidelijk mee geprutst en dat is precies wat spammers doen.
Daardoor is de kans groot dat je bericht als gevolg hiervan als spam
wordt gezien.

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

Dat is niet altijd zo. De verzender kan zelf bepalen wat de ontvanger te
zien krijgt. Het kan bijvoorbeeld zijn dat de verzenderde boodschap
alleen via HTML kan overbrengen. Een tekst die dat uitlegt wordt dan
geplaatst in het text deel van een multipart/alternative opmaak.

Simpele anti-spam programma's als SpamAssassin kennen punten
toe als de inhoud alleen HTML is of als de inhoud van text en HTML
niet even groot is. Modernere, intelligente anti-spam software doet dat
niet aangezien het makkelijk leidt tot false positives,met name in
gewenste mailings.
16-01-2008, 22:15 door Anoniem
Door Anoniem
Door SirDice
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.

Doe dit niet, hiermee vervals je de opmaak van het
mailbericht.
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.
Er is duidelijk mee geprutst en dat is precies wat
spammers doen.
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.
Daardoor is de kans groot dat je bericht als gevolg
hiervan als spam wordt gezien.
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.

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

Dat is niet altijd zo. De verzender kan zelf bepalen wat de
ontvanger te zien krijgt.
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;.
Het kan bijvoorbeeld zijn dat de verzenderde
boodschap alleen via HTML kan overbrengen. Een tekst die dat
uitlegt wordt dan geplaatst in het text deel van een
multipart/alternative opmaak.
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."

Simpele anti-spam programma's als SpamAssassin kennen
punten toe als de inhoud alleen HTML is of als de inhoud van
text en HTML niet even groot is. Modernere, intelligente
anti-spam software doet dat niet aangezien het makkelijk
leidt tot false positives,met name in gewenste
mailings.
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.
17-01-2008, 08:24 door Sebastian
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.
17-01-2008, 08:58 door SirDice
Door Anoniem
Door SirDice
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.

MIME mails kunnen ook alleen HTML bevatten. Er is geen regel die bepaald dat er een HTML mail ook alternatief in text zou moeten bevatten.
De platte tekst wordt mee gezonden om de e-mail leesbaar te maken op clients die geen MIME ondersteunen.


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.

Doe dit niet, hiermee vervals je de opmaak van het mailbericht. Er is duidelijk mee geprutst en dat is precies wat spammers doen. Daardoor is de kans groot dat je bericht als gevolg hiervan als spam wordt gezien.
Stuur een HTML e-mail met outlook en bekijk de bron eens...
17-01-2008, 14:52 door Anoniem
Door SirDice
Stuur een HTML e-mail met outlook en bekijk de bron eens...

En daarmee wil je zeggen...? Ik denk dat je mijn punt mist.
17-01-2008, 15:29 door Anoniem
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.

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.

En dat is ook precies wat email-marketeers doen en andere
onverlaten.

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.

Beter is dan de dubieuze HTML markup te converteren naar
puur tekst, de enige manier om kwalijke code definitief onschadelijk te
maken.

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.

Dat hangt sterk af van de boodschap die je wilt overbrengen. Je
houdt namelijk uitsluitend de tekstuele boodschap over die je wilt
communiceren.

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.

Zoals dat uitsluitend bij dubieuze HTML markup wordt gedaan?

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.

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;
.

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.
17-01-2008, 15:32 door Anoniem
Door Sebastián (...) 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.

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).
17-01-2008, 16:51 door SirDice
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 ;)
17-01-2008, 20:51 door Sebastian
Door Anoniem
Het zou bijvoorbeeld veel effectiever zijn (voor inkomende
mail) links onklaar te maken.
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.
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.
Kun je daar een voorbeeld van geven?

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.
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.
17-01-2008, 21:41 door Anoniem
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.
17-01-2008, 21:44 door Anoniem
Door SirDice
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 ;)

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.
18-01-2008, 17:28 door Sebastian
Door Anoniem
Je moet geen berichten sturen naar de afzender tenzij je er
zeker van bent dat die niet vervalst is.
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 voorbeeld van HTML formattering is een rekening
met uitlijning.
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.
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.
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?
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.
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.
Merk ook op dat links bij een conversie naar text
veelal nog steeds functioneren. Het gevaar heb je daarmee
dus niet afgewend.
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.
Vanzelfsprekend moeten spam filters onaagepaste mail
te scannen krijgen, anders zullen detectieresultaten er
onder lijden, zowel door false positives als false
negatives.
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".
18-01-2008, 19:39 door Anoniem
Je noemt het vervalsen, maar binnen bedrijven en instellingen
worden de mails centraal gecontroleerd en worden aan uitgaande
mails zaken toegevoegd (knip)

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

Een dergelijke rekening bevat doorgaans geen bedenkelijke
HTML, die bij het openen direct met internet 'zou willen babbelen'.

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.

Dergelijke rekeningen worden daarnaast veelal als bijlage
verzonden.

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

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.

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.

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.

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

Dezelfde kwetsbaarheden die voor de gebruikte browser
gelden, gelden voor de rendering van HTML-email in mailprogramma's.

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.

Wat werd daar eerder over geschreven?

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

Zo vanzelfsprekend is dat niet omdat na conversie puur de
werkelijk te communiceren informatie overblijft om te controleren.

Dat is wishful thinking. Zo werken anti-spam systemen niet.
20-01-2008, 13:05 door awesselius
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 -
20-01-2008, 14:08 door lieque
Probeer us wat te zoeken over php of asp .net kan ook nog. Maar
persoonlijk zou ik dan gaan voor php of .net.
23-01-2008, 13:00 door Anoniem
Door Anoniem
Door Anoniem 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.
HTML hoort sowieso niet thuis in e-mail
???
RFC ?
24-01-2008, 01:19 door Anoniem
Door Anoniem
Door Anoniem
HTML hoort sowieso niet thuis in e-mail
???
RFC ?
822
24-01-2008, 18:01 door Sebastian
Door Anoniem
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.
Dat is irrelevant omdat je ook rekening moet houden met eventuele abusievelijk gedane instellingen door de gebruiker.

Dezelfde kwetsbaarheden die voor de gebruikte browser
gelden, gelden voor de rendering van HTML-email in mailprogramma's.
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.
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.

Zo vanzelfsprekend is dat niet omdat na conversie puur de werkelijk te communiceren informatie overblijft om te controleren.
Dat is wishful thinking. Zo werken anti-spam systemen niet.
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.
24-01-2008, 22:04 door Anoniem
Door Sebastián
Dat is irrelevant omdat je ook rekening moet houden met eventuele
abusievelijk gedane instellingen door de gebruiker.

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.

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.


Toon aan.

Laat onverlet de risico's bij gecompromitteerde externe
webpagina's of resources

Welke risico's? Scripting wordt niet uitgevoerd, weet je nog?

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.

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.
25-01-2008, 08:02 door Sebastian
Door Anoniem
Door Sebastián
Dat is irrelevant omdat je ook rekening moet houden met eventuele abusievelijk gedane instellingen door de gebruiker.
Het is nogal moeilijk voor een gebruiker om de instellingen te veranderen.
Wat de kans op abusievelijk gedane instellingen in het mailprogramma verhoogt.
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.
Toon aan.
Dat kun je [url=http://www.pixmix.us/files/s8lmtw060lq9ev3lisop.png]hier[/url] bekijken.
Laat onverlet de risico's bij gecompromitteerde externe webpagina's of resources
Welke risico's? Scripting wordt niet uitgevoerd, weet je nog?
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.
Met jouw conversies verniel je spamberichten waardoor die niet meer als spam worden herkend.
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.
Je gaat er gemakshalve maar van uit dat iedereen Bayesiaanse filters gebruikt.
Hoe bedoel je dat?
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.
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.
25-01-2008, 11:47 door Anoniem
Door Sebastián
Wat de kans op abusievelijk gedane instellingen in het mailprogramma verhoogt.

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.

Dat kun je [url=http://www.pixmix.us/files/s8lmtw060lq9ev3lisop.png]hier[/url] bekijken.

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

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.

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

Hoe bedoel je dat?

Is geen woord Frans bij denk ik.

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.

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.
25-01-2008, 19:23 door Sebastian
Door Anoniem
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.
Welnee, omdat je rekening moet houden
met eventuele abusievelijk gedane instellingen door de
gebruiker, en dat ongeacht moeilijkheidsgraad van gegeven
instellingen is.
Dat kun je
[url=http://www.pixmix.us/files/s8lmtw060lq9ev3lisop.png]hier[/url]
bekijken.
Toon aan met code. Een plaatje is zegt niets. Zorg ervoor
dat je met standaard instellingen werkt.
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.

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.
Dat werkt niet. Standaard security settings verbieden het
laden van ActiveX.
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.

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.
Je vind dat iedereen maar een door jou uitgekozen methode
moet gebruiken (...)
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.
(...) 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).
Welke grootse
inspanningen verwacht je dat de ontvanger wil gaan
verrichten aan schone, van spam, virussen en van andere
malware gevrijwaarde e-mail?

Feit is dat jouw conversies detectie verhinderen bij
bijna alle spam filters en dat je dat daarom niet moet
doen.
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.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.