Sysadmins precisa atualizar seu código para trabalhar com os endereços de e-mail para atender alterações no DNS global, ou correm o risco de perder clientes e reputação.
Isso de acordo com uma série de especialistas em domínio reunidos na conferência NamesCon em Las Vegas esta semana.
Representantes do Google, ICANN, DotAsia eo Domain Name Association (DNA), entre outros, se reuniram para discutir a questão da "aceitação universal" e descobrir como alcançar os milhões de bases de código por aí na internet que estão usando desatualizados e código potencialmente buggy.
No cerne da questão é a expansão da internet, tanto em termos de registros de nível superior e usuários globais. Entre as centenas de novos domínios de nível superior são várias dezenas em caracteres não-latinos: árabe, chinês, partes do francês e afins.
Cada vez mais esses registros e seus domínios não estão apenas sendo usado em navegadores, mas por e-mail. E isso está causando sérios problemas.
Quem diabos configurado isso?
A maioria dos sistemas, incluindo servidores de email, são projetados para aceitar endereços de e-mail com algum nível de codificação destina a verificar que se trata de um endereço de e-mail real. Qualquer coisa de simplesmente verificar que figure o símbolo "@", para limitar a entrada de caracteres específicos, para a execução de um whitelist que exclui qualquer coisa que não é um domínio reconhecido (alguns até mesmo excluir domínios e-mail gratuito, em um esforço para limitar spam).
A questão da resolução de sites com novos domínios de internet em navegadores tem sido largamente fixa graças a lista de sufixos pública do Mozilla e Chrome referindo-se à lista autorizada de domínios de nível superior, publicados pela IANA.
Mas os nomes de domínio internacionalizados (IDNs) apresentar um problema mais difícil, uma vez que são enviados em punycode e começar com o prefixo "xn--", o que significa que qualquer software para manipulação de domínios tem de fazer referência a um repositório IDN saber como exibi-los.
E-mails são mais um passo em complicação desde que as regras precisam ser desenvolvidos tanto para o nome de usuário antes do símbolo "@" eo fim do domínio. Uma vez que uma grande quantidade de e-mail de codificação pré-data a introdução de IDNs, sistemas, muitas vezes, simplesmente rejeitar e-mails que não funcionam dentro do modelo de DNS de idade - se recusar a permitir que traços, por exemplo.
Alguns sistemas têm codificação que pode lidar com a parte do domínio de um endereço de e-mail, mas não o nome do usuário (se apresentado como um IDN) - principalmente porque ainda não há um padrão para codificar que parte de um e-mail.
Mas à medida que mais e mais pessoas vêm on-line e os usuários mais não-ingleses começar a adoptar e-mails em sua própria língua, a incapacidade de aceitar o endereço de e-mail de alguém como válido vai começar levando a uma perda de clientes globais e vai fazer você parecer ridículo.
Não é tão simples como permitir que qualquer coisa na caixa de e-mail no entanto. Um exemplo famoso de um possível problema de segurança está na utilização de cirílico para criar o que se parece exatamente com um script Latina "a", mas na verdade é um personagem completamente diferente (há muitos outros exemplos). Isso significa, por exemplo, que o nome de domínio "raural.com" é cirílico pode parecer exatamente como "paypal.com" em latim. As oportunidades para spoofing e phishing são óbvias.
A prática faz perfeito
E assim, explicou o CEO da DotAsia, Edmon Chung, um grupo de especialistas de domínio estão a desenvolver diretrizes de melhores práticas e políticas que ajudem a reduzir potenciais problemas - por exemplo, um código que não aceitará um mix de scripts no mesmo e-mail ou domínio.
Isso seria um ponto de partida, explicou Chung, mas precisa de refinamento desde que há usos legítimos para os scripts mistas em japonês e chinês, para não mencionar o fato de que muitas pessoas usam nomes de usuários latino com domínios IDN.
Google foi cavando nesta questão há algum tempo. Gmail é um dos muito poucos serviços de e-mail que assume total endereços IDN. Como atualmente lida com endereços de e-mail que não seguem padrões típicos é através de uma caixa de alerta. Mas, como gerente de programa Brent Londres apontou, há complicações adicionais.
Por exemplo, o árabe é escrito da direita para a esquerda. Sistemas criados para lidar com a escrita árabe, passa geralmente quando o primeiro caractere árabe é inserido. Mas, com um endereço de e-mail roteiro misto, tal como 'customer.care @ [domínio IDN] .IDN', o sistema precisa de ser capaz de lidar com ambos scripting da esquerda para a direita e da direita para a esquerda.
Isso fornece outra falha de segurança em potencial: se alguém registra o nome de domínio "customer.care" neste cenário que poderia escrever o roteiro árabe primeira (username), fazendo com que um sistema de e-mail para exibir a da direita para a esquerda e, em seguida, colocar no domínio "customer.care". Afigura-se na caixa como se "customer.care" era o nome de usuário no lado esquerdo do endereço de e-mail. A única diferença seria que todo o endereço seria alinhado à direita.
Enquanto Londres observou que, devido à relativamente pequena take-up de e-mails IDN no momento isso não é um grande risco à segurança, é algo que é susceptível de obter cada vez mais problemático ao longo do tempo.
Outras questões de tecnologia do nosso tempo
O maior problema, porém, é que a questão da "aceitação universal" é uma combinação do bug Y2K e rollout IPv6.
O bug Y2K existiu por causa de uma decisão de codificação eficiente feita muitos anos antes (para apenas permitir-dois caracteres para representar o ano). O mesmo acontece com a codificação e-mail - ele é projetado para funcionar apenas com latino-script.
Da mesma forma, enquanto a comunidade técnica tem vindo a exigir empresas para atualizar para o IPv6 por uma década, rollout continua lento, em grande parte porque não há demanda dos clientes por ele.
"Quando começamos a abordar as pessoas sobre este problema, eles dizem 'e daí? Ninguém está pedindo para ele'", explicou Chung. Como resultado que não falam inglês, muitas vezes, ter um endereço de e-mail de back-up que eles usam para aqueles sistemas que não vai aceitar o seu endereço de e-mail principal. Mas, como IPv6, esta abordagem não é sustentável.
Felizmente, a codificação em torno IDN endereços de e-mail é muito mais simples de conseguir do que um movimento para infra-estrutura IPv6. A desvantagem, como Chung explica é que "qualquer um pode configurar um servidor de correio e definir suas próprias configurações."
O grupo está a desenvolver uma estratégia para alcançar o maior número de pessoas responsáveis por código possível e pretende dar o exemplo, concentrando-se primeiro sobre a própria indústria de nomes de domínios - os sistemas que registros e registradores usar para executar o sistema de nome de domínio. Diretor do serviço técnico Francisco Arias da ICANN disse aos participantes que ele estava constantemente a falar com a indústria sobre como atualizar seus sistemas e vai realizar uma reunião em Washington DC na próxima semana, a fim de empurrar o problema junto.
O Domain Name Association (DNA) também assumiu a tarefa com o seu diretor-executivo Kurt Pritz delineando planos para construir um repositório e recursos para ajudar os administradores a entender e corrigir os problemas. Ele está preocupado que o grupo terá de entrar no C-suite para ter um impacto real: "Podemos enviou bilhetes pessoas, mas na melhor das hipóteses eles vão ficar com os caras tecnologia e é improvável que querem mergulhar no código, a menos há alguma pressão de cima ".
Corrigindo o problema não é caro, Pritz observou, mas haverá uma despesa. E o retorno sobre o investimento não é imediatamente aparente. Mas o grupo é decidido em duas coisas: uma, eles precisam fornecer as ferramentas para tornar mais fácil para as pessoas a fazer as mudanças; e dois, essas alterações vão tornar-se extremamente importante, em apenas alguns anos.
Para obter mais informações sobre a aceitação universal, visite a página de informações da ICANN em http://ift.tt/1E2aj9w . O DNA será o desenvolvimento de seus recursos em publicar em breve no http://thedna.org/ .
via Alimentação (Feed)
Nenhum comentário:
Postar um comentário