zlacker

Here's another reasonable summary:

https://www.revsys.com/tidbits/greet_pause-a-new-anti-spam-f...

I get several thousand SPAM attempts per day: I estimate that this one technique kills a large fraction of them. And look how old the feature is...

>>DamonH+(OP)
Okay, so the requests do get rejected, it just uses a delay to make that decision.

I don't consider GreetPause to be a form of shadow moderation because the sender knows the commands were rejected. The issue with shadow moderation on platforms is that the system shows you one thing while showing others something else.

Legally speaking, I have no problem with shadow moderation. I only argue it's morally wrong and bad for discourse. It discourages trust and encourages the growth of echo chambers and black-and-white thinking.

>>rhaksw+E
How do you view the rest of typical SPAM filtering, where the mail is apparently accepted for delivery but then silently thrown away? For simplicity assume a system such as mine where I control the MTA and client, so no one is making decisions hidden from me as the end user who wants to get the ham and see no SPAM. (I get tens of ham per day and many many thousands of SPAM attempts.)

>>DamonH+c2
With spam email, the recipient has a chance to recover the mail by looking in their spam folder.

No such spam folder is provided to the public on social media.

>>rhaksw+F2
Note that in the GreetPause case the SPAMmer will not see the rejection errors since they don't look at the response to their hit and run (ie no one gets to see any error, neither sender nor target), and a legitimate sender should never get the error, so even this may be messy by your criteria I think!

>>DamonH+54
> even this may be messy by your criteria I think!

Only if the recipient sent a false response.

If the response were misrepresented then I would object to the technique. But it doesn't sound like that's what happens.

>>rhaksw+v6
OK, thanks!