/etc/postfix/main.cf.
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.
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.
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.
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.
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
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
/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
/etc/postfix/virtual, a tabela postfix /etc/postfix/virtual.db precisa ser atualizada usando o sudo postmap /etc/postfix/virtual.
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
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).
/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
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.
smtpd_client_restrictions controla quais máquinas tem permissão para se comunicar com o servidor de e-mail.
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.netpermit_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).
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.
check_client_access permite ao administrador criar uma lista negra e uma lista branca de servidores de e-mail, armazenados em /etc/postfix/access_clientip. Servidores na lista branca são considerados de confiança e os e-mails vindos de lá, portanto, não passam pelas regras seguintes de filtragem.
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.orgpermit_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.
reject_invalid_helo_hostname rejeita e-mails quando o anúncio EHLO lista um nome de host incorreto sintaticamente. A regra reject_non_fqdn_helo_hostname rejeita mensagens quando o nome do host anunciado não é um nome de domínio totalmente qualificado (incluindo nome de domínio e nome de host). A regra reject_unknown_helo_hostname rejeita mensagens se o nome anunciado não existe no DNS. Uma vez que esta última regra infelizmente leva a muitas rejeições, os(as) administradores(as) converteram seu efeito em uma simples advertência com o modificador warn_if_reject como um primeiro passo; eles(as) podem decidir remover este modificador em uma etapa posterior após a auditoria dos resultados desta regra.
reject_rhsbl_helo permite especificar uma lista negra para verificar o nome da máquina num RHSBL.
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.
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/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.
reject_unknown_sender_domain exige um domínio de remetente válido, já que tal domínio é necessário para um endereço válido. A regra reject_unlisted_sender rejeita remetentes locais se o endereço não existe; isso impede que emails sejam enviados de um endereço inválido no domínio falcot.com, e as mensagens que se originam de joe.bloggs@falcot.com são apenas aceitas se tal endereço realmente existe.
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.
reject_rhsbl_sender rejeita remetentes baseada num serviço RHSBL (baseado em domínio).
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,
permitreject_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.
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.
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.
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.
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.
RCPT TO.
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.
smtpd_delay_reject.
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
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
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.
check_policy_service como uma restrição extra:
smtpd_recipient_restrictions =
permit_mynetworks,
[...]
check_policy_service inet:127.0.0.1:10023postgrey e enviar a ele informações a respeito da mensagem relevante. Do seu lado, o Postgrey considera a tripla endereço IP/remetente/destinatário e verifica em seu banco de dados se a mesma tripla foi vista recentemente. Se sim, o Postgrey responde que a mensagem foi aceita; se não, a resposta indica que a mensagem deve ser rejeitada temporariamente, e a tripla é registrada no banco de dados.
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_accessExemplo 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
clamav a partir do pacote homônimo.
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.
dpkg-reconfigure clamav-milter. Quando questionado pela “Communication interface with Sendmail”, responda “inet:10002@127.0.0.1”.
dpkg-reconfigure clamav-base.
/etc/postfix/main.cf:
# Virus check with clamav-milter smtpd_milters = inet:[127.0.0.1]:10002
systemctl reload postfix deve ser executado para que essa alteração seja levada em conta.
include, ela deve ter um.
Name: example.org Type: TXT TTL: 3600 Data: v=spf1 a mx -all
falcot.org.
#host -t TXT falcot.orgfalcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"
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.
/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.
Header_Type deve ser definido por AR.
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.
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.*
/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=[...]"
-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:
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
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.
/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
/etc/postfix/master.cf em vez disso.
/usr/share/doc/opendkim/ e nas páginas de manual opendkim(8) e opendkim.conf(5).
_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.
#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;"
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:
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.
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
/etc/postfix/main.cf.
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 ...]
/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.
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,
[...]/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
[..]
AUTH desatualizado (alguns clientes de correio muito velhos o fazem), se pode habilitar la interoperabilidade com eles usando a diretiva broken_sasl_auth_clients.