Product SiteDocumentation Site

Capítulo 11. Serviços de Rede: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

11.1. Servidor de Correio Eletrônico
11.1.1. Instalando o Postfix
11.1.2. Configurando Domínios Virtuais
11.1.3. Restrições para Recebimento e Envio
11.1.4. Configurando "listas cinzas" (greylisting)
11.1.5. Personalização de filtros baseados no destinatário
11.1.6. Integrating an Antivirus Filter
11.1.7. Lutando contr o spam com SPF, DKIM y DMARC
11.1.8. SMTP autenticado
11.2. Servidor web (HTTP)
11.2.1. Instalação do Apache
11.2.2. Adicionando suporte a SSL
11.2.3. Configuração de servidores virtuais
11.2.4. Diretivas comuns
11.2.5. Analisadores de Log
11.3. Servidor de Arquivos FTP
11.4. Servidor de Arquivos NFS
11.4.1. Proteção do NFS
11.4.2. Servidor NFS
11.4.3. Cliente NFS
11.5. Configurando um Compartilhamento Windows com o Samba
11.5.1. Servidor Samba
11.5.2. Cliente Samba
11.6. Proxy HTTP/FTP
11.6.1. Instalando
11.6.2. Configurando um Cache
11.6.3. Configurando um Filtro
11.7. Diretório LDAP
11.7.1. Instalando
11.7.2. Preenchendo o Diretório
11.7.3. Gerenciando Contas com LDAP
11.8. Serviços de Comunicação em Tempo Real
11.8.1. Configurações de DNS para serviços RTC
11.8.2. Servidor TURN
11.8.3. Servidor Proxy SIP
11.8.4. Servidor XMPP
11.8.5. Rodando serviços na porta 443
11.8.6. Adicionando WebRTC
Serviços de rede são programas que os usuários interagem diretamente no seu dia-a-dia. Eles são a ponta do icebergue da informação, e este capítulo foca neles; as partes escondidas nas quais eles dependem são a infraestrutura que nós já descrevemos. Normalmente eles precisam da tecnologia de criptografia descrita em Seção 10.2, “Certificados X.509”.

11.1. Servidor de Correio Eletrônico

Os administradores da Falcot Corp selecionaram o Postfiz como servidor de correio eletrônico, devido a sua confiabilidade e fácil configuração. De fato, seu projeto reforça que cada tarefa é implementada em um processo com um conjunto mínimo de permissões, que é uma medida de mitigação contra problemas de segurança.

11.1.1. Instalando o Postfix

O pacote postfix inclui o daemon SMTP principal. Outros pacotes (como o postfix-ldap e o postfix-pgsql) adicionam funcionalidades extras ao Postfix, incluindo acesso a bancos de dados. Você só deve instalá-los se souber que precisa deles.
Diversas questões Debconf são feitas durante o processo de instalação do pacote. As respostas permitem gerar a primeira versão do arquivo de configuração /etc/postfix/main.cf.
A primeira pergunta é sobre qual o tipo de instalação. Apenas duas das respostas propostas são relevantes no caso de um servidor conectado à internet , "site de internet" e "internet com smarthost". O primeiro é apropriado para um servidor que recebe e-mails entrantes e envia e-mails saintes diretamente aos seus destinatários, e portanto é se adapta bem ao caso da Falcot Corp . o último é apropriado para um servidor que recebe e-mails recebidos normalmente, mas que envia e-mails saintes através de um servidor SMTP intermediário - o "smarthost" - ao invés de diretamente para o servidor do destinatário . Isto é útil para os indivíduos com um endereço IP dinâmico , uma vez que muitos servidores de e-mail rejeitam mensagens diretas de endereços IP dinâmicos. Neste caso, o smarthost será geralmente o servidor SMTP do ISP, que é sempre configurado para aceitar e-mail proveniente de clientes do ISP e transmiti-los de forma adequada. Esta configuração (com um smarthost) também é relevante para os servidores que não estão permanentemente conectados à internet, uma vez que se evita ter de gerenciar uma fila de mensagens não entregues que precisa ser repetida mais tarde.
A segunda questão diz respeito ao nome completo da máquina, utilizada para gerar os endereços de e-mail a partir de um nome de usuário local; o nome completo da máquina acaba como a parte após o arroba ("@"). No caso da Falcot, a resposta deveria ser mail.falcot.com. Esta é a única pergunta feita por padrão, mas a configuração gerada não é completa o suficiente para as necessidades de Falcot, razão pela qual os administradores executam o dpkg-reconfigure postfix, para personalizar mais parâmetros.
Uma das questões extras pede para todos os nomes de domínio relacionados com esta máquina. A lista padrão inclui o seu nome completo, bem como alguns sinônimos para localhost, mas o principal domínio falcot.com precisa ser adicionado manualmente. De modo geral, esta questão deve ser respondida normalmente com todos os nomes de domínio para que esta máquina deve servir como um servidor MX; em outras palavras, todos os nomes de domínio para o qual o DNS diz que esta máquina vai aceitar e-mail. Esta informação acaba na variável mydestination do principal arquivo de configuração do Postfix - /etc/postfix/main.cf.
Papel do registro MX no DNS ao enviar um e-mail

Figura 11.1. Papel do registro MX no DNS ao enviar um e-mail

Em alguns casos, a instalação pode perguntar quais redes devem ser permitidas a enviar e-mail usando a máquina. Em sua configuração padrão, o Postfix somente aceita e-mails vindo da máquina em si, a rede local normalmente será adicionada. Os administradores da Falcot Corp adicionaram 192.168.0.0/16 na pergunta padrão. Se a questão não é feita, a variável relevante no arquivo de configuração é mynetworks, como visto no exemplo abaixo.
E-mails locais podem ser enviados através do comando procmail. Esta ferramenta permite aos usuários organizarem seus e-mail de entrada de acordo com a regras armazenadas em seu arquivo ~/.procmailrc. Tanto o Postfix quanto o Exim4 sugerem procmail por padrão, mas existem alternativas, como o maildrop ou Sieve filters.
Após este primeiro passo, os administradores conseguiram o seguinte arquivo de configuração; ele será usado como ponto de partida para adicionarmos funcionalidades extras nas próximas seções.

Exemplo 11.1. Arquivo inicial /etc/postfix/main.cf

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2



# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_security_level=may

smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache


smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.falcot.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost
relayhost = 
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
default_transport = smtp
relay_transport = smtp
inet_protocols = all
myorigin = /etc/mailname

11.1.2. Configurando Domínios Virtuais

The mail server can receive mails addressed to other domains besides the main domain; these are then known as “virtual“ domains. In most cases where this happens, the emails are not ultimately destined to local users. Postfix provides two interesting features for handling virtual domains.

11.1.2.1. Alias de domínios virtuais

Um alias de domínio virtual contém somente aliases, isto é, endereços que encaminham unicamente os e-mails para outros endereços.
Tal domínio é ativado ao se adicionar seu nome a variável virtual_alias_domains, e referenciar um arquivo de mapa de endereços a variável virtual_alias_maps.
virtual_alias_domains = falcotsbrand.com
virtual_alias_maps = hash:/etc/postfix/virtual
O arquivo /etc/postfix/virtual descreve o mapeamento com uma sintaxe bastante simples: cada linha contém dois campos separados por espaços em branco; o primeiro campo é o nome do alias, o segundo campo é uma lista de endereços de e-mail onde ele redireciona. A sintaxe especial @domain.com abrange todos os aliases restantes em um domínio.
webmaster@falcotsbrand.com  jean@falcot.com
contact@falcotsbrand.com    laure@falcot.com, sophie@falcot.com
# The alias below is generic and covers all addresses within
# the falcotsbrand.com domain not otherwise covered by this file.
# These addresses forward email to the same user name in the
# falcot.com domain.
@falcotsbrand.com           @falcot.com
Depois de alterar o /etc/postfix/virtual, a tabela postfix /etc/postfix/virtual.db precisa ser atualizada usando o sudo postmap /etc/postfix/virtual.

11.1.2.2. Domínios Virtuais de Caixa de Correio

As mensagens endereçadas a um domínio de caixa de correio virtual são armazenadas em caixas de correio não atribuídos a um usuário do sistema local.
Ativando um domínio de caixa de correio virtual requer nomear este domínio na variável virtual_mailbox_domains, e referenciar um arquivo de mapeamento de caixa de correio no virtual_mailbox_maps. O parâmetro virtual_mailbox_base contém o diretório sob o qual as caixas de correio serão armazenadas.
virtual_mailbox_domains = falcot.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /var/mail/vhosts
O parâmetro virtual_uid_maps (virtual_gid_maps respectivamente) faz referência ao arquivo que contém o mapeamento entre o endereço de e-mail e o usuário do sistema (grupo respectivamente) que "possui" a caixa correspondente. Para obter todas as caixas de correio de propriedade do mesmo dono/grupo, a sintaxe static:5000 atribui um UID/GID fixo (de valor 5000 aqui).
Novamente, a sintaxe do arquivo /etc/postfix/vmailbox é bastante simples: dois campos separados por espaço em branco. O primeiro campo é um endereço de e-mail dentro de um dos domínios virtuais, e o segundo campo é a localização da caixa de correio associada (relativo ao diretório especificado no virtual_mailbox_base). Se o nome da caixa de correio termina com uma barra (/), os e-mails serão armazenados no formato maildir; caso contrário, o tradicional formato mbox será usado. O formato maildir usa um diretório inteiro para armazenar a caixa de correio, cada mensagem que está sendo armazenada em um arquivo separado. No formato mbox, por outro lado, toda a caixa de correio é armazenado em um arquivo, e cada linha começando com "De " (De seguido de um espaço) indica o início de uma nova mensagem.
# Os e-mails de Jean são armazenados como maildir, com
# um arquivo por e-mail em um diretório dedicado
jean@falcot.org falcot.org/jean/
# Os e-mails de Sophie são armazenados em um arquivo tradicional "mbox",
# com todos os e-mails concatenados em um arquivo único
sophie@falcot.org falcot.org/sophie

11.1.3. Restrições para Recebimento e Envio

O crescente número de e-mails em massa não solicitados (spams) requer cada vez ser mais rigoroso ao decidir quais e-mails um servidor deve aceitar. Esta seção apresenta algumas das estratégias incluídas no Postfix.
Se as reject-rules forem muito restritivas, pode acontecer que até mesmo emails válidos fiquem travados. Portanto, é um bom hábito testar restrições e prevenir a rejeição permanente de requisições durante este tempo usando a diretiva soft_bounce = yes. Adicionando uma diretiva reject-type com warn_if_reject faz com que apenas uma mensagem de log seja gravada ao invés de rejeitar a mensagem.

11.1.3.1. Restrições de Acesso Baseados no IP

A diretiva smtpd_client_restrictions controla quais máquinas tem permissão para se comunicar com o servidor de e-mail.
Quando uma variável contém uma lista de regras, como no exemplo abaixo, essas regras são avaliadas em ordem, desde a primeira até a última. Cada regra pode aceitar a mensagem, rejeitá-la, ou deixar a decisão para a seguinte regra. Como consequência, a ordem importa e simplesmente mudar duas regras pode levar a um comportamento completamente diferente.

Exemplo 11.2. Restrições Baseadas no Endereço do Cliente

smtpd_client_restrictions =
    permit_mynetworks,
    warn_if_reject reject_unknown_client_hostname,
    check_client_access hash:/etc/postfix/access_clientip,
    reject_rhsbl_reverse_client dbl.spamhaus.org,
    reject_rhsbl_reverse_client rhsbl.sorbs.net,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client dnsbl.sorbs.net
A diretiva permit_mynetworks, usada como primeira regra, aceita e-mails vindos de uma máquina na rede local (como definido na variável de configuração mynetworks).
A segunda diretiva normalmente rejeitaria e-mails provenientes de máquinas sem uma configuração de DNS completamente válido. Tal configuração válida significa que o endereço IP pode ser resolvida para um nome, e que esse nome, por sua vez, resolve o endereço IP. Essa restrição é muitas vezes demasiada rigorosa, uma vez que muitos servidores de e-mail não tem um DNS reverso para o seu endereço IP. Isso explica por que os administradores da Falcot prefixaram o modificador warn_if_reject para a diretiva reject_unknown_client: este modificador transforma a rejeição em uma simples advertência registrada nos logs. Os administradores podem, em seguida, manter um olho sobre o número de mensagens que seriam rejeitadas se a regra fosse realmente cumprida, e tomar uma decisão informada mais tarde, se quiser ativar essa aplicação.
The check_client_access directive allows the administrator to set up a blacklist and a whitelist of email servers, stored in the /etc/postfix/access_clientip file. Servers in the whitelist are considered as trusted, and the emails coming from there therefore do not go through the following filtering rules.
As últimas quatro regras rejeitam qualquer mensagem proveniente de um servidor relacionado em uma das listas bloqueadas indicadas. RBL é um acrônimo para Remote Block List (Lista Bloqueada Remota) e RHSBL significa Right-Hand Side Block List (Lista Bloqueada de Confiança). A diferença é que a primeira lista endereços IP e a última lista nomes de domínio. Existem diversos desses serviços. Eles listam domínios e endereços IP de baixa reputação, servidores mal configurados que spammers usam para transmitir seus e-mails, bem como relays de e-mails inesperados como máquinas infectadas com worms ou vírus.

11.1.3.2. Verificando a Validade dos Comandos EHLO ou HELO

Cada troca SMTP inicia com um comando HELO (ou EHLO), seguido do nome do servidor de email remetente. Checar a validade deste nome pode ser interessante. Para garantir completamente as restrições listadas em smtpd_helo_restrictions a opção smtpd_helo_required precisa estar habilitada. Caso contrário os clientes podem pular as restrições não enviando nenhum comando HELO/EHLO.

Exemplo 11.3. Restrições no nome anunciado com EHLO

smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    warn_if_reject reject_unknown_helo_hostname,
    check_helo_access hash:/etc/postfix/access_helo,
    reject_rhsbl_helo multi.surbl.org
A primeira diretiva permit_mynetworks permite que todas as máquinas da rede local se apresentem livremente. Isso é importante, porque alguns programas de e-mail não respeitam essa parte do protocolo SMTP de forma suficientemente correta e podem se apresentar com nomes sem sentido.
The reject_invalid_helo_hostname rule rejects emails when the EHLO announce lists a syntactically incorrect hostname. The reject_non_fqdn_helo_hostname rule rejects messages when the announced hostname is not a fully-qualified domain name (including a domain name as well as a host name). The reject_unknown_helo_hostname rule rejects messages if the announced name does not exist in the DNS. Since this last rule unfortunately leads to a lot of rejections, the administrators turned its effect to a simple warning with the warn_if_reject modifier as a first step; they may decide to remove this modifier at a later stage, after auditing the results of this rule.
O reject_rhsbl_helo permite especificar uma lista negra para verificar o nome da máquina num RHSBL.
Usando permit_mynetworks como a primeira regra tem um efeito colateral interessante: as regras seguintes aplicam-se apenas aos hosts fora da rede local. Isso permite bloquear todos os hosts que se anunciam como parte da rede falcot.com, por exemplo adicionando uma linha falcot.com REJECT Você não é da nossa rede! no arquivo /etc/postfix/access_helo.

11.1.3.3. Accepting or Refusing Mails Based on the Announced Sender

Toda mensagem tem um remetente, anunciado pelo comando MAIL FROM do protocolo SMTP; novamente esta informação pode ser validada de diversas maneiras.

Exemplo 11.4. Verificações do Remetente

smtpd_sender_restrictions =
    check_sender_access hash:/etc/postfix/access_sender,
    reject_unknown_sender_domain,
    reject_unlisted_sender,
    reject_non_fqdn_sender,
    reject_rhsbl_sender rhsbl.sorbs.net
A tabela /etc/postfix/access_sender mapeia algum tratamento especial a alguns remetentes. Isso geralmente significa listar alguns remetentes em uma lista branca ou uma lista negra.
The reject_unknown_sender_domain rule requires a valid sender domain, since it is needed for a valid address. The reject_unlisted_sender rule rejects local senders if the address does not exist; this prevents emails being sent from an invalid address in the falcot.com domain, and messages emanating from joe.bloggs@falcot.com are only accepted if such an address really exists.
Finalmente, a regra reject_non_fqdn_sender rejeita e-mails que pretendem vir de endereços sem um nome de domínio totalmente qualificado. Na prática, isso significa rejeitar e-mails vindos de um usuário @máquina: o endereço deve ser anunciado como user@machine.example.com ou user@example.com.
A regra reject_rhsbl_sender rejeita remetentes baseada num serviço RHSBL (baseado em domínio).

11.1.3.4. Accepting or Refusing Mails Based on the Recipient

Todo e-mail tem ao menos um destinatário, anunciado com o comando RCPT TO no protocolo SMTP. Estes endereços também são passíveis de validação, mesmo que sejam menos relevantes do que as verificações feitas no endereço do remetente.

Exemplo 11.5. Verificações pelo Destinatário

smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unauth_destination,
    reject_unlisted_recipient,
    reject_non_fqdn_recipient,
    permit
reject_unauth_destination é a regra básica que exige que mensagens externas sejam endereçadas para nós; mensagens enviadas para um endereço não servido por este servidor são rejeitadas. Sem esta regra, um servidor se torna um retransmissor ("relay") aberto que permite que spammers enviem e-mails não solicitados; esta regra é, portanto, obrigatória, e vai ser melhor incluí-la perto do início da lista, de forma que nenhuma outra regra possa autorizar a mensagem antes de seu destino ser verificado.
A regra reject_unlisted_recipient rejeita mensagens enviadas para usuários locais não-existentes, o que faz sentido. Finalmente, a regra reject_non_fqdn_recipient rejeita endereços não totalmente qualificados; isso faz com que seja impossível enviar um e-mail para jean ou jean@machine, e em vez disso requer o uso do endereço completo, como jean@machine.falcot.com ou jean@falcot.com.
A directiva permit no final não é necessária. Mas pode ser útil no final de uma lista de restrições para deixar explícita a política predeterminada.

11.1.3.5. Restrições Associadas ao Comando DATA

O comando DATA do SMTP é emitido antes do conteúdo da mensagem. Ele não fornece qualquer informação, por si só, além de anunciar o que vem a seguir. Pode ainda ser submetidos a verificações.

Exemplo 11.6. Verificações pelo DATA

smtpd_data_restrictions = reject_unauth_pipelining
A diretiva reject_unauth_pipelining faz com que a mensagem seja rejeitada se o remetente envia um comando antes da resposta ao comando anterior foi enviado. Isso evita uma otimização comum usada por robôs de spammers, uma vez que eles geralmente não se importam em nada pelas respostas e se concentram apenas no envio de tantos e-mails quanto possível em tão curto espaço de tempo possível.

11.1.3.6. Aplicando as Restrições

Embora os comandos acima validem as informações em vários estágios de troca SMTP, o Postfix envia por padrão a rejeição real como uma resposta ao comando RCPT TO.
Isto significa que mesmo se a mensagem for rejeitada devido a um comando EHLO inválido, o Postfix conhece o remetente e o destinatário ao anunciar a rejeição. Então ele pode registrar uma mensagem mais explícita do que ele poderia se a transação havia sido interrompida desde o início. Além disso, um número de clientes SMTP não esperam falhas nos comandos SMTP iniciais, e esses clientes serão menos perturbados por esta rejeição tardia.
A vantagem final para esta escolha é que as regras podem acumular informação durante as várias fases do intercâmbio SMTP; este permite definir permissões mais refinadas, como a rejeição de uma conexão não-local se ele se anuncia com um remetente local.
O comportamento padrão é controlado pela regra smtpd_delay_reject.

11.1.3.7. Filtrando Baseado no Conteúdo da Mensagem

O sistema de validação e restrição não seria completo sem uma maneira de aplicar verificações para o conteúdo da mensagem. O Postfix diferencia as verificações praticadas nos cabeçalhos de e-mail das que se aplicam ao corpo do e-mail.

Exemplo 11.7. Habilitação de filtros baseados em conteúdo

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks
Ambos os arquivos contêm uma lista de expressões regulares (comumente conhecido como regexps ou regexes) e ações associadas a serem acionadas quando os cabeçalhos de e-mail (ou corpo) coincidir com a expressão.

Exemplo 11.8. Exemplos do arquivo /etc/postfix/header_checks

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane)
/^Subject: *Your email contains VIRUSES/ DISCARD virus notification
O primeiro verifica o cabeçalho mencionando o software de e-mail; a mensagem será rejeitada se GOTO Sarbacane (um software de e-mail em massa) for encontrado. A segunda expressão controla o assunto da mensagem; se menciona uma notificação de vírus, podemos decidir não rejeitar a mensagem, mas descartá-lo imediatamente.
Usando esses filtros é uma espada de dois gumes, porque é fácil de fazer as regras demasiadamente genéricas e como consequência perder e-mails legítimos. Nestes casos, não apenas as mensagens serão perdidas, mas seus remetentes receberão mensagens de erro indesejadas (e chatas).

11.1.4. Configurando "listas cinzas" (greylisting)

“Greylisting” is a filtering technique according to which a message is initially rejected with a temporary error code, and only accepted after a further delivery attempt with some delay. This filtering is particularly efficient against spam sent by the many machines infected by worms and viruses, since this software rarely acts as a full SMTP agent (by checking the error code and retrying failed messages later), especially since many of the harvested addresses are really invalid and retrying would only mean losing time.
Postfix não fornece lista cinza nativamente, mas existe uma funcionalidade na qual a decisão de aceitar ou rejeitar uma dada mensagem pode ser delegada a um programa externo. O pacote postgrey contém tal programa, feito para ser uma interface com este serviço de delegação de políticas de acesso.
Uma vez o postgrey estando instalado, ele roda como um daemon e ouve na porta 10023. O Postfix pode então ser configurado para usá-lo. adicionando o parâmetro check_policy_service como uma restrição extra:
smtpd_recipient_restrictions =
    permit_mynetworks,
    [...]
    check_policy_service inet:127.0.0.1:10023
Each time Postfix reaches this rule in the rule set, it will connect to the postgrey daemon and send it information concerning the relevant message. On its side, Postgrey considers the IP address/sender/recipient triplet and checks in its database whether that same triplet has been seen recently. If so, Postgrey replies that the message should be accepted; if not, the reply indicates that the message should be temporarily rejected, and the triplet gets recorded in the database.
A principal desvantagem de listas cinza é que mensagens legítimas podem ser atrasadas, o que nem sempre é aceitável. também aumenta a carga em servidores que mandam muitos email legítimos.

11.1.5. Personalização de filtros baseados no destinatário

Seção 11.1.3, “Restrições para Recebimento e Envio” e Seção 11.1.4, “Configurando "listas cinzas" (greylisting)” revisaram muitas das restrições possíveis. Todas objetivam limitar a quantidade de spam recebido, mas todas têm suas desvantagens. É portanto, mais e mais comum personalizar o conjunto de filtros dependendo do destinatário. Na Falcot Corp, a lista cinza é interessante para a maioria dos usuários, mas isso dificulta o trabalho de alguns usuários que precisam de baixa latência em seus e-mails (como o serviço de suporte técnico). De maneira similar, o serviço comercial às vezes tem problemas para receber e-mails de alguns provedores asiáticos que podem constar em listas negras; este serviço pede um endereço não filtrado de modo a ser capaz de corresponder.
O Postfix fornece tal customização de filtros com o conceito de “classe de restrição”. As classes são declaradas no parâmetro smtpd_restriction_classes, e definidas da mesma maneira como smtpd_recipient_restrictions. A diretiva check_recipient_access então define uma tabela de mapeamento de um determinado destinatário para o conjunto apropriado de restrições.

Exemplo 11.9. Definição de classes de restrição em main.cf

smtpd_restriction_classes = greylisting, aggressive, permissive

greylisting = check_policy_service inet:127.0.0.1:10023
aggressive =
        reject_rbl_client sbl-xbl.spamhaus.org,
        check_policy_service inet:127.0.0.1:10023
permissive = permit

smtpd_recipient_restrictions =
        permit_mynetworks,
        reject_unauth_destination,
        check_recipient_access hash:/etc/postfix/recipient_access

Exemplo 11.10. O arquivo /etc/postfix/recipient_access

# Unfiltered addresses
postmaster@falcot.com  permissive
support@falcot.com     permissive
sales-asia@falcot.com  permissive

# Aggressive filtering for some privileged users
joe@falcot.com         aggressive

# Special rule for the mailing-list manager
sympa@falcot.com       reject_unverified_sender

# Greylisting by default
falcot.com             greylisting

11.1.6. Integrating an Antivirus Filter

The many viruses circulating as attachments to emails make it important to set up an antivirus solution at the entry point of the company network, since despite an awareness campaign, some users will still open attachments from obviously shady messages.
The Falcot administrators selected clamav from the homonymous package.
A tarefa de fazer a interface entre o antivírus e o servidor de email vai para o clamav-milter. Ummilter (abreviação de mail filter) é um programa de filtragem especialmente projetado para fazer a interface com os servidores de email. O milter usa uma interface de programação de aplicativo (API) padrão que fornece uma performace muito melhor que os filtros externos para servidores de email. Os milters foram inicialmente introduzidos pelo Sendmail, mas o Postfix o adotou em seguida.
Uma vez que o pacote clamav-milter esteja instalado, o milter deve ser reconfigurado para rodar em uma porta TCP ao invés do soquete nomeado padrão. Isso pode ser feito com dpkg-reconfigure clamav-milter. Quando questionado pela “Communication interface with Sendmail”, responda “inet:10002@127.0.0.1”.
A configuração padrão do ClamAV se encaixa na maioria das situações, mas alguns parâmetros importantes ainda podem ser customizados com dpkg-reconfigure clamav-base.
O último passo envolve informar ao Postfix para usar o filtro recém-configurado. Isso é uma simples questão de adicionar a seguinte diretiva ao /etc/postfix/main.cf:
# Virus check with clamav-milter
smtpd_milters = inet:[127.0.0.1]:10002
Se o antivírus causar problemas, essa linha pode ser retirada de comentário e systemctl reload postfix deve ser executado para que essa alteração seja levada em conta.
Todas as mensagens manipuladas pelo Postfix agora passam pelo filtro de antivírus.

11.1.7. Lutando contr o spam com SPF, DKIM y DMARC

O grande números de email não-solicitado enviado a cada dia levou à criação de vários padrões, que visam validar que a máquina que envou uma mensagem está autorizada e que o email não foi adulterado. Os seguintes sistemas estão baseados em DNS e precisam não apenas que os administradores tenham controle sobre o servidor de email, como também sobre o DNS para o domínio em questão.

11.1.7.1. Integrando a Sender Policy Framework (SPF)

A Sender Policy Framework (SPF) é utilizada para validar se um servidor de correio eletrônico tem permissão para enviar e-mails por um determinado domínio. É normalmente configurado através do DNS. A sintaxe para fazer uma entrada é explicada em detalhes em:
The following is a sample DNS entry which states that all the domain's Mail Exchange Resource Records (MX-RRs) are allowed to send email for the current domain, and all others are prohibited. The DNS entry does not need to be given a name. But to use the include directive it must have one.
Name: example.org
Type: TXT
TTL:  3600
Data: v=spf1 a mx -all
Vamos dar uma rápida olhada na entrada falcot.org.
# host -t TXT falcot.org
falcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"
Ele afirma que o IP do remetente deve corresponder ao registro A para o domínio de envio, ou deve ser listado com um dos registros de recursos de troca de mensagens para o domínio atual, ou deve ser um dos três endereços IPv4 mencionados. Todos os outros hosts devem ser marcados como não autorizados a enviar e-mail para o domínio remetente. Este último é chamado de "falha leve" e destina-se a marcar o e-mail de acordo, mas ainda assim aceitá-lo.
O servidor de email postfix pode checar o registro SPF dos emails de entrada usando o pacote postfix-policyd-spf-python, um agente de política escrito em Python. O arquivo /usr/share/doc/postfix-policyd-spf python/README.Debian descreve os passos necessários para integrar o agente ao postfix, então nós não iremos repetí-los aqui.
A configuração é feita no arquivo /etc/postfix-policyd-spf-python/policyd-spf.conf, que é documentado em policyd-spf.conf(5) e /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. Os principais parâmetro de configuração são HELO_reject e Mail_From_reject, que configuram se os e-mail devem ser rejeitados (Fail) ou aceitos com um cabeçalho anexado (False), se as verificações falharem. O último geralmente é útil, quando a mensagem é processada posteriormente por um filtro de spam.
Se o resultado se destina a ser usado por opendmarc (Seção 11.1.7.3, “Integrando Autenticação de Mensagens Basada em Domínios, relatórios e Conformidade (DMARC, en inglés)”), então Header_Type deve ser definido por AR.
Observe que o spamassassin contém uma extensão para verificar o registro SPF.

11.1.7.2. Assinando e verificando DKIM (Integrating DomainKeys -- chaves de domínio integradas)

O padrão DKIM (Domain Keys Identified Mail) é um sistema de autenticação de emissário. O agente de transporte de email, no caso, o postfix, adiciona uma assinatura digital associada com o nome de domínio ao cabeçalho do emails de saída. O receptor pode validar os campos do corpo e cabeçalho da mensagem comparando a assinatura com uma chave pública, que é recuperada de registros de DNS de emissários.
As ferramentas necessárias são enviadas com os pacotes opendkim e opendkim-tools.
Primeiro, a chave privada deve ser criada usando o comando opendkim-genkey -s SELECTOR -d DOMAIN. SELECTOR deve ser um nome exclusivo para a chave. Pode ser tão simples como um "e-mail" ou a data de criação, se você planeja alterar as chaves.

Exemplo 11.11. Crie uma chave privada para assinar e-mails de falcot.com

# opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys
# chown opendkim.opendkim /etc/dkimkeys/mail.*
Isto criará os arquivos /etc/dkimkeys/mail.private e /etc/dkimkeys/mail.txt e atribuirá a propriedade apropriada. O primeiro arquivo contém a chave privada, e o último a chave pública que precisa ser adicionada ao DNS:
Name: mail._domainkey
Type: TXT
TTL:  3600
Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"
O pacote opendkim no Debian tem um tamanho de chave predeterminado de 2048 bits. Infelizmente alguns servidores DNS só lidam com entradas de texto com tamanho máximo de 255 caracteres, que é ultrapassado pelo tamanho de chave predeterminado. Neste caso, use a opção -b 1024 para optar por um tamanho de chave menor. Se o opendkim-testkey tiver exito, a entrada se ajusta corretamente. Aqui se explica a sintaxe:
Para configurar o opendkim, devem ser escolhidos SOCKET e RUNDIR em /etc/default/opendkim. Observe que SOCKET deve ser acessível a partir do postfix em seu ambiente com chroot. Configurações adicionais são feitas em /etc/opendkim.conf. A seguir um extrato de configuração, que garante que Domain "falcot.com" todos os subdomínios (SubDomain) estão assinados pelo Selector "mail" a chave privada única (KeyFile) /etc/dkimkeys/mail.private. A Canonicalization "relaxada" tanto para o cabeçalho quanto para o corpo tolera uma modificação suave (por exemplo, por um software de uma lista de correio). O filtro é executado tanto no Modo de assinatura ("s" de signing) quanto no verificação ("v"). Caso uma assinatura falhe em validar (On-BadSignature), o correio deve ser posto em quarentena ("q").
[...]
Domain                  falcot.com
KeyFile                 /etc/dkimkeys/mail.private
Selector                mail

[...]
Canonicalization        relaxed/relaxed
Mode                    sv
On-BadSignature         q
SubDomains              yes

[...]
Socket                  inet:12345@localhost

[...]
UserID                  opendkim
Também é possível usar os seletores/chaves (KeyTable), domains (SigningTable) e para especificar hosts internos ou de confiança (InternalHosts, ExternalIgnoreList), que podem enviar e-mails através do servidor como um dos domínios de assinatura sem credenciais.
As seguintes diretivas em /etc/postfix/main.cf fazem o postfix usar o filtro:
milter_default_action = accept
non_smtpd_milters = inet:localhost:12345
smtpd_milters = inet:localhost:12345
Para diferenciar entre assinatura e a verificação, às vezes é mais útil adicionar diretivas aos serviços em /etc/postfix/master.cf em vez disso.
Há mais informações disponíveis no diretório /usr/share/doc/opendkim/ e nas páginas de manual opendkim(8) e opendkim.conf(5).
Tenha em conta que spamassassin contém um plugin para comprovar o registro DKIM.

11.1.7.3. Integrando Autenticação de Mensagens Basada em Domínios, relatórios e Conformidade (DMARC, en inglés)

O padrão de Autenticação de Mensagens Baseada em Domínios, Relatórios e Conformidade (DMARC, em inglês) é usado para definir uma entrada DNS TXT com o nome _dmarc e a ação que deve ser tomada quando os e-mails que contêm seu domínio como o host de envio não são validados usando DKIM e SPF.
Vamos dar uma olhada nas entradas de dois grandes provedores:
# host -t TXT _dmarc.gmail.com
_dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
# host -t TXT _dmarc.yahoo.com
_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"
Yahoo possui uma política rigorosa para rejeitar todos os e-mails que fingem ter sido enviados por uma conta Yahoo mas falham nas verificações DKIM e SPF. Google Mail (Gmail) propaga uma política muito relaxada, na qual tais mensagens do domínio principal ainda devem ser aceitas (p=none). Para subdomínios eles devem ser marcados como spam (sp=quarantine). Os endereços dados na chave rua podem ser utilizados para enviar relatórios agregados DMARC. A sintaxe completa é explicada aqui:
O servidor de email postfix pode usar também esta informação. O pacote opendmarc contém o filtro de email necessário. De forma similar a opendkim, SOCKET e RUNDIR devem ser escolhidos em /etc/default/opendmarc (para soquetes Unix você tem que garantir que eles estão dentro do chroot do postfix). O arquivo de configuração /etc/opendmarc.conf contém comentários detalhados, e também se explica em opendmarc.conf(5). Por padrão, os emails que falham na verificação DMARC não são rejeitados, mas etiquetados, adicionando um campo de cabeçalho apropriado. Para alterar isto, use RejectFailures true.
O filtro de correio se adiciona a smtpd_milters e non_smtpd_milters. Se cpnfiguramos os filtros de correio opendkim e opendmarc para funcionar nas portas 12345 y 54321, a entrada en /etc/postfix/main.cf tem este aspecto:
non_smtpd_milters = inet:localhost:12345,inet:localhost:54321
smtpd_milters = inet:localhost:12345,inet:localhost:54321
Diretivas para serem adicionadas no arquivo /etc/postfix/main.cf.

11.1.8. SMTP autenticado

Ser capaz de enviar emails requer um servidor SMTP ao alcance; e também requer que o referido servidor SMTP envie emails por ele. Para usuários móveis, pode ser preciso que eles alterem, regularmente, a configuração do cliente SMTP, já que o servidor SMTP da Falcot rejeita mensagens provenientes de endereços IP aparentemente não pertencentes à companhia. Existem duas soluções: ou o usuário instala um servidor SMTP em seu computador, ou ele usa o servidor da companhia com algum meio de autenticação como empregado. A primeira solução não é recomendada já que o computador não estará permanentemente conectado, e não será capaz de tentar enviar mensagens novamente em caso de problemas; nós iremos nos focar na última solução.
A autenticação SMTP no Postfix se apoia no SASL (Simple Authentication and Security Layer). Ela precisa dos pacotes libsasl2-modules e sasl2-bin instalados, e em seguida o registro de uma senha no banco de dados do SASL para cada usuário que precise autenticar no servidor SMTP. Isso é feito com o comando saslpasswd2, o qual recebe vários parâmetros. A opção -u define o domínio de autenticação, que deve corresponder com o parâmetro smtpd_sasl_local_domain na configuração do Postfix. A opção -c permite criar um usuário, e -f permite especificar o arquivo a ser usado se o banco de dados do SASL precisar ser armazenado em um local diferente do padrão (/etc/sasldb2).
# saslpasswd2 -u `postconf -h nomedomeuhost` -f /var/spool/postfix/etc/sasldb2 -c jean
[... digite a senha de jean duas vezes ...]
Note que o banco de dados do SASL foi criado no diretório do Postfix. Para garantir consistência, nós também transformamos o /etc/sasldb2 em uma ligação simbólica apontando para o banco de dados usado pelo Postfix, com o comando ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.
Agora nós precisamos configurar o Postfix para usar o SASL. Primeiro, o usuário postfix precisa ser adicionado ao grupo sasl, para que ele possa acessar a conta no banco de dados do SASL. Alguns novos parâmetros também são necessários para habilitar o SASL, e o parâmetro smtpd_recipient_restrictions precisa ser configurado para permitir que cliente autenticado pelo SASL possam enviar emails livremente.

Exemplo 11.12. Ativando o SASL no /etc/postfix/main.cf

# Enable SASL authentication
smtpd_sasl_auth_enable = yes
# Define the SASL authentication domain to use
smtpd_sasl_local_domain = $myhostname
[...]
# Adding permit_sasl_authenticated before reject_unauth_destination
# allows relaying mail sent by SASL-authenticated users
smtpd_recipient_restrictions =
    permit_sasl_authenticated,
    permit_mynetworks,
    reject_unauth_destination,
[...]
Normalmente, é uma boa ideia não enviar senhas em uma conexão sem criptografia. Postfix permite usar diferentes configurações para cada porta (serviço) onde executa. Todas elas podem se configurar com diferentes regras e diretivas no arquivo /etc/postfix/master.cf. Para desativar a autenticação por completo para a porta 25 (serviço smtpd) adicione a seguinte diretriz:
smtp      inet  n       -       y       -       -       smtpd
    [..]
    -o smtpd_sasl_auth_enable=no
    [..]
Se por alguma razão os clientes usam um comando AUTH desatualizado (alguns clientes de correio muito velhos o fazem), se pode habilitar la interoperabilidade com eles usando a diretiva broken_sasl_auth_clients.