I wonder if there is a reason not to put $encode instead of $text on lines 144 and 147 of the invisimail.module 1.3.2.1 2008/06/13 22:26:41.
I know this doesn't add too much protection, but at least after this modification the 'smth@smth.smth' pattern is not present in cleartext in the HTML source, and HTML entities decoding is required.
I did this modification in my installed module, and FF3 rendering isn't hampered by this, so I suppose other browsers will also have no problems seeing entities between the open/close anchor tags...
I'm attaching the full modified file.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | invisimail-5.x-1.0.patch | 841 bytes | tetramentis |
| #2 | invisimail-5.x-1.x-dev.patch | 716 bytes | tetramentis |
| #2 | invisimail-6.x-1.x-dev.patch | 716 bytes | tetramentis |
| invisimail.module.zip | 2.5 KB | tetramentis |
Comments
Comment #1
Crell commentedI'm afraid a full modified module is rather useless for patching. Please provide a proper patch against a supported dev release. (At the moment, that's just the D6 branch.) See: http://drupal.org/patch/create
Comment #2
tetramentis commentedI've created patches for all 3 versions currently available for download, including the 6.x-dev version.
After this modification the 'smth@smth.smth' e-mail pattern is no longer present in cleartext in the HTML source, and HTML entities decoding capability is required for the spam bot to process such an email. Before the patch, when JS-encoding was turned on together with 'automatically generate links', the 'smth@smth.smth' e-mail pattern was written as-is to the HTML source of the page, providing absolutely no protection.
Comment #3
Crell commentedCommitted to both the 5.x and 6.x dev versions. Thanks.