| Autores | |
|---|---|
Nome: Jordi Palet Martinez Email: jordi.palet@theipv6company.com Organização: The IPv6 Company |
Nome: Jordi Palet Martinez Email: jordi.palet@theipv6company.com Organização: The IPv6 Company |
| Resumo | |
A proposta permite garantir e validar os contatos de abuso do WHOIS (abuse-c e abuse-mailbox) das organizações e poder a ssim informar os casos de abuso e resolvê-los. Esta proposta visa resolver o problema e garantir a existência de um contato abuse-c correto e o processo para seu uso. |
A proposta permite garantir e validar os contatos de abuso do WHOIS (abuse-c e abuse-mailbox) das organizações e poder a ssim informar os casos de abuso e resolvê-los. Esta proposta visa resolver o problema e garantir a existência de um contato abuse-c correto e o processo para seu uso. |
| Justificativa(Descrever o problema que deseja solucionar) | |
A política atual (ASN) não é clara em relação à obrigação de registrar um contato de abuse (abuse-c) nem ao formato espe cífico, e se pode ser aplicada a outros casos de registros no WHOIS. Como resultado, pode haver receptores de recursos de LACNIC que não têm esse contato registrado para seus recursos, ou a inda há casos de LIRs/ISPs, usuários finais ou outros, que usam uma caixa de correio inexistente ou que não está ativame nte monitorada. A falta de validação dos contatos tornou o relato de casos de abuso ineficaz, gerando problemas de segurança e custos pa ra as vítimas. Para tentar resolver este problema, é feita uma simples verificação periódica do contato de abuso, evitando assim custos desnecessários para terceiros. A proposta garante que o custo de processar os abusos recaia sobre o receptor do recurso quem, direta ou indiretamente ( seu cliente e de quem ele possivelmente recebe compensação pelo serviço), é responsável pelo abuso, em vez de recair sob re a vítima. Leve em conta que isso evita o possível agravamento, tempo e despesas legais para ambas as partes se forem para essa instância. Para isso, o atributo abuse-c, que até agora era apenas referenciado para o objeto "aut-num", torna-se obrigatório nos o bjetos "inetnum" (tanto para o IPv4 quanto para o IPv6), e qualquer um que venha surgir no futuro. Este atributo é um co ntato de abuso, que irá conter no mínimo o atributo "abuse-mailbox". |
A política atual (ASN) não é clara em relação à obrigação de registrar um contato de abuse (abuse-c) nem ao formato espe cífico, e se pode ser aplicada a outros casos de registros no WHOIS. Como resultado, pode haver receptores de recursos de LACNIC que não têm esse contato registrado para seus recursos, ou a inda há casos de LIRs/ISPs, usuários finais ou outros, que usam uma caixa de correio inexistente ou que não está ativame nte monitorada. A falta de validação dos contatos tornou o relato de casos de abuso ineficaz, gerando problemas de segurança e custos pa ra as vítimas. Para tentar resolver este problema, é feita uma simples verificação periódica do contato de abuso, evitando assim custos desnecessários para terceiros. A proposta garante que o custo de processar os abusos recaia sobre o receptor do recurso quem, direta ou indiretamente ( seu cliente e de quem ele possivelmente recebe compensação pelo serviço), é responsável pelo abuso, em vez de recair sob re a vítima. Leve em conta que isso evita o possível agravamento, tempo e despesas legais para ambas as partes se forem para essa instância. Para isso, o atributo abuse-c, que até agora era apenas referenciado para o objeto "aut-num", torna-se obrigatório nos o bjetos "inetnum" (tanto para o IPv4 quanto para o IPv6), e qualquer um que venha surgir no futuro. Este atributo é um co ntato de abuso, que irá conter no mínimo o atributo "abuse-mailbox". |
| Texto atual | |
Texto atual: Não existe --------- Texto novo: 12. Registro e validação de "abuse-c" e "abuse-mailbox" 12.1. Descrição do "abuse-c" e "abuse-mailbox" Todos os recursos que usem os sistemas de registro de LACNIC devem incluir obrigatoriamente, nas entradas do WHOIS corre spondentes, o atributo de contato abuse-c (contato de abuso) como mínimo com um e-mail abuse-mailbox válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e semelhantes. O atributo abuse-mailbox deve estar disponível sem restrições via WHOIS, APIs e futuras tecnologias. Levando em conta a natureza hierárquica dos objetos, os herdados de aqueles alocados diretamente por LACNIC (por exemplo , subdesignações), estar cobertos pelos objetos de nível superior e seu próprio atributo "abuse-c” é optativo. Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins. 12.2. Características do "abuse-mailbox" Os e-mails enviados para "abuse-mailbox" devem exigir intervenção manual em algum momento, por parte do destinatário, e não podem ser filtrados, pois isso poderia impedir, em alguns casos, a recepção de um relatório de abuso. Por exemplo, u m relatório de spam, ao incluir a própria mensagem de spam ou URLs ou conteúdos geralmente classificados como spam. A caixa de correio "abuse-mailbox" poderá enviar inicialmente uma resposta automática, por exemplo, designando um número de bilhete, aplicando procedimentos de classificação, solicitando mais informações, etc. No entanto, não poderá requere r o uso de um formulário, pois isso implicaria que cada entidade que precisar denunciar abusos, geralmente de forma auto matizada, seja forçada a desenvolver uma interface específica para cada receptor de recursos a quem tem que informar um abuso. Isso seria inviável, uma vez que faria recair o custo do processado dos abusos em quem envia a reclamação, vítima do abuso, em vez de ser pago por aquele que, direta ou indiretamente, provoca o abuso. O razoável é que quem denuncia o abuso, faça isso no primeiro relatório, enviando informações suficientes (log, cópia de spam ou cabeçalhos completos, o equivalente em cada tipo de abuso). Da mesma forma, é razoável que o e-mail inicial de resposta automática indique que, se essas informações não tiverem sido enviadas, não será atendido, dando assim a oportu nidade de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2 ban, SpamCop ou outros, com um custo mínimo para ambas as partes. Normalmente, espera-se que, se um número de bilhete ti ver sido designado, ele será mantido em todas as comunicações (tipicamente como parte do assunto). 12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox" O procedimento, que deverá ser desenvolvido por LACNIC, deve atender aos seguintes objetivos: 1) Garantir sua funcionalidade e permitir os "helpdesk" que lidam com os relatórios de abuso, a verificação de que a val idação realmente vem de LACNIC e não de terceiras fontes (envolvendo riscos de segurança, evitando, por exemplo, uma úni ca URL "direta" para a validação). 2) Impedir um processo exclusivamente automatizado. 3) Confirmar que quem valida: • garante conhecer o procedimento e as políticas de LACNIC • monitora regularmente o “abuse-mailbox” • toma medidas a esse respeito • responde ao relatório de abuso. 4) Prazo de validação “inicial” de 15 dias. 5) Se não for validado corretamente, “escalado” com o restante dos contatos disponíveis, em um prazo “adicional” de 15 d ias. Os prazos de validação poderão ser modificados a critério de LACNIC, informando a comunidade dos motivos. (Na forma de recomendação, propõe-se um procedimento detalhado em "informações adicionais" desta proposta de política). 12.4. Validação do "abuse-c"/"abuse-mailbox" LACNIC validará o cumprimento da política periodicamente, pelo menos duas vezes por ano, e quando os atributos "abuse-c" forem criados ou modificados. A frequência de validação poderá ser modificada a critério de LACNIC, informando a comunidade dos motivos. 12.5. Dos incumprimentos O incumprimento por parte de qualquer organização ocorre se não foi validado no prazo "inicial" ou "adicional". Isso imp licará o bloqueio de MiLACNIC e medidas equivalentes nos sistemas dos NIRs, para todos os recursos associados a essa org anização. Excluem-se as questões exclusivamente contratuais e relacionadas a pagamentos, bem como a atualização dos cont atos abuse-c/abuse-mailbox, de modo que possam ser revalidados automaticamente para permitir o desbloqueio de MiLACNIC. Qualquer acesso a MiLACNIC (ou sistemas equivalentes dos NIRs) durante o referido bloqueio, mostrará uma mensagem de avi so, incluindo o texto desta política, e para permitir continuar será necessário que essa mensagem seja "lida" até o fina l, e confirmada por meio de um check-box ou semelhante. Mecanismos equivalentes adaptados ao progresso da tecnologia pod erão ser usados. Se o incumprimento for mantido, LACNIC atuará de acordo com suas políticas e procedimentos pertinentes. 12.6. Mecanismo de escalado para LACNIC Comportamentos fraudulentos (por exemplo, "abuse-mailbox” que respondem apenas a e-mails de LACNIC, a um assunto específ ico ou corpo da mensagem) ou o incumprimento dos demais aspectos desta política (incorreta ou não atenção aos casos de a buso), poderão ser denunciados a LACNIC, para sua revalidação segundo 12.4. |
Texto atual: Não existe Texto novo: 12. Registro e validação de "abuse-c" e "abuse-mailbox" 12.1. Descrição do "abuse-c" e "abuse-mailbox" Todos os recursos que usem os sistemas de registro de LACNIC devem incluir obrigatoriamente, nas entradas do WHOIS corre spondentes, o atributo de contato abuse-c (contato de abuso) como mínimo com um e-mail abuse-mailbox válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e semelhantes. O atributo abuse-mailbox deve estar disponível sem restrições via WHOIS, APIs e futuras tecnologias. Levando em conta a natureza hierárquica dos objetos, os herdados de aqueles alocados diretamente por LACNIC (por exemplo , subdesignações), estar cobertos pelos objetos de nível superior e seu próprio atributo "abuse-c” é optativo. Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins. 12.2. Características do "abuse-mailbox" Os e-mails enviados para "abuse-mailbox" devem exigir intervenção manual em algum momento, por parte do destinatário, e não podem ser filtrados, pois isso poderia impedir, em alguns casos, a recepção de um relatório de abuso. Por exemplo, u m relatório de spam, ao incluir a própria mensagem de spam ou URLs ou conteúdos geralmente classificados como spam. A caixa de correio "abuse-mailbox" poderá enviar inicialmente uma resposta automática, por exemplo, designando um número de bilhete, aplicando procedimentos de classificação, solicitando mais informações, etc. No entanto, não poderá requere r o uso de um formulário, pois isso implicaria que cada entidade que precisar denunciar abusos, geralmente de forma auto matizada, seja forçada a desenvolver uma interface específica para cada receptor de recursos a quem tem que informar um abuso. Isso seria inviável, uma vez que faria recair o custo do processado dos abusos em quem envia a reclamação, vítima do abuso, em vez de ser pago por aquele que, direta ou indiretamente, provoca o abuso. O razoável é que quem denuncia o abuso, faça isso no primeiro relatório, enviando informações suficientes (log, cópia de spam ou cabeçalhos completos, o equivalente em cada tipo de abuso). Da mesma forma, é razoável que o e-mail inicial de auto-resposta indique que, se essas informações não tiverem sido enviadas, não será atendido, dando assim a oportunidade de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2ban, S pamCop ou outros, com um custo mínimo para ambas as partes. Normalmente, espera-se que, se um número de bilhete tiver si do designado, ele será mantido em todas as comunicações (tipicamente como parte do assunto). 12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox" O procedimento, que deverá ser desenvolvido por LACNIC, deve atender aos seguintes objetivos: 1) Garantir sua funcionalidade e permitir os "helpdesk" que lidam com os relatórios de abuso, a verificação de que a v alidação realmente provem de LACNIC e não de terceiras fontes (envolvendo riscos de segurança, evitando, por exemplo, um a única URL "direta" para a validação). 2) Impedir um processo exclusivamente automatizado. 3) Confirmar que quem valida: • garante conhecer o procedimento e as políticas de LACNIC • monitora regularmente o “abuse-mailbox” • toma medidas a esse respeito • responde ao relatório de abuso. 4) Prazo de validação “inicial” de 15 dias. 5) Se não for validado corretamente, “escalado” com o restante dos contatos disponíveis, em um prazo “adicional” de 1 5 dias. Os prazos de validação poderão ser modificados a critério de LACNIC, informando a comunidade dos motivos. (na forma de recomendação, propõe-se um procedimento detalhado em "informações adicionais" desta proposta de política). 12.4. Validação do "abuse-c"/"abuse-mailbox" LACNIC validará o cumprimento da política periodicamente, pelo menos duas vezes por ano, e quando os atributos "abuse-c" forem criados ou modificados. A frequência de validação poderá ser modificada a critério de LACNIC, informando a comunidade dos motivos. 12.5. Dos incumprimentos O incumprimento por parte de qualquer organização ocorre se não foi validado no prazo "inicial" ou "adicional". Isso imp licará o bloqueio de MiLACNIC e medidas equivalentes nos sistemas dos NIRs, para todos os recursos associados a essa org anização. Excluem-se as questões exclusivamente contratuais e relacionadas a pagamentos, bem como a atualização dos cont atos abuse-c/abuse-mailbox, de modo que possam ser revalidados automaticamente para permitir o desbloqueio de MiLACNIC. Qualquer acesso a MiLACNIC (ou sistemas equivalentes dos NIRs) durante o referido bloqueio, mostrará uma mensagem de avi so, incluindo o texto desta política, e para permitir continuar será necessário que essa mensagem seja "lida" até o fina l, e confirmada por meio de um check-box ou semelhante. Mecanismos equivalentes adaptados ao progresso da tecnologia pod erão ser usados. Se o incumprimento for mantido, LACNIC atuará de acordo com suas políticas e procedimentos pertinentes. 12.6. Mecanismo de escalado para LACNIC Comportamentos fraudulentos (por exemplo, "abuse-mailbox” que respondem apenas a e-mails de LACNIC, a um assunto específ ico ou corpo da mensagem) ou o incumprimento dos demais aspectos desta política (incorreta ou não atenção aos casos de a buso), poderão ser denunciados a LACNIC, para sua revalidação segundo 12.4. |
| Texto novo | |
Texto atual: Não existe --------- Texto novo: 12. Registro e validação de "abuse-c" e "abuse-mailbox" 12.1. Descrição do "abuse-c" e "abuse-mailbox" Todos os recursos que usem os sistemas de registro de LACNIC devem incluir obrigatoriamente, nas entradas do WHOIS corre spondentes, o atributo de contato abuse-c (contato de abuso) como mínimo com um e-mail abuse-mailbox válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e semelhantes. O atributo abuse-mailbox deve estar disponível sem restrições via WHOIS, APIs e futuras tecnologias. Levando em conta a natureza hierárquica dos objetos, os herdados de aqueles alocados diretamente por LACNIC (por exemplo , subdesignações), estar cobertos pelos objetos de nível superior e seu próprio atributo "abuse-c” é optativo. Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins. 12.2. Características do "abuse-mailbox" Os e-mails enviados para "abuse-mailbox" devem exigir intervenção manual em algum momento, por parte do destinatário, e não podem ser filtrados, pois isso poderia impedir, em alguns casos, a recepção de um relatório de abuso. Por exemplo, u m relatório de spam, ao incluir a própria mensagem de spam ou URLs ou conteúdos geralmente classificados como spam. A caixa de correio "abuse-mailbox" poderá enviar inicialmente uma resposta automática, por exemplo, designando um número de bilhete, aplicando procedimentos de classificação, solicitando mais informações, etc. No entanto, não poderá requere r o uso de um formulário, pois isso implicaria que cada entidade que precisar denunciar abusos, geralmente de forma auto matizada, seja forçada a desenvolver uma interface específica para cada receptor de recursos a quem tem que informar um abuso. Isso seria inviável, uma vez que faria recair o custo do processado dos abusos em quem envia a reclamação, vítima do abuso, em vez de ser pago por aquele que, direta ou indiretamente, provoca o abuso. O razoável é que quem denuncia o abuso, faça isso no primeiro relatório, enviando informações suficientes (log, cópia de spam ou cabeçalhos completos, o equivalente em cada tipo de abuso). Da mesma forma, é razoável que o e-mail inicial de resposta automática indique que, se essas informações não tiverem sido enviadas, não será atendido, dando assim a oportu nidade de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2 ban, SpamCop ou outros, com um custo mínimo para ambas as partes. Normalmente, espera-se que, se um número de bilhete ti ver sido designado, ele será mantido em todas as comunicações (tipicamente como parte do assunto). 12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox" O procedimento, que deverá ser desenvolvido por LACNIC, deve atender aos seguintes objetivos: 1) Garantir sua funcionalidade e permitir os "helpdesk" que lidam com os relatórios de abuso, a verificação de que a val idação realmente vem de LACNIC e não de terceiras fontes (envolvendo riscos de segurança, evitando, por exemplo, uma úni ca URL "direta" para a validação). 2) Impedir um processo exclusivamente automatizado. 3) Confirmar que quem valida: • garante conhecer o procedimento e as políticas de LACNIC • monitora regularmente o “abuse-mailbox” • toma medidas a esse respeito • responde ao relatório de abuso. 4) Prazo de validação “inicial” de 15 dias. 5) Se não for validado corretamente, “escalado” com o restante dos contatos disponíveis, em um prazo “adicional” de 15 d ias. Os prazos de validação poderão ser modificados a critério de LACNIC, informando a comunidade dos motivos. (Na forma de recomendação, propõe-se um procedimento detalhado em "informações adicionais" desta proposta de política). 12.4. Validação do "abuse-c"/"abuse-mailbox" LACNIC validará o cumprimento da política periodicamente, pelo menos duas vezes por ano, e quando os atributos "abuse-c" forem criados ou modificados. A frequência de validação poderá ser modificada a critério de LACNIC, informando a comunidade dos motivos. 12.5. Dos incumprimentos O incumprimento por parte de qualquer organização ocorre se não foi validado no prazo "inicial" ou "adicional". Isso imp licará o bloqueio de MiLACNIC e medidas equivalentes nos sistemas dos NIRs, para todos os recursos associados a essa org anização. Excluem-se as questões exclusivamente contratuais e relacionadas a pagamentos, bem como a atualização dos cont atos abuse-c/abuse-mailbox, de modo que possam ser revalidados automaticamente para permitir o desbloqueio de MiLACNIC. Qualquer acesso a MiLACNIC (ou sistemas equivalentes dos NIRs) durante o referido bloqueio, mostrará uma mensagem de avi so, incluindo o texto desta política, e para permitir continuar será necessário que essa mensagem seja "lida" até o fina l, e confirmada por meio de um check-box ou semelhante. Mecanismos equivalentes adaptados ao progresso da tecnologia pod erão ser usados. Se o incumprimento for mantido, LACNIC atuará de acordo com suas políticas e procedimentos pertinentes. 12.6. Mecanismo de escalado para LACNIC Comportamentos fraudulentos (por exemplo, "abuse-mailbox” que respondem apenas a e-mails de LACNIC, a um assunto específ ico ou corpo da mensagem) ou o incumprimento dos demais aspectos desta política (incorreta ou não atenção aos casos de a buso), poderão ser denunciados a LACNIC, para sua revalidação segundo 12.4. |
Texto atual: Não existe Texto novo: 12. Registro e validação de "abuse-c" e "abuse-mailbox" 12.1. Descrição do "abuse-c" e "abuse-mailbox" Todos os recursos que usem os sistemas de registro de LACNIC devem incluir obrigatoriamente, nas entradas do WHOIS corre spondentes, o atributo de contato abuse-c (contato de abuso) como mínimo com um e-mail abuse-mailbox válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e semelhantes. O atributo abuse-mailbox deve estar disponível sem restrições via WHOIS, APIs e futuras tecnologias. Levando em conta a natureza hierárquica dos objetos, os herdados de aqueles alocados diretamente por LACNIC (por exemplo , subdesignações), estar cobertos pelos objetos de nível superior e seu próprio atributo "abuse-c” é optativo. Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins. 12.2. Características do "abuse-mailbox" Os e-mails enviados para "abuse-mailbox" devem exigir intervenção manual em algum momento, por parte do destinatário, e não podem ser filtrados, pois isso poderia impedir, em alguns casos, a recepção de um relatório de abuso. Por exemplo, u m relatório de spam, ao incluir a própria mensagem de spam ou URLs ou conteúdos geralmente classificados como spam. A caixa de correio "abuse-mailbox" poderá enviar inicialmente uma resposta automática, por exemplo, designando um número de bilhete, aplicando procedimentos de classificação, solicitando mais informações, etc. No entanto, não poderá requere r o uso de um formulário, pois isso implicaria que cada entidade que precisar denunciar abusos, geralmente de forma auto matizada, seja forçada a desenvolver uma interface específica para cada receptor de recursos a quem tem que informar um abuso. Isso seria inviável, uma vez que faria recair o custo do processado dos abusos em quem envia a reclamação, vítima do abuso, em vez de ser pago por aquele que, direta ou indiretamente, provoca o abuso. O razoável é que quem denuncia o abuso, faça isso no primeiro relatório, enviando informações suficientes (log, cópia de spam ou cabeçalhos completos, o equivalente em cada tipo de abuso). Da mesma forma, é razoável que o e-mail inicial de auto-resposta indique que, se essas informações não tiverem sido enviadas, não será atendido, dando assim a oportunidade de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2ban, S pamCop ou outros, com um custo mínimo para ambas as partes. Normalmente, espera-se que, se um número de bilhete tiver si do designado, ele será mantido em todas as comunicações (tipicamente como parte do assunto). 12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox" O procedimento, que deverá ser desenvolvido por LACNIC, deve atender aos seguintes objetivos: 1) Garantir sua funcionalidade e permitir os "helpdesk" que lidam com os relatórios de abuso, a verificação de que a v alidação realmente provem de LACNIC e não de terceiras fontes (envolvendo riscos de segurança, evitando, por exemplo, um a única URL "direta" para a validação). 2) Impedir um processo exclusivamente automatizado. 3) Confirmar que quem valida: • garante conhecer o procedimento e as políticas de LACNIC • monitora regularmente o “abuse-mailbox” • toma medidas a esse respeito • responde ao relatório de abuso. 4) Prazo de validação “inicial” de 15 dias. 5) Se não for validado corretamente, “escalado” com o restante dos contatos disponíveis, em um prazo “adicional” de 1 5 dias. Os prazos de validação poderão ser modificados a critério de LACNIC, informando a comunidade dos motivos. (na forma de recomendação, propõe-se um procedimento detalhado em "informações adicionais" desta proposta de política). 12.4. Validação do "abuse-c"/"abuse-mailbox" LACNIC validará o cumprimento da política periodicamente, pelo menos duas vezes por ano, e quando os atributos "abuse-c" forem criados ou modificados. A frequência de validação poderá ser modificada a critério de LACNIC, informando a comunidade dos motivos. 12.5. Dos incumprimentos O incumprimento por parte de qualquer organização ocorre se não foi validado no prazo "inicial" ou "adicional". Isso imp licará o bloqueio de MiLACNIC e medidas equivalentes nos sistemas dos NIRs, para todos os recursos associados a essa org anização. Excluem-se as questões exclusivamente contratuais e relacionadas a pagamentos, bem como a atualização dos cont atos abuse-c/abuse-mailbox, de modo que possam ser revalidados automaticamente para permitir o desbloqueio de MiLACNIC. Qualquer acesso a MiLACNIC (ou sistemas equivalentes dos NIRs) durante o referido bloqueio, mostrará uma mensagem de avi so, incluindo o texto desta política, e para permitir continuar será necessário que essa mensagem seja "lida" até o fina l, e confirmada por meio de um check-box ou semelhante. Mecanismos equivalentes adaptados ao progresso da tecnologia pod erão ser usados. Se o incumprimento for mantido, LACNIC atuará de acordo com suas políticas e procedimentos pertinentes. 12.6. Mecanismo de escalado para LACNIC Comportamentos fraudulentos (por exemplo, "abuse-mailbox” que respondem apenas a e-mails de LACNIC, a um assunto específ ico ou corpo da mensagem) ou o incumprimento dos demais aspectos desta política (incorreta ou não atenção aos casos de a buso), poderão ser denunciados a LACNIC, para sua revalidação segundo 12.4. |
| Informações adicionais | |
Nota (não deve ser incluído no manual de políticas): A seção atual “12. Apêndices "passa a ser" A. Apêndices ", no final do manual de políticas, e todas as referências a ela são renumeradas em todo o manual de políticas. Dessa forma, as nov as seções do manual não requererão renumerações futuras, segundo o manual for "crescendo". O texto desta proposta torna- se, portanto, a seção 12, ou a considerada apropriada pelo pessoal no momento de sua implementação, uma vez que o consen so tenha sido alcançado. O texto a seguir é um exemplo de procedimento de validação, considerando as práticas usuais nos "helpdesk" (mesas de aju da), que, por exemplo, impedem clicar em um link html de um e-mail, para evitar casos de phishing ou outros. Mesmo quand o este texto não faz parte do texto da política, recomenda-se sua consideração estrita, uma vez que é o resultado de dis cussões relacionadas a políticas de abuse-c na comunidade global. 1) A validação começa de forma automatizada, por parte de LACNIC, com o envio de DOIS e-mails consecutivos para o "abuse -mailbox". 2) Esses e-mails terão exclusivamente formato de texto (e, portanto, ocultam URLs que correspondem a ataques como "phish ing" etc.). 3) A critério de LACNIC, de forma generalizada ou em casos específicos (por exemplo, para a confirmação em casos de esca lado de acordo com o ponto 12.6), LACNIC, para realizar as referidas validações, poderá usar domínios diferentes a lacni c.*, e até mesmo modificar o assunto e corpo da mensagem. 4) O primeiro dos e-mails vai conter a URL onde a validação deve ser realizada, que será "validacion.lacnic.net", e pode rá conter informações sobre o procedimento, extrato desta política, etc. 5) O segundo dos e-mails vai conter um código alfanumérico único de validação. 6) O receptor que atende o "abuse-mailbox", deverá acessar à URL e colar no formulário o código recebido no segundo e-ma il. 7) Esta URL deverá estar projetada de forma de impedir um processo automatizado (por exemplo, "captcha") e conterá um te xto que confirme que o receptor da validação conhece o procedimento, a política e que monitora regularmente o "abuse-mai lbox" e que são tomadas medidas adequadas para resolver os abusos relatados e responder a eles, com um "checkbox" que de verá ser necessariamente aceito. 8) O código alfanumérico apenas será válido por um máximo de 15 dias. 9) Se o código não for inserido nesse prazo, o sistema marcará o "abuse-c" como "provisoriamente inválido" e alertará a equipe de LACNIC para que possa ser iniciado o acompanhamento personalizado com o receptor do recurso. 10) No caso de não obter uma resposta com a confirmação da correção da situação, em um prazo adicional de 15 dias, o "ab use-c" será marcado de forma permanente como "inválido". 11) O processo de validação será repetido automaticamente (pontos 1 a 7 acima) e, neste caso, o "abuse-c" será marcado c omo "válido" se for satisfatório, caso contrário, seria um caso de incumprimento da política. 12) LACNIC terá mecanismos (formulário, e-mail e outros no futuro) para facilitar o escalamento nos casos em que se quei ra denunciar uma violação desta política. Isso permitirá a revalidação (12.4) e a intervenção de LACNIC na aplicação da s políticas, procedimentos e requisitos contratuais em vigor. |
Nota (não deve ser incluído no manual de políticas): A seção atual “12. Apêndices "passa a ser" A. Apêndices ", no final do manual de políticas, e todas as referências a ela são renumeradas em todo o manual de políticas. Dessa forma, as novas seções do manual não requererão renumerações futur as, segundo o manual for "crescendo". O texto desta proposta torna-se, portanto, a seção 12, ou a considerada apropriada pelo pessoal no momento de sua implementação, uma vez que o consenso tenha sido alcançado. O texto a seguir é um exemplo de procedimento de validação, considerando as práticas usuais nos "helpdesk" (mesas de aju da), que, por exemplo, impedem clicar em um link html de um e-mail, para evitar casos de phishing ou outros. Mesmo quand o este texto não faz parte do texto da política, recomenda-se sua consideração estrita, uma vez que é o resultado de dis cussões relacionadas a políticas de abuse-c na comunidade global. 1) A validação começa de forma automatizada, por parte de LACNIC, com o envio de DOIS e-mails consecutivos para o "ab use-mailbox”. 2) Esses e-mails terão exclusivamente formato texto (e, portanto, ocultar URLs que correspondam a ataques como "phish ing" etc.). 3) A critério de LACNIC, de forma generalizada ou em casos específicos (por exemplo, para a confirmação em casos de e scalado de acordo com o ponto 12.6), LACNIC, poderá usar outros domínios além do lacnic.*, e inclusive modificar o assun to e corpo da mensagem, para realizar ditas validações de forma mais eficaz. 4) O primeiro dos e-mails vai conter a URL onde a validação deve ser realizada, que será "validacion.lacnic.net", e p oderá conter informações sobre o procedimento, extrato desta política, etc. 5) O segundo dos e-mails vai conter um código alfanumérico único de validação. 6) O receptor que atende o "abuse-mailbox", deverá acessar à URL e inserir no formulário o código recebido no segundo e-mail. 7) Esta URL deverá estar projetada de forma de impedir um processo automatizado (por exemplo, "captcha") e conterá um texto que confirme que o receptor da validação conhece o procedimento, a política e que monitora regularmente o "abuse- mailbox" e que são tomadas medidas adequadas para resolver os abusos relatados e responder a eles, com um "checkbox" que deverá ser necessariamente aceito. 8) O código alfanumérico apenas será válido por um máximo de 15 dias. 9) Se o código não for inserido nesse prazo, o sistema marcará o "abuse-c" como "provisoriamente inválido" e alertará a equipe de LACNIC para que possa ser iniciado o acompanhamento personalizado com o receptor do recurso. 10) No caso de não obter uma resposta com a confirmação da correção da situação, em um prazo adicional de 15 dias, o "abuse-c" será marcado de forma permanente como "inválido". 11) O processo de validação será repetido automaticamente (pontos 1 a 7 acima) e, neste caso, o "abuse-c" será marcad o como "válido" se for satisfatório, caso contrário, seria um caso de descumprimento da política. 12) LACNIC terá mecanismos (formulário, e-mail e outros no futuro) para facilitar o escalamento nos casos em que se q ueira denunciar uma violação desta política. Isso permitirá a revalidação (12.4) e a intervenção de LACNIC na aplicação das políticas, procedimentos e requisitos contratuais em vigor. |
| Referências | |
Em APNIC, uma versão equivalente a esta proposta chegou a consenso. No RIPE, uma proposta semelhante foi adotada, mas apenas para verificação automática, e o recente debate na lista indico u precisamente a necessidade de fazê-lo de maneira "não exclusivamente automática", uma vez que o procedimento atual per mite inúmeras fraudes. Além disso, uma proposta equivalente está sendo processada e será publicada em breve. Em AfriNIC e ARIN se apresentou uma proposta equivalente. |
- |