Linux Professional Institute Learning Logo.
Ir para o conteúdo principal
  • Home
    • Todos os recursos
    • LPI Materiais Didáticos
    • Colabore Conosco
    • Publishing Partners
    • Seja um Publishing Partner
    • Quem Somos
    • FAQ
    • Colaboradores
    • Traduções
    • Contato
  • LPI.org
108.3 Lição 1
Tópico 105: Shells e scripts do Shell
105.1 Personalizar e trabalhar no ambiente shell
  • 105.1 Lição 1
  • 105.1 Lição 2
  • 105.1 Lição 3
105.2 Editar e escrever scripts simples
  • 105.2 Lição 1
  • 105.2 Lição 2
Tópico 106: Interfaces de usuário e Desktops
106.1 Instalar e configurar o X11
  • 106.1 Lição 1
106.2 Desktops gráficos
  • 106.2 Lição 1
106.3 Acessibilidade
  • 106.3 Lição 1
Tópico 107: Tarefas administrativas
107.1 Administrar contas de usuário, grupos e arquivos de sistema relacionados
  • 107.1 Lição 1
  • 107.1 Lição 2
107.2 Automatizar e agendar tarefas administrativas de sistema
  • 107.2 Lição 1
  • 107.2 Lição 2
107.3 Localização e internacionalização
  • 107.3 Lição 1
Tópico 108: Serviços essenciais do sistema
108.1 Manutenção da data e hora do sistema
  • 108.1 Lição 1
  • 108.1 Lição 2
108.2 Log do sistema
  • 108.2 Lição 1
  • 108.2 Lição 2
108.3 Fundamentos de MTA (Mail Transfer Agent)
  • 108.3 Lição 1
108.4 Configurar impressoras e impressão
  • 108.4 Lição 1
Tópico 109: Fundamentos de Rede
109.1 Fundamentos de protocolos de internet
  • 109.1 Lição 1
  • 109.1 Lição 2
109.2 Configuração persistente de rede
  • 109.2 Lição 1
  • 109.2 Lição 2
109.3 Soluções para problemas simples de rede
  • 109.3 Lição 1
  • 109.3 Lição 2
109.4 Configurar DNS cliente
  • 109.4 Lição 1
Tópico 110: Segurança
110.1 Tarefas administrativas de segurança
  • 110.1 Lição 1
110.2 Configurar a segurança do host
  • 110.2 Lição 1
110.3 Proteção de dados com criptografia
  • 110.3 Lição 1
  • 110.3 Lição 2
How to get certified
  1. Tópico 108: Serviços essenciais do sistema
  2. 108.3 Fundamentos de MTA (Mail Transfer Agent)
  3. 108.3 Lição 1

108.3 Lição 1

Certificação:

LPIC-1

Versão:

5.0

Tópico:

108 Serviços essenciais do sistema

Objetivo:

108.3 Noções básicas do Mail Transfer Agent (MTA)

Lição:

1 de 1

Introdução

Nos sistemas operacionais do tipo Unix, como o Linux, cada usuário tem sua própria caixa de entrada: um local especial no sistema de arquivos, inacessível a outros usuários não-root, para armazenar as mensagens de email pessoais do usuário. Novas mensagens são adicionadas à caixa de entrada do usuário pelo Mail Transfer Agent (MTA). O MTA é um programa executado como um serviço do sistema que coleta mensagens enviadas por outras contas locais, bem como mensagens recebidas da rede, enviadas por contas de usuários remotos.

O mesmo MTA é responsável pelo envio de mensagens para a rede, caso o endereço de destino se refira a uma conta remota. Ele faz isso usando um local do sistema de arquivos como uma caixa de saída de email para todos os usuários do sistema: assim que um usuário coloca uma nova mensagem na caixa de saída, o MTA identifica o nó da rede de destino a partir do nome de domínio fornecido pelo endereço de email do destino — a parte após o sinal @ — e então tenta transferir a mensagem para o MTA remoto usando o Simple Mail Transfer Protocol (SMTP). O SMTP foi projetado pensando em redes não confiáveis; portanto, ele tenta estabelecer rotas de entrega alternativas caso o nó de destino principal do email esteja inacessível.

MTA local e remoto

As contas de usuário tradicionais das máquinas conectadas em rede constituem o cenário mais simples de troca de emails, em que cada nó da rede executa seu próprio daemon MTA. Nenhum outro software além do MTA é necessário para enviar e receber mensagens de email. Na prática, porém, é mais comum usar uma conta de email remota e não ter um serviço MTA local ativo (ou seja, usar um aplicativo cliente de email para acessar a conta remota).

Ao contrário das contas locais, uma conta de email remota — também chamada de caixa de correio remota — requer autenticação do usuário para conceder acesso à caixa de correio do usuário e ao MTA remoto (neste caso, simplesmente chamado de servidor SMTP). Ao passo que o usuário que interage com uma caixa de entrada local e o MTA já está identificado pelo sistema, um sistema remoto precisa verificar a identidade do usuário antes de manipular suas mensagens por meio de IMAP ou POP3.

Note

Hoje em dia, o método mais comum para enviar e receber emails é através de uma conta hospedada em um servidor remoto; por exemplo, um servidor de email centralizado de uma empresa que hospeda todas as contas dos funcionários ou um serviço de email pessoal, como o Gmail do Google. Em vez de coletar as mensagens entregues localmente, o aplicativo cliente de email se conecta à caixa de correio remota e recupera as mensagens de lá. Os protocolos POP3 e IMAP são comumente usados para recuperar as mensagens no servidor remoto, mas outros protocolos proprietários não padrão também podem ser usados.

Quando um daemon MTA está sendo executado no sistema local, os usuários locais podem enviar um email para outros usuários locais ou usuários em uma máquina remota, desde que seu sistema também tenha um serviço MTA que aceite conexões de rede. A porta TCP 25 é a porta padrão para a comunicação SMTP, mas outras portas também podem ser usadas, dependendo do esquema de autenticação e/ou criptografia empregado (se houver).

Deixando de lado as topologias que envolvem o acesso a caixas de correio remotas, uma rede de troca de emails entre contas de usuários Linux comuns pode ser implementada, desde que todos os nós da rede tenham um MTA ativo capaz de realizar as seguintes tarefas:

  • Manter a fila de saída das mensagens a serem enviadas. Para cada mensagem na fila, o MTA local avaliará o MTA de destino a partir do endereço do destinatário.

  • Comunicar-se com daemons MTA remotos usando SMTP. O MTA local deve ser capaz de usar o protocolo SMTP sobre a pilha TCP/IP para receber, enviar e redirecionar mensagens de/para outros daemons MTA remotos.

  • Manter uma caixa de entrada individual para cada conta local. O MTA geralmente armazena as mensagens no formato mbox: um único arquivo de texto contendo todas as mensagens de email em sequência.

Normalmente, os endereços de email especificam um nome de domínio como o local, por exemplo lpi.org em info@lpi.org. Quando for esse o caso, o MTA do remetente consultará o serviço de DNS em busca do registro MX correspondente. O registro DNS MX contém o endereço IP do MTA que gerencia o email para esse domínio. Se o mesmo domínio tiver mais de um registro MX especificado no DNS, o MTA tentará contatá-los de acordo com seus valores de prioridade. Se o endereço do destinatário não especificar um nome de domínio ou se o domínio não tiver um registro MX, a parte após o símbolo @ será tratada como o host do MTA de destino.

É preciso pensar na segurança se os hosts MTA forem ficar visíveis para os hosts na internet. Por exemplo, um usuário desconhecido poderia usar o MTA local para se passar por outro usuário e enviar emails potencialmente perigosos. Um MTA que retransmite cegamente um email é conhecido como open relay, quando pode ser usado como intermediário para potencialmente disfarçar o verdadeiro remetente da mensagem. Para evitar esses usos indevidos, recomenda-se aceitar conexões somente de domínios autorizados e implementar um esquema de autenticação seguro.

Além disso, existem muitas implementações de MTA diferentes para Linux, cada qual enfocando aspectos específicos como compatibilidade, desempenho, segurança etc. No entanto, todos os MTAs seguem os mesmos princípios básicos e fornecem recursos semelhantes.

MTAs do Linux

O MTA tradicionalmente disponível para os sistemas Linux é o Sendmail, um MTA de uso geral bastante flexível adotado por muitos sistemas operacionais do tipo Unix. Outros MTAs comuns são o Postfix, o qmail e o Exim. O principal motivo para escolher um MTA alternativo é implementar recursos avançados com mais facilidade, pois configurar servidores de email personalizados no Sendmail pode ser uma tarefa complicada. Além disso, cada distribuição pode ter seu MTA preferido, com ajustes predefinidos apropriados à maioria das configurações comuns. Todos os MTAs pretendem ser substitutos diretos do Sendmail e, portanto, todos os aplicativos compatíveis com o Sendmail costumam funcionar, independentemente do MTA que está sendo usado.

Se o MTA estiver em execução, mas não aceitar conexões de rede, ele só poderá entregar mensagens de email na máquina local. Para o MTA sendmail, o arquivo /etc/mail/sendmail.mc deve ser modificado para aceitar conexões não locais. Para isso, a entrada

DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl

deve ser modificada com o endereço de rede correto e o serviço precisa ser reiniciado. Algumas distribuições Linux, como o Debian, podem oferecer ferramentas de configuração para ajudar a guarnecer o servidor de email com um conjunto predefinido de recursos comumente usados.

Tip

Devido a problemas de segurança, a maioria das distribuições Linux não instala um MTA por padrão. Para testar os exemplos fornecidos nesta lição, verifique se existe um MTA em execução em todas as máquinas e se elas aceitam conexões na porta TCP 25. Para fins de segurança, esses sistemas não devem ser expostos a conexões de entrada da internet pública durante o teste.

Uma vez que o MTA está em execução e aceitando conexões da rede, as novas mensagens de email são passadas para ele com comandos SMTP enviados por meio de uma conexão TCP. O comando nc — um utilitário de rede que lê e grava dados genéricos na rede — pode ser usado para enviar comandos SMTP diretamente para o MTA. Se o comando nc não estiver disponível, ele será instalado com o pacote ncat ou nmap-ncat, dependendo do sistema de gerenciamento de pacotes em uso. Escrever comandos SMTP diretamente no MTA é útil para entender melhor o protocolo e outros conceitos gerais sobre o email, bem como para ajudar a diagnosticar problemas no processo de entrega de mensagens.

Se, por exemplo, a usuária emma no host lab1.campus deseja enviar uma mensagem ao usuário dave no host lab2.campus, ela pode usar o comando nc para conectar-se diretamente ao MTA lab2.campus, supondo que ele esteja escutando na porta TCP 25:

$ nc lab2.campus 25
220 lab2.campus ESMTP Sendmail 8.15.2/8.15.2; Sat, 16 Nov 2019 00:16:07 GMT
HELO lab1.campus
250 lab2.campus Hello lab1.campus [10.0.3.134], pleased to meet you
MAIL FROM: emma@lab1.campus
250 2.1.0 emma@lab1.campus... Sender ok
RCPT TO: dave@lab2.campus
250 2.1.5 dave@lab2.campus... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Subject: Recipient MTA Test

Hi Dave, this is a test for your MTA.
.
250 2.0.0 xAG0G7Y0000595 Message accepted for delivery
QUIT
221 2.0.0 lab2.campus closing connection

Assim que a conexão é estabelecida, o MTA remoto se identifica e está pronto para receber comandos SMTP. O primeiro comando SMTP no exemplo, HELO lab1.campus, indica lab1.campus como o iniciador da troca. Os dois comandos seguintes, MAIL FROM: emma@lab1.campus e RCPT TO: dave@lab2.campus, indicam o remetente e o destinatário. A mensagem de email em si começa após o comando DATA e termina com um ponto sozinho em uma linha. Para adicionar um campo subject (assunto) ao email, ele deve estar na primeira linha após o comando DATA, como mostrado no exemplo. Quando o campo de assunto é usado, deve haver uma linha em branco separando-o do conteúdo do email. O comando QUIT termina a conexão com o MTA no host lab2.campus.

No host lab2.campus, o usuário dave receberá uma mensagem semelhante a You have new mail in /var/spool/mail/dave assim que entrar em uma sessão do shell. Este arquivo conterá a mensagem de email bruta enviada por emma, bem como os cabeçalhos adicionados pelo MTA:

$ cat /var/spool/mail/dave
From emma@lab1.campus  Sat Nov 16 00:19:13 2019
Return-Path: <emma@lab1.campus>
Received: from lab1.campus (lab1.campus [10.0.3.134])
	by lab2.campus (8.15.2/8.15.2) with SMTP id xAG0G7Y0000595
	for dave@lab2.campus; Sat, 16 Nov 2019 00:17:06 GMT
Date: Sat, 16 Nov 2019 00:16:07 GMT
From: emma@lab1.campus
Message-Id: <201911160017.xAG0G7Y0000595@lab2.campus>
Subject: Recipient MTA Test

Hi Dave, this is a test for your MTA.

O cabeçalho Received: mostra que a mensagem de lab1.campus foi recebida diretamente por lab2.campus. Por padrão, os MTAs só aceitam mensagens para destinatários locais. O seguinte erro provavelmente ocorrerá se o usuário emma tentar enviar um email para o usuário henry no host lab3.campus usando o MTA lab2.campus em vez do MTA correto lab3.campus:

$ nc lab2.campus 25
220 lab2.campus ESMTP Sendmail 8.15.2/8.15.2; Sat, 16 Nov 2019 00:31:44 GMT
HELO lab1.campus
250 lab2.campus Hello lab1.campus [10.0.3.134], pleased to meet you
MAIL FROM: emma@lab1.campus
250 2.1.0 emma@lab1.campus... Sender ok
RCPT TO: henry@lab3.campus
550 5.7.1 henry@lab3.campus... Relaying denied

Os números de resposta do SMTP que começam com 5, como na mensagem Relaying denied (retransmissão negada), indicam um erro. Existem situações legítimas em que a retransmissão é desejável, como quando os hosts que enviam e recebem emails não estão conectados o tempo todo: um MTA intermediário pode ser configurado para aceitar emails destinados a outros hosts, agindo como um servidor SMTP retransmissor (ou relay) capaz de encaminhar mensagens entre MTAs.

A possibilidade de rotear o tráfego de email por meio de servidores SMTP intermediários desestimula a tentativa de conexão direta ao host indicado pelo endereço de email do destinatário, como mostrado nos exemplos anteriores. Além disso, os endereços de email geralmente têm um nome de domínio como local (após o @), de forma que o nome real do host MTA correspondente deve ser recuperado através do DNS. Portanto, é recomendável delegar a tarefa de identificar o host de destino apropriado ao MTA local ou ao servidor SMTP remoto quando usamos caixas de correio remotas.

O Sendmail fornece o comando sendmail para realizar uma série de operações relacionadas a email, incluindo auxiliar na composição de novas mensagens. Ele também requer que o usuário digite os cabeçalhos do email manualmente, mas de uma forma mais amigável do que usar comandos SMTP diretamente. Assim, um método mais adequado para o usuário emma@lab1.campus enviar uma mensagem de email para dave@lab2.campus seria:

$ sendmail dave@lab2.campus
From: emma@lab1.campus
To: dave@lab2.campus
Subject: Sender MTA Test

Hi Dave, this is a test for my MTA.
.

Aqui, novamente, o ponto sozinho em uma linha finaliza a mensagem. A mensagem deve ser enviada imediatamente ao destinatário, a menos que o MTA local não tenha conseguido contatar o MTA remoto. O comando mailq, se executado pelo root, mostra todas as mensagens não entregues. Se, por exemplo, o MTA em lab2.campus não respondeu, então o comando mailq listará a mensagem não entregue e a causa da falha:

# mailq
		/var/spool/mqueue (1 request)
-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient-----------
xAIK3D9S000453       36 Mon Nov 18 20:03 <emma@lab1.campus>
                 (Deferred: Connection refused by lab2.campus.)
					 <dave@lab2.campus>
		Total requests: 1

O local padrão da fila da caixa de saída é /var/spool/mqueue/, mas diferentes MTAs podem usar locais diversos no diretório /var/spool/. O Postfix, por exemplo, cria uma árvore de diretórios sob /var/spool/postfix/ para gerenciar a fila. O comando mailq equivale a sendmail -bp, e eles devem estar presentes qualquer que seja o MTA instalado no sistema. Para garantir a compatibilidade reversa, a maioria dos MTAs inclui esses comandos tradicionais de administração de email.

Se o principal host de destino do email — quando fornecido a partir de um registro MX DNS para o domínio — estiver inacessível, o MTA tentará entrar em contato com as entradas com prioridade mais baixa (se houver alguma especificada). Se nenhuma delas estiver acessível, a mensagem ficará na fila da caixa de saída local para ser enviada posteriormente. Se configurado para isso, o MTA pode verificar periodicamente a disponibilidade dos hosts remotos e realizar uma nova tentativa de entrega. Se estiver usando um MTA compatível com o Sendmail, uma nova tentativa ocorrerá imediatamente com o comando sendmail -q.

O Sendmail armazena as mensagens recebidas em um arquivo com o nome do proprietário da caixa de entrada correspondente, por exemplo /var/spool/mail/dave. Outros MTAs, como o Postfix, podem armazenar as mensagens de email recebidas em locais como /var/mail/dave, mas o conteúdo do arquivo é o mesmo. No exemplo, o comando sendmail foi usado no host do remetente para compor a mensagem, de modo que os cabeçalhos brutos da mensagem mostram que o email atravessou etapas extras antes de chegar ao destino final:

$ cat /var/spool/mail/dave
From emma@lab1.campus  Mon Nov 18 20:07:39 2019
Return-Path: <emma@lab1.campus>
Received: from lab1.campus (lab1.campus [10.0.3.134])
	by lab2.campus (8.15.2/8.15.2) with ESMTPS id xAIK7clC000432
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
	for <dave@lab2.campus>; Mon, 18 Nov 2019 20:07:38 GMT
Received: from lab1.campus (localhost [127.0.0.1])
	by lab1.campus (8.15.2/8.15.2) with ESMTPS id xAIK3D9S000453
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
	for <dave@lab2.campus>; Mon, 18 Nov 2019 20:03:13 GMT
Received: (from emma@localhost)
	by lab1.campus (8.15.2/8.15.2/Submit) id xAIK0doL000449
	for dave@lab2.campus; Mon, 18 Nov 2019 20:00:39 GMT
Date: Mon, 18 Nov 2019 20:00:39 GMT
Message-Id: <201911182000.xAIK0doL000449@lab1.campus>
From: emma@lab1.campus
To: dave@lab2.campus
Subject: Sender MTA Test

Hi Dave, this is a test for my MTA.

De baixo para cima, as linhas que começam com Received: mostram a rota seguida pela mensagem. A mensagem foi enviada pela usuária emma com o comando sendmail dave@lab2.campus emitido em lab1.campus, conforme declarado pelo primeiro cabeçalho Received:. Em seguida, ainda em lab1.campus, o MTA usa ESMTPS — um superconjunto do SMTP, que adiciona extensões de criptografia — para enviar a mensagem para o MTA em lab2.campus, conforme especificado pelo último (topo) cabeçalho Received:.

O MTA conclui seu trabalho depois que a mensagem é salva na caixa de entrada do usuário. É comum realizar algum tipo de filtragem de email, como bloqueadores de spam ou a aplicação de regras de filtragem definidas pelo usuário. Essas tarefas são executadas por aplicativos de terceiros, trabalhando em conjunto com o MTA. O MTA poderia, por exemplo, chamar o utilitário SpamAssassin para marcar mensagens suspeitas usando seus recursos de análise de texto.

Embora possível, não é conveniente ler diretamente o arquivo da caixa de correio. Recomenda-se usar um programa cliente de email (por exemplo, Thunderbird, Evolution ou KMail), que analisará o arquivo e gerenciará as mensagens apropriadamente. Esses programas também oferecem recursos extras, como atalhos para ações comuns, subdiretórios de caixa de entrada, etc.

O comando mail e Mail User Agents (MUA)

É possível escrever uma mensagem de email diretamente em seu formato bruto, mas é muito mais prático usar um aplicativo cliente — também conhecido como MUA (Mail User Agent ou agente do usuário de email) — para agilizar o processo e evitar erros. O MUA cuida do trabalho de bastidores, ou seja, o cliente de email apresenta e organiza as mensagens recebidas e faz a comunicação adequada com o MTA após o usuário redigir um email.

Existem muitos tipos distintos de Mail User Agents. Aplicativos de desktop como o Mozilla Thunderbird e o Evolution, do Gnome, oferecem suporte a contas de email locais e remotas. Mesmo as interfaces Webmail podem ser vistas como um tipo de MUA, pois intermediam a interação entre o usuário e o MTA subjacente. No entanto, os clientes de email não estão restritos às interfaces gráficas: os clientes de email de console são amplamente usados para acessar caixas de correio não integradas a uma interface gráfica e para automatizar tarefas relacionadas a email em scripts do shell.

Originalmente, o comando mail do Unix destinava-se apenas a compartilhar mensagens entre usuários do sistema local (o primeiro comando mail data da primeira edição do Unix, lançada em 1971). Quando as trocas de emails em rede se tornaram mais expressivas, outros programas foram criados para lidar com o novo sistema de entrega e gradualmente substituíram o antigo programa mail.

Hoje em dia, o comando mail mais comumente usado é fornecido pelo pacote mailx, compatível com todos os recursos de email modernos. Na maioria das distribuições Linux, o comando mail é apenas um link simbólico para o comando mailx. Outras implementações, como o pacote GNU Mailutils, basicamente fornecem os mesmos recursos do mailx. Existem, no entanto, pequenas diferenças entre eles, especialmente com relação às opções de linha de comando.

Independentemente de sua implementação, todas as variações modernas do comando mail operam em dois modos: modo normal e modo de envio. Se um endereço de email for fornecido como argumento para o comando mail, ele entrará no modo de envio; caso contrário, entrará no modo normal (leitura). No modo normal, as mensagens recebidas são listadas com um índice numérico para cada uma, para que o usuário possa consultá-las individualmente ao digitar comandos no prompt interativo. O comando print 1 pode ser usado para exibir o conteúdo da mensagem número 1, por exemplo. Comandos interativos podem ser abreviados, de forma que comandos como print, delete ou reply podem ser substituídos por p, d ou r, respectivamente. O comando mail sempre considerará a última mensagem recebida ou visualizada quando o número do índice da mensagem for omitido. O comando quit ou q serve para sair do programa.

O modo de envio (send mode) é especialmente útil para enviar mensagens de email automatizadas. Ele pode ser usado, por exemplo, para enviar um email ao administrador do sistema se um script de manutenção programado falhar em realizar sua tarefa. No modo de envio, o mail usa o conteúdo da entrada padrão como corpo da mensagem:

$ mail -s "Maintenance fail" henry@lab3.campus <<<"The maintenance script failed at `date`"

Neste exemplo, a opção -s foi adicionada para incluir um campo de assunto na mensagem. O corpo da mensagem foi fornecido pelo redirecionamento Hereline para a entrada padrão, mas o conteúdo de um arquivo ou a saída de um comando também pode ser canalizado com um pipe para o stdin do programa. Se nenhum conteúdo for fornecido por um redirecionamento para a entrada padrão, o programa aguardará que o usuário entre no corpo da mensagem. Nesse caso, a combinação de teclas Ctrl+D encerra a mensagem. O comando mail é concluído imediatamente após a mensagem ser adicionada à fila da caixa de saída.

Entrega personalizada

Por padrão, as contas de email em um sistema Linux são associadas às contas de sistema padrão. Por exemplo, se a usuária Carol tem o nome de login carol no host lab2.campus, seu endereço de email será carol@lab2.campus. Esta associação direta entre contas de sistema e caixas de correio pode ser estendida por métodos padrão fornecidos pela maioria das distribuições Linux, em particular o mecanismo de roteamento de email fornecido pelo arquivo /etc/aliases.

Um alias de email é um destinatário de email “virtual” cujas mensagens recebidas são redirecionadas para caixas de correio locais existentes ou para outros tipos de destino de armazenamento ou processamento de mensagens. Os aliases são úteis, por exemplo, para colocar as mensagens enviadas para postmaster@lab2.campus na caixa de correio de Carol, que é uma caixa de correio local comum do sistema lab2.campus. Para isso, a linha postmaster: carol deve ser adicionada ao arquivo /etc/aliases em lab2.campus. Após modificar o arquivo /etc/aliases, o comando newaliases deve ser executado para atualizar os bancos de dados de aliases do MTA e efetivar as alterações. Os comandos sendmail -bi ou sendmail -I também servem para atualizar o banco de dados de aliases.

Os aliases são definidos em linhas, no formato `<alias>: <destination> `. Além das caixas de correio locais comuns, indicadas pelo nome de usuário correspondente, outros tipos de destino estão disponíveis:

  • Um caminho completo (começando com /) para um arquivo. As mensagens enviadas para o alias correspondente serão anexadas ao arquivo.

  • Um comando para processar a mensagem. <destination> deve começar com um caractere de pipe e, se o comando contiver caracteres especiais (como espaços em brancos), ele deve ser posto entre aspas duplas. Por exemplo, o alias subscribe: |subscribe.sh em lab2.campus encaminha todas as mensagens enviadas para subscribe@lab2.campus para a entrada padrão do comando subscribe.sh. Se sendmail estiver rodando no modo restrito do shell, os comandos permitidos — ou os links para eles — deverão estar em /etc/smrsh/.

  • Um arquivo de inclusão. Um único alias pode ter diversos destinos (separados por vírgulas) e, portanto, pode ser mais prático mantê-los em um arquivo externo. A palavra-chave :include: deve indicar o caminho do arquivo, como em :include:/var/local/destinations

  • Um endereço externo. Os aliases também podem encaminhar mensagens para endereços de email externos.

  • Outro alias.

Um usuário local sem privilégios pode definir aliases para seu próprio email editando o arquivo .forward em seu diretório inicial. Como os aliases podem afetar apenas sua própria caixa de correio, somente a parte <destination> é necessária. Para encaminhar todos os emails recebidos para um endereço externo, por exemplo, o usuário dave em lab2.campus poderia criar o seguinte arquivo ~/.forward:

$ cat ~/.forward
emma@lab1.campus

Ele encaminhará todas as mensagens de email enviadas para dave@lab2.campus para emma@lab1.campus. Como no caso do arquivo /etc/aliases, outras regras de redirecionamento podem ser adicionadas a .forward, uma por linha. Entretanto, o arquivo .forward deve ser gravável apenas por seu dono e não é necessário executar o comando newaliases após modificá-lo. Os arquivos que começam com um ponto não aparecem nas listagens de arquivos regulares, fazendo com que o usuário desconheça alguns dos aliases ativos. Portanto, é importante verificar se o arquivo existe ao diagnosticar problemas de entrega de email.

Exercícios Guiados

  1. Sem outras opções ou argumentos, o comando mail henry@lab3.campus inicia o modo de inserção de dados para que o usuário possa digitar a mensagem para henry@lab3.campus. Depois de terminar a mensagem, qual pressionamento de tecla fecha o modo de inserção e envia o email?

  2. Qual comando o usuário root pode executar para listar as mensagens não entregues que se originaram no sistema local?

  3. Como um usuário sem privilégios pode usar o método MTA padrão para encaminhar automaticamente todos os seus emails recebidos para o endereço dave@lab2.campus?

Exercícios Exploratórios

  1. Usando o comando mail fornecido por mailx, qual comando enviará uma mensagem para emma@lab1.campus com o arquivo logs.tar.gz como um anexo e a saída do comando uname -a como o corpo do email?

  2. Um administrador de serviços de email deseja monitorar as transferências de email pela rede, mas não quer sobrecarregar sua caixa de correio com mensagens de teste. Como esse administrador poderia configurar um alias de email em todo o sistema de forma a redirecionar todos os emails enviados ao usuário test para o arquivo /dev/null?

  3. Que comando, além de newaliases, poderia ser usado para atualizar o banco de dados de aliases após se adicionar um novo alias a /etc/aliases?

Resumo

Esta lição abordou a função e o uso de Mail Transfer Agents (Agentes de transferência de correio) nos sistemas Linux. O MTA fornece um método padrão para comunicação entre contas de usuário e pode ser combinado com outros softwares para fornecer funcionalidades extras. A lição discutiu os seguintes tópicos:

  • Conceitos de tecnologias, caixas de correio e protocolos relacionados ao email.

  • Como os MTAs do Linux trocam mensagens pela rede.

  • Clientes de email e MUAs (Mail User Agents) no console.

  • Aliases e encaminhamento de email local.

As tecnologias, comandos e procedimentos abordados foram:

  • SMTP e protocolos relacionados.

  • MTAs disponíveis para o Linux: Sendmail, Postfix, qmail, Exim.

  • Comandos de MTA e MUA: sendmail e mail.

  • Arquivos e comandos administrativos: mailq, /etc/aliases, newaliases, ~/.forward.

Respostas aos Exercícios Guiados

  1. Sem outras opções ou argumentos, o comando mail henry@lab3.campus inicia o modo de inserção de dados para que o usuário possa digitar a mensagem para henry@lab3.campus. Depois de terminar a mensagem, qual pressionamento de tecla fecha o modo de inserção e envia o email?

    Pressionar Ctrl+D fechará o programa e disparará o email.

  2. Qual comando o usuário root pode executar para listar as mensagens não entregues que se originaram no sistema local?

    O comando mailq ou sendmail -bp.

  3. Como um usuário sem privilégios pode usar o método MTA padrão para encaminhar automaticamente todos os seus emails recebidos para o endereço dave@lab2.campus?

    O usuário deve adicionar dave@lab2.campus em ~/.forward.

Respostas aos Exercícios Exploratórios

  1. Usando o comando mail fornecido por mailx, qual comando enviará uma mensagem para emma@lab1.campus com o arquivo logs.tar.gz como um anexo e a saída do comando uname -a como o corpo do email?

    uname -a | mail -a logs.tar.gz emma@lab1.campus

  2. Um administrador de serviços de email deseja monitorar as transferências de email pela rede, mas não quer sobrecarregar sua caixa de correio com mensagens de teste. Como esse administrador poderia configurar um alias de email em todo o sistema de forma a redirecionar todos os emails enviados ao usuário test para o arquivo /dev/null?

    A linha test: /dev/null em /etc/aliases redireciona todas as mensagens enviadas para a caixa de correio local test para o arquivo /dev/null.

  3. Que comando, além de newaliases, poderia ser usado para atualizar o banco de dados de aliases após se adicionar um novo alias a /etc/aliases?

    O comando sendmail -bi ou sendmail -I.

Linux Professional Insitute Inc. Todos os direitos reservados. Visite o site dos Materiais Didáticos: https://learning.lpi.org
31/5000 Este trabalho está licenciado sob a Licença Creative Commons Atribuição-Uso Não-Comercial-NãoDerivativos 4.0 Internacional.

Próxima Lição

108.4 Configurar impressoras e impressão (108.4 Lição 1)

Ir para a próxima lição

Linux Professional Insitute Inc. Todos os direitos reservados. Visite o site dos Materiais Didáticos: https://learning.lpi.org
31/5000 Este trabalho está licenciado sob a Licença Creative Commons Atribuição-Uso Não-Comercial-NãoDerivativos 4.0 Internacional.

A LPI é uma organização sem fins lucrativos.

© 2025 O Linux Professional Institute (LPI) é um organismo de apoio aos profissionais de Open Source e referência mundial em certificação. Com mais de 250.000 pessoas certificadas, somos o principal organismo de certificação independente para Linux e Open Source do mundo. O LPI certificou profissionais de mais de 180 países, oferece exames em diversos idiomas e tem centenas de parcerias de formação em todo o globo.

Nossa missão é proporcionar oportunidades econômicas e criativas para todos, tornando universalmente acessível a certificação de conhecimentos e competências em matéria de Open Source.

  • LinkedIn
  • flogo-RGB-HEX-Blk-58 Facebook
  • Twitter
  • Entre em Contato
  • Política de Privacidade e Cookies

Encontrou um erro ou quer ajudar a aprimorar esta página? Escreva pra nós.

© 1999–2025 The Linux Professional Institute Inc. Todos os direitos reservados.