Re: [Tiki-devel] Disposable email detector

Just a little more before i get on to what i was supposed to be doing - there's a good api which seems free to use, so i set up a web service on a very spammed tiki, using this as the url:

    https://api.stopforumspam.org/api?json&email=%email%

and it seems to return very good results, so i'm wondering what the next steps would be?

An easy option would be to add a validator to the registration form to prevent blacklisted emails registering, but then they'd just keep using other emails until they find (or create) a clean one, so maybe pretending their registration was successful but immediately banning them would be better?

Anyway, just thought i'd share this, i'd also like to add a way of reporting spammers back to stopforumspam.org to share the joy, but sadly i think it's too late now for any new code like this for 25.0 (but maybe 25.1)

jonny



> On 2 Nov 2022, at 10:29, Jonny Bradley via TikiWiki-devel <[email protected]> wrote:
> 
> Hi all
> 
> Been fiddling on with this a bit (is it just us or has the spam deluge increased recently for everyone?)
> 
> That list on GitHub is indeed very incomplete so i've been looking for better ones and this site seems quite interesting
> 
>    https://www.stopforumspam.com
> 
> Has anyone else used it? Will investigate further, but seems like they're doing a good job (and is free)
> 
> jonny
> 
> 
> 
> 
>> On 28 Oct 2022, at 17:55, Jonny Bradley via TikiWiki-devel <[email protected]> wrote:
>> 
>> Hi Benoit
>> 
>> Thanks, shame... but i committed it and pushed it quickly as i won't have any further time before 25.x is branched, so was hoping we can polish it after that for 25.0 (and thereafter).
>> 
>> The initial use for it i see is not sending mailshots and newsletters to these addresses to save costs and bandwidth (and energy), i think banning them would be a bit extreme but could be added as an option.
>> 
>> That library is pretty minimal but you can use any list you want, so if someone wanted to find or maintain a better one it could work with that too.
>> 
>> If there are still significant objections i'll remove it.
>> 
>> jonny
>> 
>> 
>> 
>> 
>>> On 28 Oct 2022, at 16:11, Benoit Grégoire <[email protected]> wrote:
>>> 
>>> On Thursday, October 27, 2022 11:01:23 A.M. EDT Jonny Bradley via TikiWiki-devel wrote:
>>>> Hi all
>>>> 
>>>> I've just spent the morning with a client trying to clean out spam from his
>>>> site and we're finding he's getting several registrations an hour by people
>>>> using disposable/temporary email addresses, which i didn't really know much
>>>> about before investigating.
>>>> 
>>>> I think it would be a useful thing for tiki (and tiki.org) to be able to
>>>> detect these and either list them on the user admin (because there's no
>>>> point emailing them), or block them from registering completely.
>>>> 
>>>> I've found an MIT licensed php library here which i might be able to sneak
>>>> in to 25.x before we branch but just thought i'd see what others think
>>>> about this?
>>> 
>>> I'm afraid it wouldn't help significantly, if at all :(
>>> 
>>> There have been such services for at least 2 decades, and people trying to list them for just as long.  They usually just generate unrealistic expectations on the part of administrators.
>>> 
>>> Using such lists will, in practice, block SOME actual humans using such services.  Usually not bots which tend to use their own domains (or hijacked ones). 
>>> 
>>> That specific list (https://github.com/disposable-email-domains/disposable-email-domains/blob/master/disposable_email_blocklist.conf) is updated quite infrequently compared to, for example, spam blocklists.  And that's assuming we actually code a cron script to keep it updated.
>>> 
>>> Modern temp mail services provide an address from a random domain picked in a list that they don't enumerate (to make anti-temp email blocking difficult).  Static lists will never be effective.
>>> 
>>> I tried the first 4 google results for "temporary email address", they all generated email addresses that weren't in the list above.  0 out of 4...
>>> 
>>> There are paid services that are possibly more effective at detection. 
>>> 
>>> But in practice, using CAPCHAS is probably the only somewhat effective mitigation.
>>> 
>>> --
>>> Benoit Grégoire
>> 
>> 
>> 
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> 
> 
> 
> _______________________________________________
> TikiWiki-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



_______________________________________________
TikiWiki-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel