A maioria das linguagens da programação são compiladas e só depois as corremos, na mais conhecida e utilizada linguagem de programação web, o PHP, é interpretado em tempo real, sem a compilação antes, e sendo assim na maioria dos sites e CMS’s é possível alterar código directamente, e compilar o site ou CMS fica caro.
Sendo de fonte aberta, será muito mais fácil detectar falhas de segurança, um dos exemplos mais conhecidos que temos são dos sistemas operativos Linux e Windows, em que linux é fonte aberta e Windows não, detectar falhas no linux seria mais fácil, mas com mais falhas detectadas mais vão ser corrigidas, já no Windows mesmo que tenha muito menos segurança será mais fácil detectar as falhas (e tem mais falhas de segurança).
Mas o que será mais seguro? Vai depender muito do suporte dos proprietários do código e na sua rapidez em corrigir as falhas, no entanto se não actualizar sempre o sistema ficará sujeito a ter imensos problemas de segurança!!!

Lição nº1: Ter SEMPRE o CMS actualizado!

A programação de raiz tem alguns benefícios, principalmente no que toca ao conhecimento do sistema, só quem o constrói que o conhece, logo à partida nenhuma falha é conhecida, mas poderá ter falhas graves se for mal feito, e que com um ataque poderá colocar em risco o site e os dados das pessoas (passwords, dados pessoais, etc.), outro dos contras será as actualizações, se mandar fazer o código de raiz quem vai fazer as actualizações?

Lição nº2: Se mandar fazer programação procure sempre alguém com conhecimentos, de confiança e que dê garantias! De preferência uma empresa.

Resumo de segurança: Um CMS bastante conhecido e sempre actualizado deverá ser bastante seguro, no entanto a programação de raiz se for bem feita será ainda mais segura, se for mal feito poderá resultar em desgraça.

A segurança não é tudo, nenhum visitante gosta que o site seja lento, é uma das maiores razões que faz os visitantes abandonarem o site precocemente, é bastante importante a velocidade a que abre um site, a utilização de imagens optimizadas para sites é bastante importante neste ponto, mas a programação também o é.

Este é um dos maiores problemas dos CMS, são bastante complexos, dão para tudo, mas são geralmente lentos, e quando existe enchentes de pessoas torna-se muitas vezes inavegável.
A solução da maioria dos CMS foi a criação de um sistema de cache, sendo assim não é necessário grandes acessos às base de dados nem grande utilização de cpu. É uma excelente solução, mas não é garantido que funcione a 100%, um dos exemplos mais conhecidos é o do phpBB3, um sistema de cache que até passou a funcionar para fóruns com bastantes pessoas online, mas apenas temporariamente se não apagarmos a cache de vez em quando, gasta-se bastante espaço e são criados ficheiros a mais, resultando depois a ser até bastante difícil apagar os ficheiros…
A melhor solução é fazer uma boa programação tendo em conta o que consome dos recursos do servidor, o que poderá resultar em menos funcionalidade, mas no caso de programação de raiz só irá colocar a funcionalidade que precisa e num CMS terá que haver funcionalidades para todos os gostos, o que será sempre pior.

Lição nº3: Analisar o número de pessoas que estamos à espera de receber, se for alto (> 100 pessoas em simultâneo) deverá ser um sistema rápido e se possível com sistema de cache se for complexo.

Resumo de velocidade: Programação de raiz será sempre mais rápido (a não ser que seja mesmo mal feito, o que muitas vezes acontece mesmo por pessoas que se dizem profissionais e com conhecimentos).

Dos pontos mais importantes para os webmasters é a funcionalidade dos sites, num CMS obtém-se bastante funcionalidade, muito mais do que a que precisamos, nos sistemas mais conhecidos existe módulos/plugins/addons feitos pelas pessoas e praticamente em poucos cliques adiciona-se funcionalidade num CMS, mas vão estar a abdicar de segurança e velocidade!

Lição nº4: Instalar plugins apenas que sejam reconhecidos e actualiza-los sempre! Não instale plugins que sejam desnecessários! Deverá desinstalar os plugins que já não tenham mais suporte!

Em resumo: Um site feito de raiz será sempre melhor que um CMS, mas para ter a mesma funcionalidade será MUITO mais caro, só compensará se tiver ganhos com o site ou seja de uma empresa, para sites pessoais e sem fins lucrativos use um CMS e tenha atenção às lições deste artigo, poderão evitar desastres…

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.