Caracterização dos servidores de email
Neste documento é feita a modulação de um servidor de email, com isto pretende-se descrever as principais funcionalidades e características que um servidor de email deve possuir.
As funcionalidades necessárias:
1. Filas para a recepção/envio de mensagens de email.
2. Suporte às diversas caixas de email (mailbox).
3. Funcionamento correcto com o protocolo de transporte de mensagens (SMTP).
4. Funcionamento com todos os MUA (Mail User Agent).
5. Recepção/envio de mensagens com anexos, onde estes podem ter diferentes tamanhos.
6. Filtros para as mensagens não solicitadas (spam).
7. Listas de email.
E as características gerais :
• Ser facilmente configurável.
• Controlo do seu estado (stoped, running, …).
• Possibilidade de funcionamento como servidor 'relay', para o reencaminhamento de email (dependente do tipo de servidor).
• Utilização de multi-task que permite um aumento das funcionalidades e melhora a gestão dos processos.
• Garantir a segurança/privacidade das mensagens de e-mail
• Possibilidade de interagir com base de dados.
De seguida apresenta-se a descrição de cada funcionalidade necessária, tendo em conta sempre os três casos de estudo.
1. Filas para a recepção/envio de mensagens de email
O MTA pode ter várias filas contendo mensagens a serem enviadas ou mensagens recentemente recebidas. Uma fila, tipicamente contém mensagens com diferentes prioridades.
Como o protocolo SMTP não oferece nenhum mecanismo de escalonamento, este pode ser feito localmente em função do destino ou do tamanho da mensagem.
Servidor MTA deve voltar a colocar na fila, uma mensagem que não foi entregue devido a um erro qualquer.
Se a mensagem a enviar tiver múltiplos destinatários, devem ser colocadas na fila as mensagens que não são entregues imediatamente. Assim como, se uma mensagem permanecer muito tempo na fila, esta deve ser eliminada. Uma opção de implementação é o envio de uma mensagem de erro ao remetente de que a mensagem ainda está pendente e que esta vai ser eliminada.
(falta falar da capacidade das filas)
“Use of Caching”
Como o servidor de DNS pode manter uma “cache” com as recentes informações, o servidor MTA também mantém duas “caches” adicionais.
Na primeira cache deve guardar os IPs dos servidores que têm o serviço SMTP disponível.
Assim evita-se o tráfego na procura desses servidores.
Na segunda cache guarda as informações das sessões SMTP existentes. Após o envio da mensagem e antes de terminar a sessão SMTP, deve ser verificado se existe na fila mais mensagens para o mesmo destino. Deste modo aproveita-se a sessão já existente.
sendmail
O sendmail guarda em uma ou mais filas e utiliza um conceito de grupos para cada fila. No mínimo existe uma fila, normalmente referenciada pela directoria “mqueue”. Cada mensagem só pode pertencer a uma fila única, e o sendmail pode ser configurado para que escolha uma única fila baseando no tipo de grupo a que a mensagem pertence.
Quando as mensagens são guardas na fila, esta é dividida por pedaços. Cada pedaço é que é guardado na fila como ficheiros separados. Isto é, o “header” e e outras informações sobre a mensagem são guardadas em um ficheiro, enquanto o “body” (que contem a parte do conteúdo) é guardada noutro ficheiro. Existem definidos 6 tipos de ficheiros que podem aparecer na directoria da fila. Sendo o tipo de cada ficheiro definido pelas duas primeiras letras no nome do mesmo.
Type Description df Data (message body)
lf Lock file (obsolete as of V5.62) nf ID creation file (obsolete as of V5.62) tf Temporary qf rewrite image
xf Transcript file
qf Queue control file (and headers)
Figura 2: Queue File Types
(explicar melhor o conceito de grupos)
Figura 1: http://www.feep.net/sendmail/tutorial/intro/queue.html
Postfix
O gestor de filas do Postfix tem quatro diferentes tipos de filas: “incoming”, “active”,
“deferred”, e “corrupt”(maildrop). Depois de tratamento inicial de “cleanup”, a fila “incoming”
recebe as novas mensagens. Assumindo que os recursos do sistema estão disponíveis, o gestor de filas move a mensagem para a fila “active” e chama um agente para fazer o entrega da mensagem.
Se este não conseguir fazer a entrega da mensagem, move a mensagem para a fila “deferred” onde permanece algum tempo até que seja entregue.
Se haver necessidade de guardar a mensagem por um tempo indefinido, deve-se mover a mensagem para a fila “hold”. Permanece nesta fila até que seja dito explicitamente para apagar ou mover para outra fila.
Figura 3: Filas em Postfix
Figura 4: Mover para a fila "hold"
MS Exchange
O MS Exchange considera que as mensagens transferidas de um processo para outro devem ser colocadas em filas até que o processo destino aceite a mensagem.
As mensagens podem passar pelo Exchange por três maneiras diferentes. A primeira através do serviço SMTP (as mensagens de email). Na segunda a troca de mensagens criadas por Microsoft Outlook (MAPI) client or an Outlook Web Access (OWA) client . E a terceira, são as mensagens que recebe através dos MTAs.
O Exchange suporta vários tipos de filas para guardar as mensagens. O número exacto e o tipo das filas depende do que pretende implementar.
Exchange uses two types of queues:
System queues. Before a message can be sent from one system to another, several processes examine and prepare the message for its journey over the network. These system processes include activities such as message categorization, address resolution, content conversion, and next-hop routing calculation. System queues hold messages awaiting this type of processing. System queues are always visible using ESM. If messages remain in the system queues for long periods, it can be an indication of problems with the system's messaging processes.
Link queues. Sending a message from one system to another often requires that the message be relayed through one or more intermediate servers in its journey to its final destination. The next server in the journey is known as the next-hop server. Once the routing engine has determined the next-hop server for a message, the message is added to a link queue for the next-hop server. All messages destined for the same nexthop server are queued to the same link queue. Messages remain in a link queue until Exchange can establish an active connection with and can transfer the message to the next-hop server. Link queues are named for the next-hop server. For example, SMTP messages queued for delivery to recipients on company.com will be added to a link queue named company.com (Remote delivery). These next-hop link queues are created and removed as needed.
For example, if the next-hop for a message is the company.com domain, the virtual server will create a temporary link queue for the company.com domain. Once all messages in the link queue have been transferred to company.com, the virtual server removes the queue. If the messages cannot be transferred to the next-hop (e.g., company.com), they are requeued for later retry.
Figura 5: Internal transport architecture for Exchange Server 2003
2. Suporte às diversas caixas de email (mailbox) MS Exchange
http://technet.microsoft.com/en-us/library/bb124699.aspx
Figura 6: http://technet.microsoft.com/pt- br/library/bb124832(EXCHG.65).aspx
