Puedo confirmar que la solución original funcionó perfectamente y resolvió este problema con los correos de Gmail. Sería un salvavidas real si se restableciera este modo opcional.
Los spammers están aprendiendo constantemente nuevas técnicas y aún están burlando con éxito a grandes jugadores como Facebook, Instagram y Twitter. Esto convierte a la mayoría de los demás lugares en “modo fácil”. Para muchos de ellos, esto es un trabajo a tiempo completo, por lo que esencialmente se convierte en:
Si es explotable y (recursos requeridos < dinero ganado), entonces será explotado.
Pueden eludir prácticamente cualquier medida; la única esperanza es aumentar los costos hasta que deje de ser rentable hacerlo.
Poder enviar spam masivo con correos/cuentas casi ilimitados (antes de la detección y el bloqueo retroactivo de su Gmail canónico por parte de un moderador/admin, junto con la eliminación manual de sus publicaciones) es bastante eficiente en cuanto a costos. Más aún si no hay un equipo de moderadores 24/7.
El costo para eludir las medidas antispam sigue disminuyendo. Un ejemplo son los proxies 4G/5G; por algo como 30-50 dólares al mes, las personas pueden acceder a IPs móviles reales prácticamente ilimitadas, de proveedores de servicios de internet (ISP) o sistemas autónomos (ASN) legítimos que rotan automática o manualmente y son compartidos por ciudades o estados enteros de usuarios legítimos de grandes ISPs. Las IPs 4G/5G son compartidas por muchos usuarios simultáneamente.
Bloquear estos ISPs/ASN o IPs no es adecuado (no se puede simplemente bloquear a todos los que usan Verizon, AT&T, etc.). Generalmente usan la IP una vez y la desechan. Las IPs individuales bloqueadas de este grupo también bloquearán a usuarios legítimos que estén compartiendo esa dirección IP al azar. El bloqueo de IPs se está volviendo lentamente una práctica obsoleta (excluyendo los ASN de empresas de hosting conocidas). Puedes ver la punta del iceberg en estos foros:
https://mpsocial.com/c/public-marketplace/61
https://www.blackhatworld.com/forums/proxies-for-sale.112/
Creo que los spammers son una mezcla de bots totalmente o parcialmente creados a mano y spam manual. A medida que Discourse capture más cuota de mercado, lo cual claramente está creciendo de manera fantástica, me sorprendería si no se convierte en un objetivo de bots comercialmente disponibles.
Cada vez que Xrumer comience a soportar la última versión de reCAPTCHA, diría que la mayoría de los webmasters en foros legacy notarán un gran aumento en el spam debido al costo ridículamente bajo del spam (ya no es necesario usar una API de resolución de captcha, que ya son muy baratas por cada 1k de resoluciones):
http://botmasterlabs.net/buy1/
La gente ya puede crear sus propios plugins/scripts para soportar prácticamente cualquier plataforma usando Xrumer. Pero si algún día soportan Discourse de inmediato:
No puedo afirmar ser imparcial en esto, ya que tengo una necesidad directa de medidas antispam. El post original sobre el truco del punto en Gmail fue creado por otra persona en 2014 y parece que otro usuario resolvió esto requiriendo aprobación para las primeras x publicaciones, así que quizás haya al menos tres reportes de usuarios. 
Perdón por la desviación, volvamos al tema.
En cuanto al bloqueo por regex para correos electrónicos, sí, tienes razón. Es una solución parcial, pero no ideal por estas razones:
Si bloqueas todos los Gmail con 1 punto o más antes de @:
- Bloquearás inevitablemente a usuarios legítimos de Gmail que tengan 1 o más puntos en su correo, lo cual es muy común.
- Los spammers aún pueden crear muchas variaciones con un solo punto. Por ejemplo, Gmail tiene una longitud máxima de 30 caracteres, por ejemplo: 12345678901234567890123456789.0@gmail.com tendrá 30 combinaciones utilizables con un solo punto.
Si bloqueas todos los Gmail con 2 puntos o más antes de @:
- Se bloquearán menos correos legítimos, pero aún así se bloquearán usuarios legítimos de Gmail que tengan más de 1 punto en su correo.
- Los spammers pueden crear muchas más variaciones con un solo Gmail de 30 caracteres. Creo que unas 842 combinaciones o así.
Puedo confirmar que las nuevas cuentas llegaron después de que el bloqueo estuviera activo, ya que la fecha de creación del bloqueo es el 1 de febrero. Estaba observando la creación de nuevas cuentas ayer mientras veía ambos casos: la regla de bloqueo teniendo nuevas coincidencias recientes, así como nuevas registraciones entrando usando combinaciones del mismo correo (solo puntos).
Desactivé los registros durante la noche y los volví a activar esta mañana. Han creado 104 nuevas cuentas hasta ahora hoy con permutaciones de esa dirección de Gmail y continúan registrando más. Puedo confirmar que una vez que se eliminan los puntos de los correos de estas cuentas, es una coincidencia exacta con el registro bloqueado de Correos Filtrados.
Intenté probar los bloqueos en rails c como se describió; aquí es donde se pone un poco extraño.
Parece que algunos registros están devolviendo ‘true’ como se esperaba y otros están devolviendo ‘false’, incluso si el correo probado es una coincidencia exacta con el correo canónico bloqueado. Para los registros que devuelven ‘true’, funcionó exactamente como se esperaba y devolvió true para todas las variaciones que probé. Pero para los correos que devuelven false, todas las variaciones que probé también devolvieron false.
Estaba tratando de encontrar alguna correlación. Puedo confirmar que estos no están correlacionados (o al menos no consistentemente):
Longitud del correo (antes de @)
Correo que contiene caracteres y números
Coincidencias (cantidad de veces bloqueado)
Fecha de coincidencia
Parece que sí hay una correlación con la fecha de creación del bloqueo, siendo los más antiguos menos propensos a funcionar (devuelven false). Los registros creados hace 9 días devolvieron una mezcla de true/false, y todos los registros que he probado hasta ahora que fueron creados antes de eso (de 1h a 8d) están devolviendo true.
¿Podría estar relacionado con ‘máxima antigüedad de correos no coincidentes’? Creo que esta opción es algo nueva; la tengo configurada con el valor predeterminado de 365 días.