108.3 Lição 1

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.

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:

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.

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

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.

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:

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:

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:

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:

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:

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:

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.

É 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:

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.

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 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:

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.