Caracterização de um Servidor de Email
- Estudo detalhado do seu funcionamento -
Neste documento pretende-se descrever de uma forma detalhada o funcionamento de um servidor de email. Esta descrição tem como base o funcionamento dos servidores de email mais utilizados: Sendmail, Postfix e Microsoft Exchange.
1. Requisitos Não Funcionais
Um servidor de email para além de satisfazer os requisitos funcionais, deve também satisfazer um conjunto de requisitos não-funcionais (requisitos de arquitectura). Os mais importantes são: a segurança e a fiabilidade, como descritos de seguida [1] [2]:
• Segurança - Um servidor de email deve ser seguro contra os ataques, de modo a não comprometer o sistema. A segurança deve ser efectuada em multi-níveis.
Só aos processos importantes é que devem ser atribuídos mais privilégios, os outros devem ser executados com os privilégios sempre mais baixos.
Os módulos que não estão em uso devem ser desactivados para que não sejam de alvo de estudo por parte dos atacantes.
• Fiabilidade – Um servidor de email deve ser fiável. Não deve perder nenhuma mensagem, mesmo em períodos de maior carga (stress). Pode sempre demorar mais tempo do que normal, mas deve fazer sempre a entrega das mensagens.
Existem outros requisitos como:
• Desempenho – Um servidor de email deve ser eficiente mesmo em casos de elevado fluxo de mensagens, procurando sempre aproveitar da melhor forma todos os recursos
disponibilizados pelo Sistema Operativo. Deve mostrar um bom desempenho sem perder a fiabilidade.
• Flexibilidade - Um servidor deve ser composto por vários programas e subsistemas. Esta abordagem permite uma maior flexibilidade. Normalmente o seu funcionamento é
configurável através de simples ficheiros de configuração.
• Robustez - Em caso de falta de recursos (por exemplo: memória, disco, etc) um servidor de email deve baixar o seu desempenho de uma forma suave. Diminuir apenas a qualidade de serviço (QoS), mas deve garantir o funcionamento mínimo. Deve também registar todas as ocorrências de erros nos logs.
• Disponibilidade - Um servidor de email deve estar sempre disponível. Deve saber defender dos ataques do tipo DoS (Denial-of-Service).
• Extensibilidade - Um servidor de email deve suportar os protocolos de transferência existentes, mas também deverá ser facilmente extensível para suportar novos protocolos.
Do mesmo modo, fácil também de implementar de novas funcionalidades.
• Manutenção - Um servidor de email deve ser implementado de modo a que a sua manutenção seja facilmente realizada.
2. Arquitectura
Um servidor de email pode ter diferentes arquitecturas:
• Sistema monolítico, que tipicamente utiliza um único programa no atendimento das mensagens de email;
• Programas mais pequenos que executam funções ou tarefas específicas. Muito destes programas são daemons, processos em background que se executarem indefinidamente.
Pode-se ter um processo principal, normalmente designado por mestre que controla os outros processos. É neste tipo de arquitectura que é abordada do modelo apresentado de seguida, que é constituída por pequenos componentes e fáceis de entender.
Do ponto de vista funcional, um servidor de email mais simples deverá ter três grandes componentes:
• um que é responsável por receber os emails;
• um que faz o processamento;
• um que é responsável pela entrega dos emails.
2.1 Entrada de emails no sistema
As mensagens de email podem entrar no servidor de uma das seguintes maneiras:
1. A mensagem pode ser aceite localmente, recebida do próprio servidor.
2. A mensagem é recebida de outros domínios autorizados;
3. Servidor de email gera mensagens quando:
● envia notificação de emails não entregues (undeliverable);
● adiamento da entrega (deferred delivery attempts);
● notificações de entrega, gerados a pedido do utilizador (return receipt).
2.2 Espera e processamento
Neste componente as mensagens são colocadas em filas de espera e é efectuado o processamento das mesmas.
O gestor de filas de espera é um elemento essencial nos servidores de email, pois é este o responsável pelo escalonamento das mensagens.
Alguns servidores de email têm como requisito que todas as mensagens que entram ou saem do sistema, sejam processados através das filas de espera. Cada fila, indica também o estado de processamento da mensagem.
Pode-se ter:
- Diferentes categorias/classes filas de espera;
- Múltiplas filas de espera (para a mesma categoria/classe);
- Diferentes tamanho (a capacidade da fila);
2.3 Entrega de emails
A entrega pode ser efectuada via vários agentes:
• Local – O destinatário pertence ao mesmo servidor.
• Outros destinatários – O destinatário pertence a noutro domínio.
• Outros tipo transporte – Entrega a outro tipo de transporte/programas. De seguida apresenta-se dois exemplos, mas podem existir outros:
a) LMTP (Local Mail Transfer Protocol)
• Permite a transferência das mensagens de email de um serviço de correio local para outro, sem a necessidade de existir uma unidade de armazenamento em comum.
Assim permite a entrega a unidades de armazenamento não normalizadas.
• Baseado e uma versão simplificado do protocolo SMTP.
b) pipe – entrega das mensagens a outros programas através do processo pipe, ou seja, comunicação entre processos.
3. Descrição do Modelo
Num servidor de email, os elementos que enviam e os recebem os emails podem ser classificados em duas classes:
• Local – Pertencem ao mesmo servidor;
• Remoto – Pertencem a outros domínios.
De um modo geral tem-se dois casos:
• Um servidor de email recebe mensagem de remetente local, o qual transfere para um destinatário local ou remoto dependendo do endereço de email.
• Um servidor de email também pode receber mensagem de outros servidor, sendo este transporte efectuado de acordo com o protocolo SMTP. Se a mensagem é destinada a um utilizador local, então a mensagem é depositada na caixa de email do respectivo utilizador.
Caso contrario é enviada para o outro servidor de email do respectivo domínio.
No modelo proposto existe um programa 'mestre', que está sempre em execução. Este invoca novos processos para fazer a leitura das filas de espera e o seu processamento.
3.1 Entrada
• Local – Recebe as mensagens com origem no próprio servidor.
• SMTP – Recebe as mensagens de outros servidores, normalmente via o protocolo de transporte SMTP.
Tanto processo 'Local' como o 'SMTP', colocam as mensagens na fila de espera para que sejam atendidas por outro processo. O 'SMTP' antes de colocar na fila, verifica se a origem é um domínio ou um remetente autorizado (controlo de acesso).
3.2 Espera e processamento
• Filtragem – Determina quando novas mensagens estão disponíveis por consulta da fila 'submetidas'. Responsável por filtragem dos emails em vários níveis:
◦ Processa os cabeçalhos dos emails e faz a formatação dos mesmos.
◦ Verifica o formato dos cabeçalhos, se estão de acordo com o formato definido. Adiciona alguns campos como From:, Message_ID: e Date:
◦ Pode fazer a reescrita dos endereços, em função dos valores pré definidos de mapeamento (presentes em tabelas ou base de dados).
• Controlo - Responsável pela gestão das filas de espera e pela distribuição das mensagens aos diversos agentes de entrega:
◦ Espera pela chegada de novas mensagens na fila 'Activas' e depois efectua a distribuição.
◦ O gestor de filas de espera responsável pelo escalonamento das filas, que garanta uma distribuição rápida e justa da entrega dos emails para todos os destinatários dentro dos recursos que dispõe.
Entre o processo 'Filtragem' e 'Controlo' pode existir várias filas de espera. No modelo apresentado tem-se duas filas, mas podem existir mais.
• Activas – Neste fila estão as mensagens que estão a ser processadas pelo 'Controlo' para fazer a entrega ao agente.
• Adiadas – Quando a entrega não é possível devido a falhas temporárias, as mensagens são colocadas nesta fila. As quais são novamente submetidas depois de um tempo pré-definido.
As mensagens corrompidas, em alguns servidores são colocadas numa outra fila. Ou pode-se ter uma conta de email para depositar este tipo de mensagens.
3.3 Entrega
• Local – A entrega local é atendido pelo processo 'Local' que deposita a mensagem na respectiva caixa de email. Mas antes de proceder à entrega, este verifica se existem aliases para o utilizador em questão, em caso afirmativo, a mensagem é enviada para o respectivo endereço (é novamente submetida).
• Cliente SMTP – Quando a entrega destina-se a outro servidor de email, o servidor em questão para a desempenhar a função de cliente. O processo 'Controlo' efectua o pedido de entrega ao processo 'Cliente SMTP'. Cada pedido específica a fila, o endereço do remetente, o domínio ou o host do destino e informações do destinatário. Sendo que o destino é
determinado pelo serviço de DNS.
• Outro tipo de transporte – Pode ser a outros tipos de transportes, ou a programas externos.
(descrito anteriormente)
4. Configurações
As configurações de funcionamento normalmente estão em ficheiros, onde os parâmetros desse ficheiros são lidos pelos processos do servidor de email. (no MS Exchange não sei como é)
Os servidores de email devem responder em conformidade às definições presentes nas configurações.
Em caso de modificação de confirmações com o servidores de email em execução, estas devem ser actualizadas com o mínimo de impacto no funcionamento do sistema.
Principais configurações
Lookup tables
• As lookup tables servem para armazenar e procurar informações sobre o controlo de acesso, reescrita dos endereços e mesmo para filtragem de conteúdo. Em geral, apresentam o seguinte formato:
chave valor
chave valor
... ...
• Estas tabelas são ficheiros indexados que permitem o acesso rápido aos valores armazenados.
• Existem muitas implementações de lookup table, deste simples ficheiros de texto até mesmo ligações com base de dados e servidor LDAP.
Ficheiros Aliases
• Os servidores de email têm normalmente associado um ficheiro ou localização de um outro tipo de meio, que contém as informações relativas aos aliases.
• Os aliases podem ser declarados em estruturas do tipo lookup tables.
• Normalmente não é possível a utilização de alguns nomes de alises que são restritos à administração do sistema, por exemplo postmaster, root, etc.
• O RFC 2142 define um conjunto de nomes para as caixas de email que todos os domínios devem possuir, dependendo dos serviços que têm em execução no seu domínio (postmaster, webmaster, etc.).
Outras considerações de configuração
Existem muitas outras considerações que merecem atenção na sua configuração, como exemplo:
• Configuração da identidade do MTA - Deve-se definir bem quais as informações são expostas aos utilizadores, tendo em conta que estas poderão ser utilizadas para potenciais ataques.
• Controlo de Relay - Deve-se definir bem quem é que tem acesso autorizado para a utilização dos recursos do sistema como relay. Tendo em conta que deve-se restringir ao máximo este tipo de acesso. O controlo de relay permite também minimizar a circulação das mensagens SPAM.
Pode-se limitar o acessos a determinados endereços de IP, mas no caso de endereços dinâmicos isto complica-se pois este tipo de controlo não vai permitir o acesso a um utilizador que devia ter acesso. Para contornar este tipo de problema, recorre-se a mecanismos de autenticação SMTP (descritas mais à frente).
5. Administração
Logging
• Todas as operações efectuadas bem como os seus resultados, devem ser alvo de registo. Nos registos devem constar as operações efectuas com sucesso, os erros e os avisos caso tenham ocorrido.
• Regularmente os registos de log, devem ser analisados, no sentido de determinar como é que o sistema está a comportar, e em caso apresentar anomalias estas poderão ser mais
facilmente resolvidas com a ajuda dos registos.
• Deve-se também definir a capacidade dos logs, ou seja, depois que limite é que começa a eliminar ocorrências de registos.
Controlo sobre o estado do servidor de email
• O administrador do sistema deve saber sempre o estado do sistema, bem como o total controlo sobre o mesmo.
6. Limitações e capacidades
• Limitar a execução de processos a determinadas contas e grupos.
• Limitar os privilégios que cada processo tem.
• Limitar o número de processo que podem ser invocados simultaneamente.
Limitar o números de vezes que um cliente tenta efectuar operações inválidas, pois poderá ser um ataque. Com possibilidade de definir um tempo a partir do qual poderá novamente efectuar o pedido.
7. Processamento dos endereços
Verifica se o endereço está correcto caso contrário efectua as alterações no sentido de ficar com o formato permitido, por exemplo pela adição do domínio ao nome do utilizador. O formato para os endereços no modelo da Internet estão definidos no RFC 2822.
Capacidade de reescrita do endereço em diferentes formatos. Pode-se ter activado a opção de completar automaticamente o endereço de email no formato FQDN - fully qualified domain name.
Canonical addresses
Permite a reescrita de endereços num formato normalizado/comum por exemplo dentro de uma organização. Muitas vezes é utilizado para fazer o mapeamento de endereços internos em endereços públicos.
Masquerading Hostnames
Masquerading permite ocultar o nome do host interno, e faz com que todos os endereços tenham sido originados do host gateway.
Exemplo: Endereços tipo manuel@seridor1.exemplo.pt e ricardo@seridor2.exemplo.pt são convertidos em manuel@exemplo.pt e ricardol@exemplo.pt.
Unknown users
Normalmente os endereços inválidos são rejeitados, mas pode-se implementar um
mecanismo de tratamento dos mesmos, por exemplo criar um endereço que recebe todos os emails dos endereços inválidos.
8. Gestão de filas de espera
• O gestor de filas de espera é um dos componentes mais importantes de um servidor de email. Todos as mensagens de entrada como as de saída, devem passar através das filas de espera.
• Tal como referido existem diferentes filas em função do estado de processamento da mensagem.
• O administrador deve possuir ferramentas que auxiliem na gestão das filas.
• Deve-se garantir que o espaço em disco das filas de espera não ultrapassa o limite permitido.
9. Segurança
Autenticação SASL
O protocolo SMTP base não permite nenhum mecanismo de autenticação dos utilizadores.
Como o endereço dos emails é fácil de falsificar, torna-se difícil determinar o verdadeiro remetente da mensagem, a não ser que o servidor tenha a capacidade de fazer a autenticação dos utilizadores.
Para prevenir de usos não autorizados, pode-se limitar a utilização a determinados endereços IPs. Mas com isto surge o problema quando os utilizadores têm endereços dinâmicos nas suas ligações ao servidor.
O RFC 2554 “SMTP Service Extension for Authentication” fornece uma extensão do protocolo SMTP, que permite a autenticação dos clientes através do protocolo SASL. Pode-se adicionalmente recorrer ao TLS.
O TLS é o método de encriptação de dados mais utilizado na comunicação Webserver e browsers, mas também pode-se utilizar para os servidores de email e os seus clientes. Sendo que em alguns mecanismos de SASL a password é transmitida em claro, podes-e recorrer ao TLS que envia a password em canais seguros.
SASL = autenticação + encriptação SASL – Visão geral
Em primeiro plano tem como objectivo fornecer mecanismo de autenticação dos utilizadores perante o servidor.
O funcionamento do SASL, necessita de saber:
• Mecanismos de autenticação – desafios e respostas entre o cliente e o servidor, e como estas devem ser codificadas para a transmissão.
• Framework de autenticação – refere-se como o servidor guarda e verifica a informação relativa à password.
TLS – Visão geral
• Fornece encriptação dos dados ponto-a-ponto.
• Encriptação a nível da aplicação.
SPF - Sender Policy Framework
SPF permite combater a falsificação de endereços de retorno dos emails (return-path). O mecanismo permite:
• ao administrador de um domínio: definir e publicar uma política SPF, onde são designados os endereços das máquinas autorizadas a enviar mensagens em nome deste domínio; e
• ao administrador de um serviço de email: estabelecer critérios de aceitação de mensagens em função da verificação das políticas SPF publicadas para cada domínio.
10. Email e DNS
Os registos de DNS de diferentes registos oferecem vários tipos de informação, tais como endereços IP, nameservers, hostname aliases e mail routing. Os registos necessários para o serviço de email são:
• A – Mapeamento de nomes em endereços IP.
• CNAME – Apontam para outro hostname em vez do endereço IP.
• MX – Informações sobre o mail-routing.
• PTR – Mapeamento inverso, endereço IP em hostname.
No DNS, o registo MX refere-se ao servidores de email. O registo MX contem informações sobre o servidor e a prioridade (ou preferência) para o envio de emails nesse domínio. Podem existir mais registo do tipo MX, que correspondem a servidores de email com uma prioridade mais baixa que funcionam como servidores de backup. Ou seja recebem os emails até que o principal volte em funcionamento.
11. Email Routing
Let's consider for a moment one way that email routing might work. A user horatio in the domain example.com has a workstation named denmark. He could receive mail by using the email address horatio@denmark.example.com. An MTA with a message to deliver would simply look up the IP address for denmark.example.com and deliver it to that system for the user horatio. This scenario requires that Horatio's workstation is always turned on, that it has a functional MTA running at all times to receive messages, and that it is accessible by unknown MTAs from anywhere on the Internet. Rather than manage hundreds or thousands of MTAs on workstations and expose them to the Internet, nearly all sites make use of mail hubs that receive all the mail for a domain.
MTAs such as Postfix need a way to determine which host or hosts are the mail hubs for a domain.
DNS MX records provide this information.
A mail exchanger either delivers mail it receives or forwards it to another mail system. A domain may have multiple mail systems for reliability, and therefore multiple MX records.
Generally, one host is the primary mail server and the others serve as backup or secondary mail servers. Each MX record in DNS contains a preference value that orders mail systems from most preferred to least preferred.
If no MX records are found for a domain, an MTA checks to see if there is an A record associated with the domain name itself. If there is an A record, the MTA attempts delivery to the system at that IP address.
--- Outras funcionalidades que deve apresentar:
• Gestor de lista de distribuição;
• Gestão e controlo de mensagens SPAM;
• Filtragem de conteúdo;
• Ligação a base de dados externas.
Referências
[1] Kyle Dent. Postfix: The Definitive Guide. O’Reilly Media, Inc., 1st edition, December 2003.
[2] M. Hafiz. Security architecture of mail transfer agents. Master’s thesis, University of Illinois at Urbana-Champaign, 2005.
[3] Postfix Web Page. http://www.postfix.org/.
[4] Bryan Costales, Claus Assmann, George Jansen, and Gregory Shapiro. Sendmail, 4th Edition.
O’Reilly Media, Inc., 4 edition, October 2007.
