Documente Academic
Documente Profesional
Documente Cultură
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.
“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.
Figura 1: http://www.feep.net/sendmail/tutorial/intro/queue.html
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)
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.
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.
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 6: http://technet.microsoft.com/pt-
br/library/bb124832(EXCHG.65).aspx
MS Exchange
http://technet.microsoft.com/en-us/library/bb124699.aspx