anjo2.com – Evil or not

O Spam tem sido uma das grandes preocupações dos datacenters nos últimos tempos, parece impossível o parar e já existe medidas descontroladas para o parar e sem sucesso, um desses exemplos é a hotmail que rejeita mails mesmo que não sejam de Spam.

A solução não é fácil, por vezes são colocados ips nas spam list indevidamente, com envios de newsletters que até são legais, ou através das listas de emails ilegais em que todos os que estão nesse servidor acabam por pagar por causa de outrem, pelo que bloquear o número de mails por hora num servidor por conta é essencial, mas poderá causar alguns transtornos, pois em grandes comunidades, ao enviar uma newsletter não é possível enviar para todas as pessoas, o que até pode ser bom pois um envio massivo de mails pode causar instabilidade num servidor. Terá então que enviar em várias vezes, e a melhor solução será uma cron que corre de x em x minutos e enviar um número x de mails, para quem usa CMS’s conhecidos, poderá usar plataformas já feitas, poderá ver aqui.

Como fazer o seu cron (requer conhecimentos em php e sql):

• Adicionar uma nova tabela com id(chave primária, defeito 1), userid (defito 0), mailid (defeito 0), timestamp (defeito 0), status (defeito 0) (todos podem ser inteiros, caso não guarde em nenhum sitio poderá usar o mailid como o texto do mail e nesse caso deverá adicionar mais uma para informar se é html ou texto).
• Criar um sistema php que vá buscar x usernames a partir do userid (ex.: “SELECT s1.email from `tabela_users` as s1, `tabela_cron_mail` as s2 where s1.id > s2.iduser order by s1.id asc limit 50″ e no fim fazer um update do userid para o último enviado + 1 (para não enviar 2 vezes ao mesmo).
• Quando já não houver mais ninguém a enviar colocar o status a 1 para indicar que foi enviado.

Nota: Isto são apenas alguns pontos que deverá ter atenção se quiser construir um sistema seu, existe um script de exemplo para envio de mail no “Repositório de código”, no entanto recomendamos o uso de smtp através da biblioteca especifica que poderá encontrar aqui.

Voltando ao assunto dos servidores, para quem tem um servidor, poderá vir a ter um problema com a hotmail e não só e para isso é preciso tomar algumas precauções, a primeira é o uso do SPF, para quem usa por exemplo o cPanel, bastará adicionar o seguinte nos templates de dns:

%domain%. IN TXT "v=spf1 a mx ip4: ?all"
Ex.: %domain%. IN TXT "v=spf1 a mx ip4:192.168.1.1 ?all"

Para os outros terão que adicionar manulamente um dns tipo TXT com esse conteúdo a cada um dos domínios.

Ex.: meudominio.com IN TXT "v=spf1 a mx ip4:192.168.1.1 ?all"

Nota: Ao adicionar no template, as contas já criadas não são influenciadas, para quem tem uma conta de revenda deverá ter atenção a isto, em último caso fale com o seu provedor de alojamento.

Poderá ir ainda mais longe, a hotmail/microsoft tem um sistema proprietário em que tem como base o Sender ID, e para isso é preciso registar o ip do servidor ou gama de ips em https://postmaster.live.com/snds/addnetwork.aspx, poderá obter mais info sobre este sistema em http://postmaster.msn.com/Default.aspx

Recomendamos que tenha cuidado com o envio de mails em massa para uma melhor regulação de todo o sistema de mails.

Actualização: Deixo aqui também o link para poderem adicionar os vossos domínios à lista da Microsoft relativamente aos SenderID, não esquecendo que o SPF é fundamental.

Por vezes ao comprar um serviço que achamos que é bom acaba por dar problemas e ser uma dor de cabeça para nós, mas de quem será a culpa? Todos sabemos que o mais fácil é deitar a culpa aos outros, no entanto será que a maior culpa será dos outros?

Ninguém está a salvo de problemas, principalmente se for o provedor de alojamento com os servidores. A culpa vem por uma hierarquia, se o problema for do Datacenter, o provedor culpa o datacenter, o revendedor (se existir) culpa o provedor, e o cliente culpa a quem comprou, é o que geralmente acontece, mas vendo por outro prisma, o cliente é que escolheu a quem comprar (sim há muita escolha, se só olhou para o preço, a culpa é do cliente que não fez uma boa escolha para as suas necessidades), o provedor é que escolheu o datacenter (existe menos escolha, mas mesmo assim ainda há escolha e também é culpado por não ter solução.

No inicio fica sempre bem dizer bem dos serviços contratados, mesmo sem se conhecer, o ego aumento, para o mundo fez a melhor escolha, são muito bons, etc etc, depois vem os problemas e culpa-se a hierarquia e quem fica a perder? o topo da hierarquia, quando secalhar a culpa nem está lá, mas é esta a realidade do povo português, quando tudo está bem são os maiores, mas rapidamente passam de bestiais a bestas.

Cada parte deve fazer o melhor possível para assegurar um bom serviço, seja pelo datacenter a garantir ligação estável, energia, etc., seja o provedor em ter os servidores bem configurados, não fazer overselling, etc, seja o cliente em ter as plataformas actualizadas, não ter mods de fontes desconhecidas, etc…, e estas são as partes internas, muitas vezes os visitantes não sabem se o site tem as plataformas actualizadas e os mods de fontes conhecidas (relembrando o ataque à comunidade phpbb feito através de uma plataforma desactualizada em que foram roubados conteúdos e passwords em apenas md5), o cliente não sabem se a empresa faz overselling ou tem os servidores bem configurados (é o prato do dia encontrar erros graves de dns em servidores de provedores), o provedor não sabe como é estruturado a rede de internet e de electricidade (relembro por exemplo a falta de energia na Claranet quando o UPS da Telvent falhou, eles deram a culpa à Telvent, mas os seus vizinhos NFSI tinham solução para isso com UPS’s próprios).

Não se esqueça que o mal não acontece só aos outros, também pode acontecer a sí, faça uma boa escolha dos serviços, proteja-se de “catástrofes” e irá ver que vai compensar ao ir vendo os problemas a acontecerem, mas neste caso só aos outros

Devido a imensas pessoas estarem nesta situação, deixo aqui algumas soluções para recuperar os vossos alojamentos e domínios caso não o consigam fazer nem os contactar.

Recuperação dos ficheiros do alojamento:

Se o domínio já estiver expirado (quando acedem à página do domínio mostra um site com publicidade) e não consigam entrar no cPanel devido ao mesmo, tentem entrar por http://www.coresp.com/cpanel no entanto verifiquem primeiro que a página http://www.coresp.com está a funcionar.
Se a vossa conta de alojamento estiver suspensa (quando acedem à página indica que a conta está suspensa) a única solução é contacta-los.

Contactos:

Mail: geral@coresp.com
Telefones: 220166852, 916446477, 914890057

Recuperação do domínio:

Verifiquem se o domínio está na nicline ou em que registrar está, pois só os mesmos podem-te ajudar, no entanto só o costumam fazer quando existe várias queixas sobre a mesma entidade. Para verificar o registrar podem ver o whois pelo site http://whois.domaintools.com/vosso-dominio.com (alterem onde está vosso-dominio.com para o vosso domínio) e onde diz ICANN Registrar: Se estiver ARSYS INTERNET, S.L. D/B/A NICLINE.COM é porque está na nicline, no entanto também pode estar na Melbourne IT, onde aparece no ICANN Registrar: a designação MELBOURNE IT, LTD. D/B/A INTERNET NAMES WORLDWIDE

Exemplo de mail a enviar para a nicline (se enviarem para a Melbourne IT editem onde está Nicline para Melbourne IT): (Não se esqueçam de alterar o que está entre “<" e ">“!!!)
Mail da nicline: nicline@nicline.com
Mail da Melbourne IT: customersolutions@melbournit.com

Subject: Domain Recover

Dear Nicline Support,
 
I have bought the domain <domínio.com> in CoreSP.com of Alix Axel, but now i can't contact them for months. I have search, and many people have this problem too. The unique solution is to contact you to get my domains back. Some people said that have contacted the nicline and received the auth code to transfer their domains.
can you give the auth to transfer my domain? Other solution, can you create me an account in order to transfer the domain to that account?
 
 
Regards,
 
<Nome>

Neste mail está a pedir o “auth code” que é o código que necessitam para transferir o vosso domínio.

Depois de os contactarem deverão receber uma resposta em menos de 48h (dias úteis), não devem ficar à espera que eles façam tudo, tentem colaborar ao máximo com o registrar, contacta-los mais do que uma vez, o mais provável é receberem uma resposta a dizer que eles vão tentar os contactar e caso não respondam, fornecem esse código.

Por norma a transferência de domínios processa-se do seguinte modo:
Passo 1: Pedido de transferência de domínio na nova empresa com o “auth code”
Passo 2: Pagamento da transferência (está incluído renovação de 1 ano)
Passo 3: O contacto administrativo irá receber um mail onde terá que aceitar a transferência do domínio
Passo 4: Após ter aceite, o registrar tem que dar a autorização de transferência, o que pode demorar cerca de 5 dias úteis

Depois de terem o “auth code”, deverão contacta-los de novo depois de pagarem o domínio e a empresa ter aceite o pagamento, para que eles aceitem a transferência, já que o contacto administrativo será o Alix Axel que está incontactável.

Atenção:
1- Questionem se a nova empresa é revendedora da nicline (ou Melbourn it caso seja este o registrar), caso seja, não existe transferências dentro do mesmo registrar, apenas é movido os serviços, o que não necessita de pagamento e onde também não está incluída a renovação.
2- Se os conseguirem contactar, não façam o que está aqui descrito e tentem pela via diplomática falando com eles.

Já é possível encontrar facilmente um alojamento barato, no entanto a vida complica-se para escolher o alojamento ideal para nós.

A 1ª fase da procura é escolher os planos e para isso é preciso saber o que precisamos, para podermos excluir planos e nos fixarmos nos que interessam para mais tarde irmos à 2ª fase da escolha, que será a qualidade do alojamento.

Características Principais (Visíveis):

• Espaço em disco: Na maioria está tudo englobado, ou seja base de dados + paginas + mails, uma base de dados de um fórum não deve passar de 200MB (já grande) e um fórum com avatares não deve passar também os 200MB (já grande), adicionando um site, 500MB deverão bastar.
• Tráfego: O mínimo deverá ser 10GB, no entanto é aconselhado 20GB de tráfego, para o primeiro ou primeiros projectos não deverão precisar de mais.
• Base de dados: Deverá ser pelo menos um, já que podes por vários sites ou fóruns dentro da mesma base de dados, mas o melhor é garantir que é uma base de dados para cada.
• Domínios Parqueados: Número de domínios que se pode colocar a “redireccionar” para o domínio principal, por ex.: dominio.com dominio.net dominio.org abrirem todos o site principal
• Domínios Adicionais: Idêntico aos parqueados mas para outras pastas, deste modo pode-se ter vários sites com domínios diferentes num só alojamento, no entanto é sempre preferível ter projectos separados por contas de alojamento.
• Os restantes irão depender de cada um, como por exemplo: Subdomínios (nome.dominio.com), Mailing lists (listas de emails), Contas ftp (se quiserem dar acesso a outras pessoas a certas pastas), etc.

Características Secundárias (Não visiveis): Não deixam de ser muito importantes apesar de estarem geralmente escondidas.

• Tamanho das bases de dados: Em alguns alojamentos existe um limite de tamanho de cada base de dados, 20MB, 50MB é um grande limitador, um fórum grande deve ter uma base de dados com cerca de 200MB e nunca pode estar num alojamento com estes limites
• Número máximo de envio de emails por hora: Caso seja muito pequeno vai ser limitativo, mas o utilizador deverá ter noção que não se deve enviar imensos mails só de uma vez, devem sempre ter software que permita enviar mails aos poucos.
• Sistema de backups: Muito importante, apesar do utilizador ter o dever de também fazer backups, é muito importante a empresa de alojamento ter uma boa politica de backups, e isto passa por guardar vários backups, num disco à parte e até num servidor à parte, além de sistemas avançados de backups como por exemplo o R1Soft.

Com estas características definidas, já conseguem escolher os planos que vos agradam, no entanto não olhem apenas para o preço, ainda falta analisar as empresas. Pelo que podem começar por analisar o site e o fórum, as características dos servidores poderá dar uma noção acerca do material que usam, no entanto poderá nem ser real, bem assim como o feedback, mesmo que esteja no site, poderá ser inventado pela empresa ou mesmo feedback antigo, devem procurar se nesse feedback existe link para o site do cliente ou algo que possam ter a certeza que é um cliente real e que é o seu feedback actual, se tiver o link, podem até tentar procurar o mail do webmaster. Deverão também analisar se têm morada e contactos.

Existe alguns pormenores como por exemplo qual é o painel (geralmente o cPanel é o preferido), o que pode ser muito importante tendo em conta que será mais fácil de transferir uma conta entre painéis iguais, software de construção de sites como por exemplo o RVSiteBuilder, software para instalação de CMS como por exemplo Fantastico ou Installatron, software especial que precisem como por exemplo RoR (Ruby on Rails), no qual devem também ter em conta.

Para finalizar, deixo aqui um template para um mail que podem enviar às empresas que estiverem interessadas para fazer a escolha final, devem analisar a qualidade de resposta e o tempo que demoraram a responder, podem responder às respostas das empresas para fazer uma média de tempo.

Boa tarde,
 
Estive a ver os vossos planos de alojamento e estou com algumas dúvidas que gostaria que me esclarecessem,
 
1- Ao passar o tráfego limite o que acontece à minha conta?
2- O domínio está incluído nos planos?
3- Quais os vossos meios de suporte e quanto tempo em média demoram a responder?
4- Existe algum sitio onde possa ver o uptime dos vossos servidores? Qual o uptime médio e garantido?
5- Existe algum limite para o tamanho das bases de dados?
6- Qual o limite de envio de emails por hora?
7- Como é o vosso sistema de backups?
8- O domínio fica em meu nome?
9- Os servidores estão em território nacional?
10- Qual o painel de alojamento?
11- Qual as versões actuais do php, mysql, postgres, asp e mssql (apagar os não aplicáveis)
12- Poderei fazer upgrade ou downgrade ao plano comprado? Qual o custo?
13- Existe algum sitio onde possa ver tudo o que está instalado no php (phpinfo)?
 
Cumprimentos,
<O vosso nome>

Apesar de ser cada vez mais conhecido os limites do ilimitado, as pessoas continuam a comprar na esperança que tenha o que alugou, muitas vezes são traídas pelos contractos com 1001 artigos ou pela letras pequenas, pois o ilimitado não existe, no entanto é preciso saber-se analisar, espero que aprendam a analisar com este “post”.

Primeiro que tudo é preciso ter-se noção do que se necessita e da importância do que se vai alojar, decerto que não devem alojar algo que é muito importante num sitio onde não fazem a mínima de quais são os limites e muitas vezes nem as práticas das empresas… Em segundo, os limites do ilimitado, o espaço em disco requer discos rígidos, discos rigidos grandes é idêntico a menos performance, existe discos SAS/SCSI e SATA, SAS/SCSI 15000rpm vão até 150GB e são os discos com maior performance, os discos SATA vão até 1TB (existe discos de 1,5TB e 2TB também, mas ainda sem provas dadas sobre a sua fiabilidade, os discos atingiram o seu limite na tecnologia actual e começa a haver interferências o que é péssimo e pode dar problemas graves, pelo que não vou contabilizar estes discos e secalhar deviam fugir de quem os coloca para produção), mas analisando uma maquina com 6 discos SATA 1TB em raid 10, iria ter 3TB de espaço, um luxo para oferecer espaço… A seguir ao espaço vem o tráfego como uma das características mais importantes e este está directamente ligado à ligação, o tráfego ilimitado não existe e está bastante mais limitado do que parece, muitas empresas têm uma ligação de 100Mbps partilhada por muitos servidores, uma conta com tráfego ilimitado pode mandar todos os servidores abaixo só por ter tráfego ilimitado? Obvio que não… Depois existe algo como o número de base de dados, de emails etc. que se forem partilhados com o espaço ocupado e o espaço for limitado, já sabem que só podem criar até ocupar o espaço que têem, idêntico para os subdominios e dominios, no entanto estes já podem fazer mossa no servidor de dns, no entanto penso que só por maldade se pode andar a criar milhares de subdominios. Existe também o limite por base de dados, ora bem, se o limite de uma base de dados for 20MB, não se podem criar fóruns com muita gente e logo estão a limitar bastante o utilizador.
Vamos agora aos limites escondidos, que são geralmente os mais importantes que são o cpu, ram e performance do disco, existe provedoras de alojamento que suspendem automáticamente as contas depois de passarem x% de uso de cpu, e esta prática vai-se tornar cada vez mais frequente, e apesar de oferecerem alojamento para multi-dominios e parecer que podem colocar todos os vossos sites apenas num alojamento, é que passam essa percentagem de cpu e todos os sites ficam offline… Além disso o número de contas num servidor por vezes é elevado, muitas vezes mais de 500, o que se tiver contas mais exigentes vais passar a ter os teus sites lentos todos os dias.

O ilimitado pode ser considerado também como não contabilizado, é uma especie de “não abuses que tudo fica bem”, mas será que compensa ter essa liberdade? Como disse antes, passa a ser uma questão de sorte ficar no servidor com menos carga para não ficar com os sites lentos, e é disso que se valem grande parte dessas empresas em que os planos são para massas, e tanto existe clientes satisfeitos, como insatisfeitos e muitas vezes fica-se na ideia que só dizem mal porque sim.

Deixo aqui a minha proposta, criar um fundo para experimentar os limites dos alojamentos, caso estejam interessados coloquem nos vossos comentários empresas que gostariam de ver os limites tanto de tráfego como de espaço que se vir muitos interessados crio um “donate” apenas para este fim e scripts que apenas gastem espaço e tráfego, não vou ver os limites de cpu, base de dados, etc, apenas encher disco e gastar tráfego como se fosse um cliente normal e reportar até onde chegou antes de dar problemas (suspenso ou ficar sem acesso).