Registro e validação do contato de abuso

Idioma Original Español Data Publicação 05/03/2018 Última Modificação 25/04/2019
Período de últimos comentários Não aplicável Data de ratificação Não aplicável Data de implementação Não aplicável
Estado Em discussão Baixar TXT PDF XML DOCX
Ver outras versões 1.0 2.0 3.0 4.0 5.0 (comparar)

Autores

Nome: Jordi Palet Martinez
E-mail: jordi.palet@theipv6company.com
Organização: The IPv6 Company

Dados da Proposta

Tipo Política: LACNIC
Id: LAC-2018-5
Última versão: 5
Apresentações:

Resumo

La propuesta permite garantizar y validar los contactos de abuso del WHOIS (abuse-c y abuse-mailbox) de las organizaciones y poder así reportar los casos de abuso y resolverlos.

Esta propuesta pretende resolver el problema y garantizar la existencia de un contacto abuse-c correcto y el proceso para su uso.

Justificativa

La política actual (ASN) no es clara en cuanto a la obligación de registrar un contacto de abuse (abuse-c) ni al formato específico y si aplica a otros casos de registros en el WHOIS.

Como consecuencia, puede haber receptores de recursos de LACNIC que no tienen dicho contacto registrado para sus recursos, o incluso hay casos de LIRs/ISPs, usuarios finales, u otros, que utilizan un buzón de correo inexistente o que no está activamente monitorizado.

La falta de validación de los contactos ha vuelto ineficaz el reporte de casos de abusos, generando problemas de seguridad y costes para las víctimas.

Para tratar de resolver este problema, se plantea una sencilla verificación periódica del contacto de abuso, evitando así costes innecesarios a terceras partes.

La propuesta garantiza que el coste de procesar los abusos recaiga sobre el receptor del recurso que, quién directa o indirectamente (su cliente y del cual recibe posiblemente compensación por el servicio), es responsable del abuso, en lugar de recaer sobre la víctima. Téngase en cuenta que ello evita el posible agravamiento, tiempo y gatos judiciales para ambas partes si se acude a dicha instancia.

Para ello, el atributo abuse-c, que hasta ahora sólo estaba referenciado para el objeto “aut-num”, se hace obligatorio en los objetos “inetnum” (tanto para IPv4 como para IPv6), y cualesquiera puedan surgir en el futuro. Este atributo es un contacto de abuso, que contendrá como mínimo el atributo “abuse-mailbox”.

Texto

Texto actual:

No existe

Nuevo texto:

12. Registro y Validación de “abuse-c” y “abuse-mailbox”

12.1. Descripción del “abuse-c” y “abuse-mailbox”
Todos los recursos que utilicen los sistemas de registro de LACNIC deben incluir obligatoriamente, en las entradas de WHOIS correspondientes, el atributo de contacto abuse-c (contacto de abuso), como mínimo con un email abuse-mailbox válido, monitorizado y adecuadamente atendido, que permita enviar reportes manuales o automáticos de comportamientos abusivos, seguridad, y similares.

El atributo abuse-mailbox debe estar disponible sin restricciones vía whois, APIs y futuras tecnologías.

Teniendo en cuenta la naturaleza jerárquica de los objetos, los heredados de aquellos distribuidos directamente por LACNIC (por ejemplo, sub-asignaciones), estan cubiertos por los objetos de nivel superior y su propio atributo “abuse-c” es opcional.

Siguiendo prácticas habituales, otros atributos “email” pueden ser incluidos para otros propósitos.

12.2. Características del “abuse-mailbox”

Los emails enviados a “abuse-mailbox” deben requerir intervención manual en algún momento, por parte del destinatario, y no pueden estar filtrados, ya que ello podría impedir, en algunos casos, la recepción de un reporte de abuso. Por ejemplo, un reporte de spam, al incluir el propio mensaje de spam o URLs o contenidos habitualmente clasificados como spam.

El buzón “abuse-mailbox” podrá devolver inicialmente, una respuesta automática, por ejemplo, asignando un número de ticket, aplicando procedimientos de clasificación, pidiendo más información, etc. Sin embargo, no podrá requerir el uso de un formulario, ya que ello implicaría que cada entidad que necesite reportar abusos, generalmente de forma automatizada, se vea obligada a desarrollar una interfaz específica para cada receptor de recursos al que tiene que reportar un abuso. Ello sería inviable, ya que haría recaer el coste del procesado de los abusos en el que envía la reclamación, víctima del abuso, en lugar de sobre aquel que (directa o indirectamente) causa el abuso.

Lo razonable, es que quien informa del abuso, lo haga en el primer reporte, enviando información suficiente (log, copia del spam o cabeceras completas, lo equivalente en cada tipo de abuso). Igualmente, es razonable que el email inicial de auto-respuesta indique que, si no se ha enviado dicha información, no será atendido, dando así la oportunidad a repetir el envío con las pruebas procedentes. Esto permite reportes automatizados, por ejemplo, mediante fail2ban, SpamCop u otros, con mínimo coste para ambas partes. Habitualmente, cabe esperar que, si se ha asignado un número de ticket, el mismo sea mantenido en todas las comunicaciones (típicamente como parte del asunto).

12.3. Objetivos de la validación del “abuse-c”/“abuse-mailbox”

El procedimiento, que habrá de ser desarrollado por LACNIC, deberá cumplir con estos objetivos:

1) Garantizar su funcionalidad y permitir a los “helpdesk” que atienden los reportes de abuso, la verificación de que la validación efectivamente proviene de LACNIC y no de terceras fuentes (implicando riesgos de seguridad, evitando, por ejemplo, una única URL “directa” para la validación).
2) Impedir un proceso exclusivamente automatizado.
3) Confirmar que quien valida:
• asegura conocer el procedimiento y las políticas de LACNIC
• monitoriza regularmente el “abuse-mailbox”
• toma medidas al respecto
• responde al reporte de abuso.
4) Plazo de validación “inicial” de 15 días.
5) Si no se valida correctamente, “escalado” con el resto de los contactos disponibles, en un plazo “adicional” de 15 días.

Los plazos de validación podrán ser modificados a criterio de LACNIC, informando a la comunidad de los motivos.

(a título de recomendación, se propone un procedimiento detallado en “información adicional” de esta propuesta de política)


12.4. Validación del “abuse-c”/“abuse-mailbox”
LACNIC validará el cumplimiento de la política de forma periódica, al menos dos veces al año, y cuando se creen o modifiquen los atributos del “abuse-c”.

La frecuencia de validación podrá ser modificada a criterio de LACNIC, informando a la comunidad de los motivos.

12.5. De los incumplimientos

El incumplimiento por parte de cualquier organización se produce si no se ha validado en el plazo “inicial” ni “adicional”. Ello implicará el bloqueo de MiLACNIC y medidas equivalentes en los sistemas de los NIRs, para todos los recursos asociados con dicha organización. Quedan exceptuadas las cuestiones exclusivamente contractuales y relacionadas con pagos, así como la actualización de los contactos abuse-c/abuse-mailbox, de tal forma que puedan ser automáticamente re-validados para permitir el desbloqueo de MiLACNIC.

Cualquier acceso a MiLACNIC (o sistemas equivalentes de los NIRs), durante dicho bloqueo, mostrará un mensaje de advertencia, incluyendo el texto de esta política, y para permitir continuar será necesario que dicho mensaje sea “leído” hasta el final, y se confirme mediante un check-box o similar. Se podrán utilizar mecanismos equivalentes adaptados al avance de la tecnología.

De mantenerse el incumplimiento, LACNIC actuará de conformidad con sus políticas y procedimientos pertinentes.


12.6. Mecanismo de escalado a LACNIC

Comportamientos fraudulentos (por ejemplo, “abuse-mailbox” que solo responden a emails de LACNIC, a determinado asunto o determinado cuerpo del mensaje), o el incumplimiento del resto de los aspectos de esta política (la incorrecta o no atención de los casos de abuso), podrán ser reportados a LACNIC, para su re-validación según 12.4.

Información adicional:

Nota (no debe ser incluida en el manual de políticas): La sección actual “12. Apéndices” pasa ser “A. Apéndices”, al final del manual de políticas, y se renumera en todo el manual de políticas, todas las referencias a ella. De este modo, nuevas secciones del manual, no requieren futuras renumeraciones, según el manual vaya “creciendo”. El texto de esta propuesta pasa por lo tanto a ser la sección 12, o la que considere oportuna el staff en el momento de su implementación, una vez alcanzado el consenso.

El texto siguiente es un ejemplo de procedimiento de validación, considerando prácticas habituales en los “helpdesk” (mesas de ayuda), que por ejemplo impiden clicar en un enlace html de un email, para evitar casos de phishing u otros. Aun cuando este texto no es parte del texto de la política, se recomienda su estricta consideración, dado que es resultado de discusiones relacionadas con políticas de abuse-c en la comunidad global.

1) La validación se inicia de forma automatizada, por parte de LACNIC, con el envío de DOS emails consecutivos al “abuse-mailbox”.
2) Dichos emails tendrán exclusivamente formato texto (y por tanto ocultar URLs que correspondan a ataques como “phishing”, etc.).
3) A criterio de LACNIC, de forma generalizada o en casos puntuales (por ejemplo para la confirmación en casos de escalado según el 12.6), LACNIC podrá utilizar dominios diferentes a lacnic.*, e incluso modificar el asunto y cuerpo del mensaje, para realizar dichas validaciones de forma mas eficaz.
4) El primero de los emails contendrá la URL donde debe realizarse la validación, que será “validacion.lacnic.net”, y podrá contener información respecto del procedimiento, extracto de esta política, etc.
5) El segundo de los emails contendrá un código alfanumérico único de validación.
6) El receptor que atiende el “abuse-mailbox”, deberá acceder a la URL y pegar en el formulario el código recibido en el segundo email.
7) Dicha URL, deberá estar diseñada de tal forma que impida un proceso automatizado (por ejemplo, “captcha”), y contendrá un texto que confirme que el receptor de la validación conoce el procedimiento, la política y que monitoriza de forma regular el “abuse-mailbox” y se toman medidas apropiadas para resolver los abusos reportados y responder a los mismos, con un “checkbox” que necesariamente deberá ser aceptado.
8) El código alfanumérico sólo será válido durante un máximo de 15 días.
9) Si el código no es introducido en ese plazo, el sistema marcará el “abuse-c” como “provisionalmente inválido”, y alertará al staff de LACNIC para que se pueda iniciar el seguimiento personalizado con el receptor del recurso.
10) En caso de no obtener una respuesta, con la confirmación de la corrección de la situación, en un plazo adicional de 15 días, el “abuse-c” será marcado de forma permanente como “inválido”.
11) Se repetirá de forma automática el proceso de validación (puntos 1 al 7 anteriores), y en este caso, el “abuse-c” será marcado como “válido” en caso satisfactorio, o en caso insatisfactorio, se trataría de un caso de incumplimiento de la política.
12) LACNIC contará con mecanismos (formulario, correo electrónico y otros en el futuro) para facilitar el escalado en los casos en los que se quiera reportar un incumplimiento de esta política. Ello permitirá la re-validación (12.4) y la intervención de LACNIC en aplicación de las políticas, procedimientos y requisitos contractuales vigentes.

Informações Adicionais

Tiempo de Implementación:

90 días, de forma prudencial y a confirmar con LACNIC, para permitir tanto al staff el desarrollo de la herramienta, como a los receptores de recursos de LACNIC actualizar sus contactos abuse-c. LACNIC podrá enviar un recordatorio con la ratificación de la propuesta por parte del Directorio.

Referencias:

En APNIC ha alcanzado consenso una versión equivalente a esta propuesta.

En RIPE se adoptó una propuesta similar pero solo de verificación automática, y el debate reciente de la lista, precisamente ha indicado la necesidad de hacerlo de forma “no exclusivamente automática”, pues el procedimiento actual permite numerosos engaños.

Además, se está tramitando una propuesta equivalente que será publicada en breve.

En AfriNIC y ARIN se ha presentado una propuesta equivalente.

Tempo de Implementação

90 días, de forma prudencial y a confirmar con LACNIC, para permitir tanto al staff el desarrollo de la herramienta, como a los receptores de recursos de LACNIC actualizar sus contactos abuse-c. LACNIC podrá enviar un recordatorio con la ratificación de la propuesta por parte del Directorio.

Referências

En RIPE se adoptó una propuesta similar pero solo de verificación automática, y el debate reciente de la lista, precisamente ha indicado la necesidad de hacerlo de forma “no exclusivamente automática”, pues el procedimiento actual permite numerosos engaños.

Además, se está tramitando una propuesta similar que será publicada en pocas semanas.

En APNIC ha alcanzado consenso una versión equivalente a esta propuesta.

En AfriNIC se ha presentado la misma propuesta.

Se prevé presentar una propuesta equivalente en ARIN.

Notas Públicas da equipe de LACNIC

ANALISE DE IMPACTO PELA EQUIPE DE LACNIC - Proposta LAC-2018-5 - versión 4

Interpretação da proposta pela equipe de LACNIC
-----------------------------------------------------

Aplicação da proposta
---------------------------
Esta proposta seria aplicada nos receptores de recursos de LACNIC para que registrem um contato de abuso válido para ASNs, IPv4 e IPv6.

Modificação do texto atual
----------------------------
A seção atual “12. Apêndices "passa a ser" A. Apêndices", no final do Manual de Políticas, e todas suas referências são atualizadas.

Serão acrescentadas as seções:
o 12. “Registro e Validação de "abuse-c" e "abuse-mailbox”
o 12.1 “Descrição do "abuse-c" e "abuse-mailbox”
o 12.2. “Características do "abuse-mailbox"
o 12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"
o 12.4. Validação do "abuse-c"/"abuse-mailbox"
o 12.5. Mecanismo de escalado para LACNIC

A nova versão acrescenta:
---------------------------
1. A sugestão da equipe que durante o bloqueio de Mi LACNIC também seja permitido acessar ao contato e à parte do pagamento em Mi LACNIC a pesar do incumprimento.

2. Melhorar a redação em algumas frases.

Comentários da equipe
----------------------
1. Mesmo que o Manual de Políticas não indique que o bloco IPv4 deva conter um contato de abuso, o sistema de LACNIC já suporta esta modalidade e os blocos IPv4, IPv6 e ASN já possuem este atributo. O mesmo acontece no caso das subdesignações, o abuse-c usado é o ponto de contato administrativo da organização que recebe a designação ou a subdesignação.

Foi feita uma consulta ao Banco de Dados de LACNIC sobre o registro dos contatos de abuso de cada tipo de recursos e os seguintes resultados foram obtidos:
- Número de recursos IPv4, IPv6, ASN com contato de abuso null ou vazio: 0
- Número de recursos legados IPv4 com contatos de abuso null ou vazio: 241
- Número de recursos legados IPv6 com contatos de abuso null ou vazio: 0
- Número de recursos legados ASN com contatos de abuso null ou vazio: 146

Portanto, atualmente não existe nenhum recurso que não seja legado com o contato de abuso vazio/null. Todos os que aparecem na BD com null/vazio sai legados.
2. LACNIC entende que isso não aplica para as organizações com recursos legados, já que nada é mencionado sobre esse tipo de organização.

3. Em relação ao seguinte texto: “Levando em conta a natureza hierárquica dos objetos, os herdados de aqueles alocados diretamente por LACNIC (por exemplo, subdesignações), são cobertos pelos objetos de nível superior e seu próprio atributo "abuse-c” é optativo”
LACNIC entende que isso significa que, no caso de subdesignações de endereços, o contato de "abuse-c" pode estar coberto pelo da organização de nível superior ou pelo de sua própria organização.

4. Observa-se que, para a implementação desta proposta, LACNIC precisará investir novos recursos para atender o acompanhamento de todos os casos que precisarem.
Recomendações
-------------------
5. Na seção 12.5 quando é apontado que “Se o incumprimento for mantido, LACNIC atuará de acordo com suas políticas e procedimentos pertinentes”:

5.1. Não é especificado como deverá proceder LACNIC. LACNIC interpreta que a violação desta política não determina a revogação dos recursos desde que foi eliminada na versão anterior. Se se pretende que o incumprimento desta política seja motivo de revogação, o autor deverá deixá-lo explícito no texto proposto.

5.2. Ao indicar “se o incumprimento for mantido (...) LACNIC entende que a seguinte verificação d incumprimento seria na segunda validação do ano.

6. É importante lembrar que a revogação de recursos é permanente, tem alto impacto nas operações das organizações e é um processo complexo. Por esse motivo, recomendamos que essa instância seja aplicada apenas quando todos os recursos sejam esgotados e tenha passado um prazo significativo após a irregularidade ser detectada.

7. Na seção 12.1 é indicado: “Todos os recursos alocados (…)”.
Recomenda-se trocar por: “Todos os recursos alocados e designados (…)”. Desta forma, procuramos manter a linguagem do Manual de Políticas, para indicar que "alocados" faz referência aos ISPs e "designados" aos Usuários Finais.

8. No ponto 5) da seção 12.3, LACNIC assume que o “escalado” seria com o contato administrativo da organização. Recomenda-se esclarecer a redação.

9. Recomenda-se que a proposta não defina prazos, mas determine ações e que os prazos necessários sejam definidos com base em razões operacionais.
Impacto no sistema de registro
---------------------------------

Esta proposta implicará a criação de um processo para o controle automático do abuse-c e abuse-mailbox.
Implicará também um desenvolvimento para o sistema o portal dos NIRs e de LACNIC para o bloqueio inicial.

Fontes oficiais de referências
--------------------------------
Políticas sobre o contato de abuso nos outros RIRs
--------------------------------------------------
- RIPE
Existe uma na fase de implementação: https://www.ripe.net/publications/docs/ripe-705
No entanto, é mais flexível: a frequência é anual e é mais simples, RIPE irá verificar que exista um domínio e que haja apenas um servidor de correio configurado.

- APNIC
Uma política semelhante à de LACNIC alcançou consenso no último evento de APNIC e está em fase de implementação.
https://www.apnic.net/wp-content/uploads/2018/08/prop-125-v001.txt

- ARIN
De acordo à seção 3.6: https://www.arin.net/participate/policy/nrpm/#3-6-annual-validation-of-arin-s-public-whois-point-of-contact-data

ARIN atualmente usa o seguinte procedimento de validação: envia um e-mail uma vez por ano para cada contato registrado. Cada contato tem um máximo de 60 dias para responder que o contato é correto e está atualizado. Se o contato não responder após 60 dias, será marcado como inválido no banco de dados. Estes usuários terão acesso limitado às funcionalidades de ARIN on-line até o contato seja atualizado.

Também há uma proposta semelhante à de LACNIC que será apresentada no evento de abril de ARIN:
https://www.arin.net/participate/policy/drafts/2019_5/

- AFRINIC
Também há uma proposta semelhante à de LACNIC que está em discussão desde novembro de 2018. Foi apresentada no último evento e voltou a discussão.
https://afrinic.net/policy/2018-gen-001-d2#proposal

ANALISE DE IMPACTO PELA EQUIPE DE LACNIC - Proposta LAC-2018-5 - versão 3

Interpretação da proposta pela equipe de LACNIC
----------------------------------------------------

Aplicação da seção 12. Registro e validação de "abuse-c" e "abuse-mailbox"
---------------------------------------------------------------------------
Esta proposta se aplicaria aos receptores dos recursos de LACNIC para que registrem um contato de abuso válido, tanto para ASNs quanto para IPv4 e IPv6.

Modificação do texto atual
---------------------------
De acordo com as modificações apresentadas na proposta 2018-5, o manual de políticas ficaria como mostrado abaixo nas seguintes seções:

• Adicionam-se as seções:
o 12. Registro e validação de "abuse-c" e "abuse-mailbox”
o 12.1 Descrição do "abuse-c" e "abuse-mailbox”
o 12.2. Características do "abuse-mailbox
o 12.4. Validação do "abuse-c"/"abuse-mailbox"
o 12.5. Mecanismo de escalado para LACNIC

• Seção 12. Os apêndices deixam de ter numeração para poder incorporar novas seções sem a necessidade de renumerar os apêndices constantemente.

Comentários da equipe
----------------------
• Mudanças em relação à versão anterior da proposta:
o Incorpora as recomendações da equipe de LACNIC das versões anteriores sobre:
- usar o termo inetnum tanto para IPv4 quanto para IPv6
- colocar a seção de apêndices sem numeração
o Acrescenta que o procedimento estabelecido por LACNIC deve impedir que o processo de validação seja exclusivamente automatizado.
o Modifica que o prazo de validação inicial não deve ser superior a 15 dias úteis em vez de 2.
o Indica que, se o contato de abuso não for validado corretamente na etapa inicial, será escalado com o receptor do recurso em um prazo não superior a 15 dias, em vez de 3.
o Acrescenta que os prazos de validação “inicial” e “escalado” podem ser modificados por LACNIC.
o Muda a validação periódica que LACNIC deveria fazer de uma vez cada 3 meses para duas vezes por ano. Além disso, permite que LACNIC modifique a frequência de validação se considerar oportuno.
o Propõe uma alternativa no caso de descumprimento:
- Bloqueio inicial de milacnic para todos os recursos da organização, exceto para a atualização de contatos abuse-c/abuse-mailbox
- Se os contatos de abuso forem atualizados corretamente, serão revalidados para permitir o desbloqueio de milacnic.
- No caso de descumprimento continuado, será aplicada a seção 7.1. Recuperação de recursos.

Recomendações
• Na seção 12.4 e 12.5, quando disse “O descumprimento, implicará um seguimento mais exaustivo, de conformidade com as políticas/procedimentos pertinentes de LACNIC e principalmente "7.1. Recuperação de recursos", não especifica como deve proceder LACNIC, si terá que aplicar a política 7.1 em todos os casos ou não.
• Observa-se que para a implementação desta proposta LACNIC precisará investir novos recursos para atender ao acompanhamento de todos os casos que o necessitarem.
• Recomenda-se que a proposta não defina prazos, mas que determine ações, e que os prazos necessários sejam definidos com base em motivos operacionais.
• Se sugere que durante o bloqueio de Mi LACNIC também se deveria permitir o acesso ao contrato de afiliação e à sessão de pagamento em Mi LACNIC apesar do incumplimento.
• Em relação às informações adicionais mencionadas na proposta, aponta que "uma proposta semelhante sobre o contato de abuso alcançou consenso no RIPE NCC em junho de 2018".
(https://www.ripe.net/participate/policies/proposals/2017-02).
A proposta 2017-2 do RIPE NCC é mais flexível: não indica prazos e a validação que o RIPE implementará é mais simples, verificará que exista um domínio e que haja um servidor de correio configurado unicamente.

Impacto da política no sistema de registro e endereços
-------------------------------------------------------
Esta proposta implicará a criação de um processo para a fiscalização automática do abuse-c e abuse-mailbox.

ANALISE DE IMPACTO PELA EQUIPE DE LACNIC - Proposta LAC-2018-5 - versão 2

Interpretação da proposta pela equipe de LACNIC
----------------------------------------------------

Aplicação
-----------
Esta proposta seria aplicada aos LIR para que deixem um registro de um contato de abuso válido.

Alteração do texto atual
-----------------------------
O manual de políticas aparecerá na seção seguinte como mostrado abaixo:

• Serão acrescentadas as secções:
o 12. “Registro e validação de "abuse-c" e "abuse-mailbox”
o 12.1 "Descrição do "abuse-c" e "abuse-mailbox"
o 12.2. "Características do "abuse-mailbox"
o 12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"
o 12.4. Validação do "abuse-c" /"abuse-mailbox"
o 12.5. Mecanismo de escalado para LACNIC

• O ponto 12: “Apêndices” passa a ser a secção 13. Apêndices.


Comentários da equipe:
-----------------------
• Nas secções 12.4 e 12.5 quando indicado "O descumprimento implicará um acompanhamento mais exaustivo, de acordo com as políticas/procedimentos pertinentes de LACNIC e, principalmente, "7.1. Recuperação de recursos", não fica claro como deverá proceder LACNIC, se deverá aplicar a política 7.1 em todos os casos ou não.


• Observa-se que, para a implementação desta proposta, LACNIC precisará investir novos recursos para atender o acompanhamento de todos os casos que precisarem. 


• Na proposta se faz referência ao objeto “inetnum6”. No whois de LACNIC, só se faz referência ao objeto "inetnum", tanto para IPv4 quanto para IPv6.


• Recomenda-se colocar a secção do apêndice sem numeração, mas como "A" (apêndice). Esta recomendação é para não ter que atualizar a numeração do apêndice tantas vezes como secções adicionadas ao manual, o que poderia gerar erros devido a todas as referências para o apêndice (seção 12), que aparecem ao longo do texto do manual de políticas.

Impacto da política no sistema de registro e endereços
-------------------------------------------------------
Esta proposta implicará a criação de um processo para o controle automático do abuse-c e do abuse-mailbox.

Política de privacidade