Built in Anti-SPAM

[wdc 0]

Please allow user to add bad words and or bad IPs and if contained in the private messages, such messages will not appear or be closed by the ApexDC. I am spammed from various users and this can help, i have not found any tutorial on how to get rid of the SPAM based on message content or IP.

[Mek 13]

Hello, it is a nice idea that would be welcome by others too I am sure.

Anyway, if you get spammed, maybe you could contact hub owners/operators to deal with the spam by banning the IPs and users?

[wdc 0]

22 hours ago, Mek said:

you could contact hub owners/operators to deal with the spam by banning the IPs and users?

atm i am connected to the 81 hubs and spammer to 9 hubs. IP is known to change, i could contribute alot of time trying to discover who is the hub operator and trying to repeatedly ask them, i already did, and never got response, this is not good advice.

I can not understand how *DC++ SW can be left without some solid antispam/ban solution. I do not want to disable personal messages (i assume i can not!) as i think they are important tool to communicate with users. Also it would be helpful if i at least see the IP of that spammer but his IP is empty.

Edited April 12, 2017 by wdc

[Mek 13]

IP is empty because hub does not send it. The vast majority of hubs does that to conserve bandwidth. You can find out the IP only if you connect to the user (e.g. by downloading filelist), but most probably you won't be able to connect to that user either because those are often bots programmed solely for spamming and not supporting P2P connections.

You cannot block PMs, but you can have them open in a non-focused window by default so a PM does not popup while you are in the middle of doing other stuff. You can also put a user to ignored users, but that is useless if his nick is changing. Sadly, that are all your options.

[Crise 26]

I have actually recently though about this type of feature. However, pattern and IP matching will only result in a never ending game of cat and mouse.

As such the only reasonable compromise I can think of (which can not be circumvented by script and bot authors) is to provide an option to ignore all PM's from particular type of hubs that are not from privileged users (ie. operators) or potentially users you have chosen to exclude by adding them as a favorite user.

The problem with above though, is that it is quite a binary choice and can not be configured very well (at the same time, I am not interested in adding a feature that matches Nicks and IP's because of things already mentioned here).

At the end of the day preventing bots from getting into a hub in the first place is obviously a hubs responsibility and whatever a client can do is only ever a band aid.

[wdc 0]

Thx Crise & Mek. It might be cat and mouse game, but at least there would be a way to reduce spam.

Often spammer is using hyperlinks and that is not that easy for them to change domains they promote.

PS: for those that are bothered by SPAM, here is what im doing now to get rid of this issue:

set ApexDC not to popup private messages in new tabs and leave them in hub tab so this way i ignore all private messages so no one can get in touch with me unfortunately (i do not monitor all 80 hubs terminals). (Settings/Appearance/Windows/Window options), at least my work is not distracted by spam and my time not wasted by closing excessive amount of spammer private messages tabs.

[Crise 26]

Just as an general comment... running ApexDC, or any DC client, with 80 hubs open is not really a typical use case. Or rather it wasn't one when these applications where created. So they really can't deal with volume efficiently, regardless of whether PM's are spam or legitimate messages.

The UI is (or rather was originally) designed in such a way that the user is expected to only open a number of hub connections they can manage manually, which is why there is no real degree of automation in many places when it comes to managing any aspect of the UI.

To put it in another way, DC really is not a general purpose file sharing application, as it was never designed to reach a large volume of content at once. Rather it was designed to reach a type of content aggregated by getting like-minded users together, you could say quality over quantity I guess (hence why it has chat featured at least equally if not more prominently than file sharing capabilities).

As a bit of a history lesson, the original incarnation of DC was intended as an IRC replacement with a more user friendly interface for sharing files, as using IRC for sending files or using file servers is a bit of a mystic art in itself (and certainly mostly a lost one at that these days). Apart from that the original DC client, out of which DC++ and its many variants were initially reverse engineered from, could only connect to one (1) hub at a time. For more on the history of this thing, look here. Not that it is really good for anything but an interesting retrospective in today's context as the DC of today is completely different from that, but some parts of it still show today, in particular in the way the applications remain structured to this day.