[Feature] Email tag met image parser

[Bolk]

Ik weet niet in hoeverre het geimplementeerd kan worden, maar een [email] tag lijkt me handig die dan geparsed wordt naar een image.

M14 in "Gratis tweaker party, schrijf je hier in..." hier bijv komen de plaatjes uit profile, is het mogelijk om dit real time te fixxen? Wellicht is het er al en zie ik het over het hoofd?

[sdomburg]

Ik zat er laatst ook over te denken, en ik weet dat het eerder ter sprake is gekomen ergens, maar ik kan het betreffende topic in de search niet vinden.

Edit; jaj, met de veel te algemene zoekterm mail in dit subforum en wat handmatig doorspitten: [rml][ feat] Revised mailtag[/rml]

Zou het trouwens wel fijn vinden als chem even toelicht waarom het nutteloos is? Lijkt me handig tegen spammers en zodat je niet allemaal truucjes met [kringelding [puntje] etc. hoeft te doen

[ Voor 59% gewijzigd door sdomburg op 17-04-2004 18:57 ]

[curry684]

Volgens mij was chem daar even wat snel, z'n conclusie klopte namelijk wel voor het meuk(at)melp(dot)nl replacing, ik denk dat ie de image-variant gemist had

[crisp]

Het moet mogelijk zijn in React zelf tags aan te maken en daar je eigen replacement aan te koppelen, hoe of dat dit werkt weet ik nog niet precies maar zal ik voor de nieuwe layout toch moeten gaan onderzoeken omdat veel RML nog niet XHTML-compliant is, en ik uiteindelijk bepaalde behaviour wil verplaatsen naar javascript (denk aan het target-attribuut voor links).
Grootste nadeel dat ik op dit moment kan verzinnen voor zo'n aanpak is dat base_grey er waarschijnlijk niet mee om kan gaan en oude topics nog oude RML hebben.
Als Parse niets ziet in het inbouwen van zo'n feature is er dus een mogelijkheid om het alleen voor GoT te doen, maar ik ben niet degene die daarover gaat Dit afgezien van de algemene discussie dus over RML die nog gevoerd zal moeten gaan worden.

[moto-moi]

Ehmm... ok..
Dit klinkt leuk, in theorie enzo, maaruh, stel:

code:

[email=[e-mail]]

OK, in de standaard view zou je daar geen fuck van zien, maar klik nu eens op het 'view message' icoontje ?
Juist, daar staat dus je hele email-adres in al zijn glorie.
Om dit te voorkomen zou je dus een apart scherm moeten gaan maken, waarin je een email-adres invult, waarbij je dan een code terug krijgt, het email-adres moet dan in de database gezet worden.
Dit is iets meer werk dan simpelweg een nieuwe rml-tag, er zal redelijk wat voor bijgeprogrammeerd moeten worden, voor iets wat je eigenlijk bijna nooit gebruikt, tenminste, ik zie niet zo vaak email-adressen van mensen die niet op GoT zitten verschijnen.

Maargoed, misschien vinden de heren van Parse het wel een ubergeile feature

[ Voor 6% gewijzigd door moto-moi op 17-04-2004 20:01 ]

[curry684]

moto-moi is een prutsprogrammeur

Als ik [FORUM=10]Software Algemeen[/FORUM] intyp wordt dat ook vertaald tot [forum=10]Software Algemeen[/forum]: de feitelijke message hoeft dus niet identiek te blijven aan het originele bericht.

Op dezelfde manier zou [email][e-mail][/email] geparsed kunnen worden tot [email]enc:478327984265652[/email], een encrypted variant van het mailadres. De renderer kan dan aan een escaper (zoals ik hier 'enc:' gebruik) bij een edit herkennen of het al of niet een encrypted mailadres is.

[sjaakaq]

En wat dan ook handig zou zi9jn: dat het plaatje een mailto: link is, adressen van plaatjes overtypen is

Als het kan hè

[Verwijderd]

leokennis schreef op 17 april 2004 @ 20:34:
En wat dan ook handig zou zi9jn: dat het plaatje een mailto: link is, adressen van plaatjes overtypen is

Als het kan hè

Grapjas...

[elevator]

leokennis - In een link zou dan alsnog het daadwerkelijk mail address moeten zitten dus dat lijkt me niet handig

[moto-moi]

curry684 schreef op 17 april 2004 @ 20:12:
Op dezelfde manier zou [email][e-mail][/email] geparsed kunnen worden tot [email]enc:478327984265652[/email], een encrypted variant van het mailadres. De renderer kan dan aan een escaper (zoals ik hier 'enc:' gebruik) bij een edit herkennen of het al of niet een encrypted mailadres is.[/norml]

Dat zeg ik toch ook ? Ik geef 2 mogelijke oplossingen, waarvan jij er blijkbaar maar eentje heb gelezen

Mijn punt blijft, bij de laatste manier,die jij ook weer uitlegd, moet er dus geprogrammeerd gaan worden, hetgeen meer inhoudt dan even een rml-tag aanmaken.

[Arjan]

het zou toch ook beperkt kunnen worden tot bv. [email] en dat dan gewoon het mail adres van de persoon z'n profiel geparsed wordt. Eventueel een optie voor een tweede email adres toevoegen. Dan zou je bv [email1] of [email2] kunnen gebruiken. Op die manier hoeven er ook geen tig plaatjes gegenereerd te worden. (niet dat de tweaker servers daar wakker van zullen liggen )

[ACM]

Is het niet minder werk om gewoon naam (at) plek (dot) nl in te tikken
Allemaal plaatjes gaan bakken (en dus onhandig, want je moet het overtikken) en moeilijk doen voor automatisch gegenereerde zooi en encryptie van e-mailadressen...

Ik zie niet in waarom je niet gewoon het adres verkapt neer kan zetten.

[ Voor 16% gewijzigd door ACM op 17-04-2004 22:34 ]

[m-m]

code:

http://www.mhil.net/myself/gotscript.php?a=m-m&b=tweakers.net

->
Als je een dergelijk scriptje op de T.net server zet en zorgt dat [e-mail] in RML wordt vertaald naar <img src="http://gathering.tweakers.net/antispam.php?a=m-m&b=tweakers.net" alt="m-m (at) tweakers (dot) net" /> dan ben je er al. Tuurlijk, een slim script kan alle adressen alsnog harvesten, maar dat kan ook met de blaat(at)blaat.nl methode. Je vangt zo alsnog de spiders wel af.

Ik snap geen ruk van PHP, maar zelfs ik kan dit maken:

PHP:

<?php
header("Content-type: image/png");

$textstring = $_GET['a']."@".$_GET['b'];
$width = 6 * strlen($textstring);
$im = @imagecreate($width, 12)
   or die("Cannot Initialize new GD image stream");
$background_color = imagecolorallocate($im, 255, 255, 255);
$text_color = imagecolorallocate($im, 0, 0, 0);
imagestring($im, 2, 0, 0, $textstring, $text_color);
imagecolortransparent($im, $background_color);
imagepng($im);
imagedestroy($im);
?> 

[ Voor 32% gewijzigd door m-m op 17-04-2004 22:39 ]

[Bolk]

Ik ga mee met het m-m verhaal. Toch nog een beetje content advertising achtig

[Oxi]

Ik bedacht dit net ook en toen ik dit idee wilde plaatsen hier zag ik dit topic al.
dinges (op irc) kwam ook met de gedachte van bekijk/quote bericht. maar kan dit niet afgesloten worden als je niet ingelogd bent.

[m-m]

er staat [e-mail] (met een komma dus, geen @)dus op zich kan een spider daar in bekijk/quote bericht alsnog niets mee, lijkt me Desnoods verzin je een nog l33tere syntax daarvoor.
Najja, ik weet het ook niet

[ Voor 15% gewijzigd door m-m op 18-04-2004 00:05 ]

[Oxi]

Ja maar ik ging er van uit dat je het hele emailadres intikt

[curry684]

m-m schreef op 17 april 2004 @ 22:39:
Ik snap geen ruk van PHP, maar zelfs ik kan dit maken:

Jij bent echt een 1337 devslet, wil je moderator Programming & Webscripting worden?

[ACM]

Ok nog es:
Ja, het is programmeertechnisch mogelijk, so what?
De vraag is niet of het mogelijk is, maar of het wenselijk is. Ik zie niet waarom en heb nog geen argumenten gezien waarom het wenselijk zou zijn.

Alvast wat nadelen waar het tegen op moet wegen:
- Leesbaarheid met tekstbrowsers verlaagt.
- Snelheid van "tekstonly" interfaces gaat omlaag (pda's via gprs enzo).
- Extra serverload voor elk plaatje dat gegenereerd moet worden.
- E-mailadressen worden niet meer door onze searchengine geindexeerd.

En geef dan de voordelen van "een willekeurig e-mailadres-rewriter" en daarbovenop de voordelen van een "afbeeldings-e-mailadres-rewriter". Vooral de extra voordelen van die laatste stap zie ik niet zo goed.

Volgens mij is zoiets veel leesbaarder en handiger:
<span class='first'>naam</span><span class='at'>@</span><span class='last'>iets.nl</span>
wat dus dit oplevert: [e-mail]
Knappe spambot die daar nog een e-mailadres uit weet te halen, terwijl het precies hetzelfde leest als een daadwerkelijk e-mailadres. En uiteraard zijn daar allerlei varianten op mogelijk.

[ Voor 7% gewijzigd door ACM op 18-04-2004 10:39 ]

[Bolk]

ACM schreef op 18 april 2004 @ 10:38:
Alvast wat nadelen waar het tegen op moet wegen:
- Leesbaarheid met tekstbrowsers verlaagt.

Ehm, ja, die gebruikt iedereen dagelijks. Sorry, maar dit vind ik niet echt een sterk argument.

- Snelheid van "tekstonly" interfaces gaat omlaag (pda's via gprs enzo).

Daar zit wel iets in, maar zou toch graag weten om hoeveel procent het van de pageviews gaat hier.

- Extra serverload voor elk plaatje dat gegenereerd moet worden.

Ga me niet vertellen dat die gigantische farm geen statische content kan genereren. Overigens komt niet in elke post (topic zelfs) een email adres voor, dus de servers zouden het nieteens merken imho.

- E-mailadressen worden niet meer door onze searchengine geindexeerd.

Daar is vast een oplossing voor te verzinnen. Als je iets realtime rendert is het natuurlijk simpel, doe je iets met statische content is het iets lastiger.

Volgens mij is zoiets veel leesbaarder en handiger:
<span class='first'>naam</span><span class='at'>@</span><span class='last'>iets.nl</span>
wat dus dit oplevert: <span class='first'>naam</span><span class='at'>@</span><span class='last'>iets.nl</span>
Knappe spambot die daar nog een e-mailadres uit weet te halen, terwijl het precies hetzelfde leest als een daadwerkelijk e-mailadres. En uiteraard zijn daar allerlei varianten op mogelijk.

De intensie van het topic was het "email adres spam proof te maken". Dus deze textvariant is ook een prima oplossing imho

[Verwijderd]

ACM schreef op 18 april 2004 @ 10:38:
Ok nog es:
Ja, het is programmeertechnisch mogelijk, so what?
De vraag is niet of het mogelijk is, maar of het wenselijk is. Ik zie niet waarom en heb nog geen argumenten gezien waarom het wenselijk zou zijn.

Alvast wat nadelen waar het tegen op moet wegen:
- Leesbaarheid met tekstbrowsers verlaagt.

GoT kent een relatief hoog percentage dat weleens Linux gebruikt. Ik kan het me voorstellen wanneer iemand vanaf de linux console toch og even iets wil opzoeken. Daarom behoorde Lynx in ieder geval tot de browsers waarin ik vond dat het forum toegankelijk moest zijn (bij het opzetten van de markup voor de nieuwe templates).

- Snelheid van "tekstonly" interfaces gaat omlaag (pda's via gprs enzo).

2KB per plaatje. Dat is nogal wat voor zo weinig informatie.

- Extra serverload voor elk plaatje dat gegenereerd moet worden.

Dat zou ik zo niet weten, zulke dingen laten we lekker aan de serveradmins over

- E-mailadressen worden niet meer door onze searchengine geindexeerd.

En geef dan de voordelen van "een willekeurig e-mailadres-rewriter" en daarbovenop de voordelen van een "afbeeldings-e-mailadres-rewriter". Vooral de extra voordelen van die laatste stap zie ik niet zo goed.

Volgens mij is zoiets veel leesbaarder en handiger:
<span class='first'>naam</span><span class='at'>@</span><span class='last'>iets.nl</span>
wat dus dit oplevert: <span class='first'>naam</span><span class='at'>@</span><span class='last'>iets.nl</span>
Knappe spambot die daar nog een e-mailadres uit weet te halen, terwijl het precies hetzelfde leest als een daadwerkelijk e-mailadres. En uiteraard zijn daar allerlei varianten op mogelijk.

Ik heb ooit eens zelf een groot deel van een DOM implementatie geschreven, en die zou dat nog wel te pakken krijgen. Met Node.textContent en een entity resolver.
Maar DOM is zo verrot zwaar om alleen maar naar wat e-mail adressen te zoeken, dat ik denk dat het veel efficienter is om gewoon in platte tekst te zoeken naar patronen.

Mijn belangrijkste argument tegen:
Hoevaak wordt dit nu helemaal gebruikt? En In welke fora wordt dit veel gebruikt? En hoeveel zoekmachines hebben toegang tot die fora?

[ACM]

Bolk schreef op 18 april 2004 @ 11:43:
Ehm, ja, die gebruikt iedereen dagelijks. Sorry, maar dit vind ik niet echt een sterk argument.

Dat het geen sterk argument is, maakt het nog niet geen argument.

Daar zit wel iets in, maar zou toch graag weten om hoeveel procent het van de pageviews gaat hier.

Ik had het niet eens genoemd, maar ook de algemene rendersnelheid gaat omlaag als er onnodige plaatjes worden gebruikt. Veel zal je er met een snelle verbinding en een snelle PC niet van merken, maar hoe langzamer een van die twee hoe erger de vertraging is.

Ga me niet vertellen dat die gigantische farm geen statische content kan genereren.

Dat is de argumentatie omdraaien, er is serverpower dus moeten we er maar wat mee doen. Zo breng jij het.
Ik ben echter van mening dat we de servers niet nodeloos moeten belasten en zolang een dergelijke uitbreiding geen nut heeft bovenop eventuele andere oplossingen zie ik het als nodeloos. Overigens is het dynamische content.

Overigens komt niet in elke post (topic zelfs) een email adres voor, dus de servers zouden het nieteens merken imho.

Nog een reden om er niet te veel tijd aan te verspillen

Verwijderd schreef op 18 april 2004 @ 11:59:
Ik heb ooit eens zelf een groot deel van een DOM implementatie geschreven, en die zou dat nog wel te pakken krijgen. Met Node.textContent en een entity resolver.
Maar DOM is zo verrot zwaar om alleen maar naar wat e-mail adressen te zoeken, dat ik denk dat het veel efficienter is om gewoon in platte tekst te zoeken naar patronen.

Ik denk inderdaad niet dat het vaak voorkomt dat een e-mailscanner de complete html gaat lopen parsen en dan ook nog es de losse innerhtml's gaat samenplakken tot tekst om dat dan weer te scannen op e-mailadressen.
Dus de kans is dan groter dat iemand een 'got-only' scanner maakt en daar wapen je je toch niet tegen, ook niet met plaatjes voor e-mailadressen die zijn imho net zo makkelijk te achterhalen als de domstructuur aflopen.

Mijn belangrijkste argument tegen:
Hoevaak wordt dit nu helemaal gebruikt? En In welke fora wordt dit veel gebruikt? En hoeveel zoekmachines hebben toegang tot die fora?

Volgens mij wordt het vrij zelden gebruikt, dat is mijn voornaamste argument om er geen tijd aan te verspillen.

Mensen die zich specifiek op GoT richten voor e-mailharvesting hou je toch niet tegen, hoewel die zich natuurlijk vooral op de profielen zullen richten. En een beetje verstandig met e-mailadressen omgaan voorkomt het ergste spamharvesting wel, voor zover die uberhaupt al got afgrazen.

[m-m]

ACM schreef op 18 april 2004 @ 10:38:
Ok nog es:
Ja, het is programmeertechnisch mogelijk, so what?
De vraag is niet of het mogelijk is, maar of het wenselijk is. Ik zie niet waarom en heb nog geen argumenten gezien waarom het wenselijk zou zijn.

Alvast wat nadelen waar het tegen op moet wegen:
- Leesbaarheid met tekstbrowsers verlaagt.

Niet relevant - Er zullen wel eens mensen even snel een oplossing zoeken via lynx/links op een probleem dat ze hebben - hebben ze daar ooit een email adres bij nodig?
En als ze het email-adres van iemand nodig hebben is dit in het profile voor hen ook al onleesbaar. Verder zat er in het voorbeeld dat ik noemde een alt= tag verwerkt die het email adres met (at) alsnog zichtbaar maakt voor lynx-gebruikers.

- Snelheid van "tekstonly" interfaces gaat omlaag (pda's via gprs enzo).

Dat is ee valide argument, alleen is GoT imho sowieso niet echt goed geschikt voor dat soort gevallen. Als de langbeloofde PDA template er is is er vast wel een mogelijkheid om daarin geen plaatjes te tonen maar een automatisch gegenereerd (at) (dot)-adres.

- Extra serverload voor elk plaatje dat gegenereerd moet worden.

Lijkt mij te overzien, zeker omdat er niet constnat email adressen worden gepost en het nou niet echt zwaar werk is.

- E-mailadressen worden niet meer door onze searchengine geindexeerd.

Dit werkt ook niet goed als iedereen zelfverzonnen manieren gebruikt om emailadressen te vernaggelen.

En geef dan de voordelen van "een willekeurig e-mailadres-rewriter" en daarbovenop de voordelen van een "afbeeldings-e-mailadres-rewriter". Vooral de extra voordelen van die laatste stap zie ik niet zo goed.

- Leesbaarheid
- Duidelijkheid (Niet iedereen begrijpt wat er bedoeld wordt als er moet worden gemailed naar "gathering tweakers net". OK- dat zijn toch domme users die je niet wilt - maar tis wel zo )
- Veilig tegen spam

Volgens mij is zoiets veel leesbaarder en handiger:
<span class='first'>naam</span><span class='at'>@</span><span class='last'>iets.nl</span>
wat dus dit oplevert: [e-mail]
Knappe spambot die daar nog een e-mailadres uit weet te halen, terwijl het precies hetzelfde leest als een daadwerkelijk e-mailadres. En uiteraard zijn daar allerlei varianten op mogelijk.

Dat zou ook kunnen ja. Dit zou dan ook in het profile mogelijk zijn.

[crisp]

eens over nadenken; we kunnen vast wel iets met een custom tag doen en wat obfuscating - de uiteindelijke verantwoordelijkheid dient echter wel bij de user te liggen vind ik

[crisp]

ik heb even kort-door-de-bocht zoiets gemaakt:

[e-mail]

dit levert op:
[e-mail]

code:

<span>crisp</span><span>@</span><span>tweakers.net</span>

is dat wat?

[Spider.007]

ziet er goed uit Wat gebeurt er als je [email=a,b,c] intikt? Zit er een regex op de input of is het echt kort-door-de-bocht?

[crisp]

Spider.007 schreef op 25 juli 2004 @ 18:34:
ziet er goed uit Wat gebeurt er als je [email=a,b,c] intikt? Zit er een regex op de input of is het echt kort-door-de-bocht?

c wordt dan genegeerd; het is echt kort-door-de-bocht

[Osiris]

En wat als een harvester sowieso alle HTML-tags wegpleurt en urldecode gebruikt? ACM had hierboven <span class='at'>.. En als het goed is heeft CSS de mogelijkheid om een bepaalde string vóór de context te zetten, wat in dit geval niets hoeft te zijn (<span class='at'></span>). Vervolgens gebruik je in je CSS:

Cascading Stylesheet:

.at:before {content: "@"}

Nóg iets beter wellicht?

[crisp]

Osiris schreef op 25 juli 2004 @ 21:07:
En wat als een harvester sowieso alle HTML-tags wegpleurt en urldecode gebruikt? ACM had hierboven <span class='at'>.. En als het goed is heeft CSS de mogelijkheid om een bepaalde string vóór de context te zetten, wat in dit geval niets hoeft te zijn (<span class='at'></span>). Vervolgens gebruik je in je CSS:

Cascading Stylesheet:

.at:before {content: "@"}

Nóg iets beter wellicht?

Tsja, en die 80% IE gebruikers dan?

[Osiris]

crisp schreef op 25 juli 2004 @ 21:12:
[...]

Tsja, en die 80% IE gebruikers dan?

Niet eens aan gedacht

Nou ja, ik geef het op

[crisp]

we zien wel gewoon of het bevalt, aanpassen kan later altijd nog

en zoals ik al eerder zei: gebruik blijft op eigen risico. vertrouw je het niet - pas dan je eigen obfuscating toe.

[ Voor 48% gewijzigd door crisp op 26-07-2004 00:41 ]