Agora que sabemos como Postfix conversa com o Dovecot e com o ViMbAdmin, é hora de descobrir como o Dovecot conversa com o Postfix e com o ViMbAdmin. Também vamos explorar outras coisas relacionadas ao Dovecot que são só dele, como o IMAP, cotas e uma coisa maravilhosa chamada Sieve. Essa parte da série também não será das mais fáceis de ler.

O Dovecot atua como MDA em nosso servidor. É ele que faz o meio de campo entre os serviços fornecidos pelo Postfix e nossos clientes de correio. Exceto pelo submission do Postfix, todo o resto dos serviços que nossos clientes de email usam e algumas funções de backend das quais o próprio Postfix necessita são fornecidas pelo Dovecot. Ou seja, ele é essencial ao nosso setup.

A melhor forma de entender essa importância é repassar o arquivo de configuração.

Monolítico

Doze entre dez guias de instalação do Dovecot que você encontrar por aí, incluindo a própria documentação do Dovecot, vão dizer que seus arquivos de configuração tem como base o arquivo dovecot.conf e que o resto da configuração é carregada a partir dos arquivos conf.d/*.conf.

Pois eu faço outra coisa. Se você olhar para o que foi feito no artigo sobre configuração e inicialização, verá que a configuração que eu proponho é monolítica, com um arquivo de configuração apenas: /etc/dovecot/dovecot.conf. Há um outro que governa o acesso ao banco, /etc/dovecot/dovecot-sql.conf.ext, mas como sua finalidade e sintaxe são bem específicas, ele se mantém separado mesmo.

É questão de gosto. Eu prefiro abrir e trabalhar em apenas um arquivo de configuração bem documentado do que ficar indo e voltando em múltiplos arquivos com finalidades diferentes para o mesmo software. Sempre que posso, simplifico essas coisas e o Dovecot é o melhor caso disso.

Se você quiser seguir o modo convencional de configurar o Dovecot com os múltiplos arquivos, fique a vontade. Eu só não vou te ajudar a separar as coisas.

Configurações

Agora que estamos entendidos sobre a função do Dovecot e como eu o configuro, pode abrir o arquivo /etc/dovecot/dovecot.conf.

Geral na linha

A primeiro bloco que encontramos nele é:

## Main settings
shutdown_clients = yes
default_login_user = dovenull
protocols = lmtp imap sieve
mail_plugins = quota
mail_home = /var/mail/vmail/%d/%n
mail_location = maildir:/var/mail/vmail/%d/%n:LAYOUT=fs
auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@

São configurações do comportamento geral do Dovecot. Com shutdown_clients = yes dizemos ao Dovecot para derrubarmos os clientes conectados quando reiniciarmos o serviço mediante um /etc/rc.d/rc.dovecot restart. Isso é útil para não termos que ficar esperando o último cliente desconectar para que o Dovecot aplique as configurações. Se você quer ser gente boa com os usuários, pode deixar isso de fora.

Em seguida, informamos ao Dovecot qual é o usuário que ele utilizará para os processos de autenticação de usuários, default_login_user = dovenull. Esse usuário dovenull é aquele desprivilegiado que criamos anteriormente. Essa configuração é padrão no Dovecot e não precisaria aparecer aqui, mas sendo ela tão importante do ponto de vista de segurança, prefiro deixá-la a mostra.

Depois vem algo crítico: quais protocolos o Dovecot fala? O nosso vai falar LMTP, IMAP e Sieve. Isso é indicado por protocols = lmtp imap sieve. Notou que não tem POP3? Pois é, não tem POP3. Se você quiser ter, terá que se virar para adicionar.

Em seguida habilitamos de modo genérico no Dovecot os mail_plugins. Aqui vamos usar apenas um: o de cotas para as caixas de correio dos usuários. Lembra da configuração do ViMbAdmin? Lembra que ele faz coisas relacionadas às cotas? É aqui que aquelas coisas passam a funcionar.

Agora vem as duas configurações mais importantes do Dovecot enquanto backend do Postfix e servidor IMAP: como e onde as mensagens dos usuários virtuais são armazenadas.

A configuração mail_home define o local no filesystem para o diretório inicial de cada usuário virtual. As variáveis %d e %n são substituídas, respectivamente, pelo nome do domínio virtual configurado no ViMbAdmin e o nome sem domínio (a parte antes do @ no endereço de email) do usuário virtual do domínio.

mail_location define o local onde onde as mensagens de cada usuário virtual serão armazenadas. Ela também define o tipo desse armazenamento para maildir (lembra que já falamos sobre mailbox e maildir?) e que esse diretório terá um layout semelhante ao do filesystem com LAYOUT=fs, onde cada pasta de mensagens será um diretório contendo mensagens.

A configuração auth_username_chars só é importante se você pretende ter nomes de usuários com caracteres especiais (acentos, espaços e outros bichos), o que em hipótese alguma é algo esperto de se fazer.

SSL

Agora vem a parte do SSL (o equivalente ao TLS no Postfix). Como na explicação do Postfix já compreendemos bem a importância disso para a segurança geral do sistema, e como as coisas aqui são semelhantes, podemos ser menos detalhistas.

## SSL settings (match Postfix)
ssl = required
ssl_cert = </etc/ssl/private/certificate.crt
ssl_key = </etc/ssl/private/certificate.key
ssl_client_ca_dir = /etc/ssl/certs
ssl_cipher_list = ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
ssl_dh_parameters_length = 2048

Pra começar, o SSL é obrigatório. Depois, como temos feito desde o nginx, especificamos o mesmo certificado e chave privada. Lembre-se que isso facilita nossa vida para administrar os certificados. Também apontamos para o Dovecot onde estão os certificados raiz do nosso sistema.

Em seguida, também como fizemos no nginx e Postfix, informamos qual a lista de cifradores que permitimos o uso. Do mesmo modo como foi feito antes, desativamos as cifragens porcarias.

E por último informamos o comprimento das chaves para o recurso PFS. Essas chaves aqui funcionam de modo um pouco diferente do que no nginx e Postfix. Lembra que quando inciamos o Dovecot pela primeira vez ele disse pra gente que estava Generating SSL parameters? Quando ele diz isso é porque está gerando as chaves Diffie-Hellman para o PFS. O Dovecot não usa arquivos pré-moldados para isso e prefere gerá-los ele mesmo. Ele faz isso a cada semana para trocar as chaves. Se você quiser desabilitar isso, eu já disse como fazer lá atrás.

IMAP

Agora é a vez do IMAP, o protocolo que usamos para ler nossos preciosos emails.

## IMAP settings
service imap-login {
  # Disable insecure IMAP listener
  inet_listener imap {
    address = 127.0.0.1
    port = 0
  }
  # Enable secure IMAP listener over IPV4 only, default port (993)
  inet_listener imaps {
    address = *
  }
}

# IMAP restrictions
protocol imap {
  mail_max_userip_connections = 15
  mail_plugins = $mail_plugins quota imap_quota
  imap_client_workarounds = delay-newmail tb-extra-mailbox-sep
}

Cada protocolo que o Dovecot 'fala' necessita de um 'ouvinte' (listener). Ou seja, um porta na rede ou socket no filesystem onde o protocolo pode ser encontrado. Isso é a mesma coisa feita no Postfix, onde o SMTP e o submission são ouvintes para o smtpd.

O Dovecot possibilita que tenhamos o protocolo IMAP ouvindo em portas seguras e não seguras. Mas nós cagamos para o não seguro e simplesmente dissemos que ela ouve apenas no localhost e numa porta nula com inet_listener imap { ... port = 0 }.

Por outro lado, adoramos coisas seguras e habilitamos o listener IMAPS (inet_listener imaps) em sua porta padrão (993), mas somente para endereços IPv4 (address = *), uma vez que o AWS não suporta IPv6.

Daí estabelecemos algumas restrições ao protocolo IMAP em geral. Cada usuário pode ter no máximo 15 conexões simultâneas no servidor, completamos o suporte a cotas para o IMAP e por fim habilitamos algumas gambiarras necessárias a clientes de emails mal comportados, tipo o Mail do OS X e Outlook Express, essas porcarias proprietárias. Sácume, né?

Agora vem o POP3.

## POP3 settings
# There's no POP3 settings because it's disabled.

Opa! Não tem POP3! :P

LMTP

Então vamos ao LMTP, o nosso carteiro.

## LMTP settings
lmtp_save_to_detail_mailbox = yes
service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    user = postfix
    group = postfix
    mode = 0600
  }
}
protocol lmtp {
  postmaster_address = postmaster@exemplo.com
  mail_plugins = $mail_plugins quota sieve
  quota_full_tempfail = no
  deliver_log_format = msgid=%m: %$
  rejection_reason = Your message to <%t> was automatically rejected: %n%r
}

Como já sabemos, o LMTP é o sujeito que o Postfix usa para entregar as mensagens recebidas de fora aos nossos usuários virtuais. Como LMTP funciona é definido agora.

A configuração lmtp_save_to_detail_mailbox é um mimo. Se você enviar um email para eumesmo@exemplo.com, essa mensagem vai parar na sua caixa de entrada. Agora se você enviar uma mensagem para eumesmo+lembretes@exemplo.com, essa mensagem será entregue automaticamente na pasta lembretes. Legal, neam? Mas tem uns poréns:

  1. A pasta de destino deverá ser criada previamente ou você tem que inserir a configuração lda_mailbox_autocreate=yes no dovecot.conf. Eu recomendo o primeiro, porque se alguém descobre que você tem esse mimo habilitado, nêgo vai criar pastas a torto e a direito só pra te sacanear. Criar a pastinha antes não dói nada. Se a pastinha não existir, a mensagem será entregue normalmente no seu INBOX.
  2. Se você tem um alias do tipo 'catch all' configurado no ViMbAdmin para o seu endereço, o mimo também não funciona porque esse alias diz para o Dovecot que todos as contas que não existam devem ser encaminhados ao seu INBOX. No caso, eumesmo+lembretes@exemplo.com é uma conta que não existe em seu servidor.
  3. Para o mimo funcionar, você deve habilitar a configuração recipient_delimiter = + no plugin Sieve.

Depois do mimo, temos a coisa séria. Definimos o listener do LMTP. No caso ele é o socket /var/spool/postfix/private/dovecot-lmtp. Você deve se lembrar que no Postfix também configuramos esse mesmo lugar como virtual_transport. Como o postfix precisa usar esse carinha, o usuário e grupo do sistema que terá permissão para usá-lo serão o postfix. A permissão é bem restrita, por isso o mode = 0600 indica que somente o usuário definido antes poderá ler e escrever neste socket.

Agora que há um listener, definimos as propriedades do protocolo LMTP. Habilitamos para ele o endereço que será usado como 'de' para as mensagens que forem devolvidas. Em seguidas são habilitados os plugins adicionais aos da configuração geral ($mail_plugins quota sieve).

A configuração quota_full_tempfail = no diz que as mensagens que chegarem para um usuário que está com sua conta acima da cota serão retornadas com erros permanentes ao invés de temporários. Erros temporários fazem com que os servidores tentem enviar a mensagem novamente mais tarde. Não queremos isso. Os usuários devem ser responsáveis e atentos a suas cotas. A resposta da rejeição permanente é informada pela configuração rejection_reason.

Por fim, a configuração deliver_log_format define como o LMTP deve registrar a entrega de mensagens no /var/log/maillog. Escolhemos mostrar o ID da mensagem e qualquer saída que o LMTP tenha gerado durante o processo de entrega. Por exemplo, uma mensagem enviada para eumesmo+lembretes@exemplo.com sem que a pasta lembretes tenha sido criada seŕa mostrada assim no log:

May 23 16:36:31 mail dovecot: lmtp(4343, eumesmo@exemplo.com): ztlEK7/WYFX3EAAAZU03Dg: msgid=<4083982.ZfhFKIGC9D@cliente.local>: save failed to open mailbox lembretes: Mailbox doesn't exist: lembretes
May 23 16:36:31 mail dovecot: lmtp(4343, eumesmo@exemplo.com): ztlEK7/WYFX3EAAAZU03Dg: msgid=<4083982.ZfhFKIGC9D@cliente.local>: saved mail to INBOX

Autenticando

Agora vem o bloco que faz a coisa mais importante de todas para a segurança do nosso Dovecot: autentica usuários. Não só para o IMAP e o ManageSieve do Dovecot, mas também para o smtpd do Postfix via SASL. Ou seja, se foder aqui, você se fodeu inteiro.

Por isso, recomendo que você leia o documento que descreve os elementos da autenticação no Dovecot. Vou usar o idioma desse documento aqui.

## Authentication settings
auth_mechanisms = plain login

# Database backend for authentication for LMTP and Postfix
passdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
# Combine passdb and userdb backends for LMTP
userdb {
  driver = prefetch
}
# The userdb below is used only by LDA and quota
userdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}

# Mailboxes are virtual
userdb {
  driver = static
  args = uid=vmail gid=vmail home=/var/mail/vmail/%d/%n
}

# Log all failed authentication attempts
auth_verbose=yes

# Postfix smtp-auth
service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0600
    user = postfix
    group = postfix
  }
  unix_listener auth-userdb {
    mode = 0600
    user = vmail
  }
  user = dovecot
}

A primeira coisa a fazer é determinar os mecanismos de autenticação ativos com auth_mechanisms = plain login. Não precisamos inventar aqui porque já dissemos lá em cima que o SSL é obrigatório, logo os dados de login trafegam criptografados.

Depois definimos os backends de autenticação. Note que todos os nossos backends estão definidos para driver = sql? Por causa de quem? Quem? ViMbAdmin e MariaDB, óbvio!

Note também que os dois backends, passdb e userdb, falam com o MariaDB por meio do mesmo arquivo, /etc/dovecot/dovecot-sql.conf.ext. Foi lá que ensinamos o Dovecot a falar com o MariaDB através das declarações SQL definidas em password_query e user_query. É a partir delas que o Dovecot tem como saber quais usuários existem, quais são suas senhas, cotas e outras coisas.

Mas note uma coisa bem interessante: existe apenas um passdb, mas dois userdb. Porque diacho é assim? Explico.

O primeiro passdb serve ao LMTP e ao Postfix e já traz no resultado da query todas as informações do usuário, incluindo o nome. As duas coisas são unidas pelo primeiro userdb ajustado para driver = prefetch. Isso diz ao dovecot que a query password_query já contém o username e ele não precisa fazer mais nada.

O segundo userdb atende ao LDA (que não usamos) e ao plugin de cotas (que usamos). Como esses dois são mais burrinhos, eles precisam de uma query adicional (a user_query) pra funcionarem.

Ou seja, sem esse segundo userdb vai tudo funcionar muito bem. Mas você vai definir uma cota de 5GB para um usuário no ViMbAdmin e ele vai parar de receber emails quando conta atingir apenas 1GB de espaço em disco. Porque 1GB? Explico quando for falar de cotas, mais abaixo.

Agora que os usuários autenticam que é uma beleza, precisamos dizer ao Dovecot que os usuários são virtuais (não existem localmente, só no MariaDB), onde é o caminho no filesystem que guarda as mensagens e qual é o usuário do sistema com acesso a essa diretório. Tudo igual fizemos no Postfix.

Depois dizemos que as autenticações de usuário devem aparecer no log com auth_verbose=yes. Queremos saber quem está cometendo erros ou tentando ataques.

Agora configuramos o Dovecot para estabelecer um listener como um socket para o smtpd do Postifix autenticar quem pode enviar emails em nosso servidor. Assim como fizemos no main.cf do Postfix, definimos o socket onde essa conversa Postfix/Dovecot vai ocorrer (/var/spool/postfix/private/auth) e permitimos somente o usuário do Postifix usar esse canal de comunicação. Isso é efetivamente o socket do SASL.

Mas aí tem uma coisinha interessante. O Dovecot precisa falar com o backend de autenticação para atender aos pedidos de autenticação do Postfix. Como ele faz isso? Simples! Através do backend de usuários LMTP/Postfix que definimos um pouco mais acima. O listener para isso é criado também como um socket em /var/run/dovecot/, só que a permissão é agora é para o nosso outro usuário desprivilegiado vmail. Essa separação de usuários garante que um ataque bem sucedido no socket do Postfix não vai expor dados do nosso importante e seguro backend.

E como cereja do bolo da segurança do backend para o Postfix, tudo isso que foi feito acima ocorre com o usuário sem privilégios dovecot. Se alguém conseguir atacar todo o serviço de email, ele conseguirá no máximo se passar por um dos usuários não privilegiados e obter as mensagens e tals, mas nunca conseguirá ser root. Não nasce asa em porco.

Cotas

As cotas determinam a quantidade de negros, índios e portadores de necessidades especiais que podem enviar mensagens para o seu servidor. NÃO, ANIMAL! Felizmente a tecnologia em si não é tão babaca e estúpida quanto uma sociedade que encontra meios legais de miscigenar o seu povo, o mesmo povo, os mesmos humanos!

O plugin de cotas no Dovecot serve para limitar o espaço em disco utilizado por cada usuário. Em um ambiente onde armazenamento custa (e onde não custa?), isso pode ser bastante útil para evitar abusos.

É bom deixar claro que, especificamente no ambiente que estamos montando, a definição das cotas é papel do ViMbAdmin, restando ao Dovecot apenas habilitar esse suporte, o que já fizemos com as configurações mail_plugins que definimos anteriormente. Algumas definições que estamos para ver estão presentes apenas para impor certas limitações caso o backend do ViMbAdmin falhe em prover tais parâmetros, o que chamamos de 'fallback'.

As cotas são controladas pelo bloco abaixo.

## Quota settings
# Default quotas (ViMbAdmin takes care of this)
plugin {
  quota_rule = *:storage=1G
  quota_rule2 = Trash:storage=+100M
  quota_rule3 = Sent:storage=+100M
}
# Quota warnings
plugin {
  quota_warning = storage=95%% quota-warning 95 %u
  quota_warning2 = storage=80%% quota-warning 80 %u
}
service quota-warning {
  executable = script /usr/local/bin/quota-warning
  user = vmail
  unix_listener quota-warning {
    user = vmail
  }
}
# Enable per user quota
plugin {
  quota = maildir:User quota
}

Os parâmetros quota_rule* definem as regras de cotas. No contexto exclusivo do Dovecot, sem usar as definições do ViMbAdmin, estamos dizendo que cada usuário tem 1GB de espaço em disco para usar em suas mensagens. Além desse limite, cada usuário tem 100MB adicionais para o lixo e para as mensagens enviadas. Isso é importante caso o usuário exceda sua cota e precise de algum espaço para efetuar a limpeza e possa continuar enviando emails até um certo limite.

Se por uma razão qualquer o Dovecot não conseguir ler as cotas definidas pelo ViMbAdmin, os valores que valerão são esses definidos acima. Usuário sem cota só se for especificamente definido no ViMbAdmin.

Depois definimos os avisos com os parâmetros quota_warning*. Os usuários recebem dois avisos: o primeiro quando a utilizar 80% da sua cota, o segundo a 95% da cota. Uma outra configuração aponta o script que deve ser executado para avisar o usuário. Esse script foi definido lá atras na configuração. Toda vez que um usuário chegar em um dos níveis para o gatilho de notificação de uso de cota, o script será executado e o usuário será avisado por email.

Por fim é dito que as cotas configuradas são por usuário com quota = maildir:User quota. O espaço em disco necessário para o servidor atender a todos os usuários com suas devidas cotas deve ser obtido por meio do cálculo:

Armazenamento Total = Max Quota * Mailboxes

Onde Max Quota e Mailbox são obtidos na configuração do domínio virtual no ViMbAdmin. Essa fórmula de padeiro já foi mencionada antes lá na parte que tratou do ViMbAdmin, mas aqui ela tem um contexto mais apropriado.

No arquivo /etc/dovecot/dovecot-sql.conf.ext existe ainda uma query adicional, iterate_query, que é usada pelo comando doveadm. Esse comando é o utilitário CLI de administração do Dovecot. Dentre as muitas coisas que ele faz (man doveadm), uma delas é verificar a quantas andam as cotas de todos os usuários. Veja como é isso:

# doveadm quota get -A
Username             Quota name Type    Value   Limit                                                              %
admin@exemplo.com    User quota STORAGE     0  102400                                                              0
admin@exemplo.com    User quota MESSAGE     0       -                                                              0
eumesmo@exemplo.com  User quota STORAGE     1 2097152                                                              0
eumesmo@exemplo.com  User quota MESSAGE     1       -                                                              0

Bonitinho, né?

Sieve

Lindo mesmo é isso! O Sieve é a nossa peneira de emails. Ele é uma linguagem para criação de filtros de mensagens. Até aí nada demais, pois qualquer cliente de email bunda filtra emails.

A parte linda dele é que você pode escrever os seus filtros localmente e enviá-los para o servidor. A partir daí os seus filtros rodam direto no servidor e vão funcionar não só no cliente onde você escreveu o filtro, mas em todos os clientes de email que você conectar a sua conta, inclusive nos que não suportam Sieve. Você escreve o filtro uma vez e eles funcionam em todos os lugares!

Esse recurso é tão legal que, depois da questão da privacidade e segurança, ele foi o meu maior motivador para sair fora do Gmail. Esperei anos o Google fazer aqueles filtros de merda deles ao menos lembrarem o que é o Sieve. Cansei de esperar.

Bom, vamos ver como ele funciona. Assim como as cotas, o Sieve também já foi devidamente habilitado nos protocolos que o utilizam através das opções mail_plugins. O bloco a seguir configura o comportamento Pingeonhole, a implementação do Sieve que o Dovecot usa e que também provê o ManageSieve, que é o serviço para gerenciarmos nossos filtros remotamente.

## Sieve settings
plugin {
  sieve = ~/.dovecot.sieve
  sieve_dir = ~/sieve
  sieve_before = /var/mail/vmail/sieve-before
  sieve_after = /var/mail/vmail/sieve-after
  recipient_delimiter = +
}

# Enable ManageSieve listener to IPv4 only, default port (4190)
service managesieve-login {
  inet_listener sieve {
    address = *
  }
  service_count = 1
}
protocol sieve {
  managesieve_max_line_length = 65536
  managesieve_implementation_string = dovecot
}

Simples, simples. Primeiro dizemos onde o arquivo com os filtros dos usuários fica com a opção sieve = ~/.dovecot.sieve. Aqui é bom entender três coisas. A primeira é que esse home aí (~/) é do usuário virtual e relativo ao mail_home do Dovecot, logo o home de eumesmo@exemplo.com é /var/mail/vmail/exemplo.com/eumesmo.

A segunda coisa é que só pode haver um arquivo ~/.dovecot.sieve ativo por usuário. Dentro de cada arquivo desse poderá haver várias regras Sieve. É importante entender isso para que você não saia escrevendo um monte de regras, cada uma em um arquivo, achando que poderá ativar todas ao mesmo tempo. Não pode. Escreva suas regras em um só lugar.

A terceira coisa é que nenhum usuário vai precisar ter acesso ao SSH para editar o conteúdo de ~/.dovecot.sieve. Isso vai ser feito remotamente e o usuário não vai nem saber que esse arquivo existe.

A configuração sieve_dir = ~/sieve diz ao ManageSieve onde os filtros enviados pelos usuários devem ser guardados. Você pode enviar vários filtros em arquivos diferentes, que serão armazenados em sieve_dir. Mas só poderá haver um arquivo de filtros ativo em qualquer dado momento. Isso é útil porque você ter múltiplos filtros no servidor, por exemplo, um filtro para respostas automáticas de férias.

Já as configurações sieve_before e sieve_after apontam para diretórios que contém arquivos com filtros que rodam para todos os usuários do servidor e que não podem ser alterados por ninguém. Nesses lugares você pode ter mais de um arquivo de filtro e todos eles rodarão em sequência.

O sieve_before é o lugar ideal para colocar os filtros antispam. Na verdade até já temos um filtro desse pronto: /var/mail/vmail/sieve-before/globalspam.sieve. Toda vez que esses filtros globais forem alterados, você precisa compilá-los com os comandos abaixo. Os filtros do usuário são compilados automaticamente.

# sievec /var/mail/vmail/sieve-before/
# sievec /var/mail/vmail/sieve-after/

A configuração recipient_delimiter = + é a que faz com que o mimo do lmtp_save_to_detail_mailbox que vimos lá no bloco do LMTP funcione. Aqui é dito que o + separa o nome do usuário do resto que vem antes da arroba, sendo que esse resto corresponde a uma pasta da caixa de correio.

Depois dos parâmetros básicos do Sive, temos a configuração do ManageSieve. Mesma coisa de todo o resto no Dovecot: um listener e um protocolo. Habilitamos o listener para ouvir apenas nos endereços IPv4, na porta padrão (4190) e com apenas um processo.

E pra fechar, dizemos que o protocolo aceita scripts Sieve com linhas de um montão de bytes (managesieve_max_line_length = 65536) e como o ManageSieve vai se apresentar aos clientes de email (managesieve_implementation_string = dovecot).

Quando formos configurar os clientes eu vou dar uns exemplos de filtros Sieve pra você usar. Mais pra frente isso.

Caixas de Correio

Só ficaram faltando o lugar onde as mensagens serão armazenadas, né? Facil!

## Default mailboxes settings
namespace inbox {
  inbox = yes
  # These mailboxes are widely used and could perhaps be created automatically
  mailbox Enviadas {
    special_use = \Sent
    auto = subscribe
  }
  mailbox Lixo {
    special_use = \Trash
    auto = subscribe
  }
  mailbox Rascunhos {
    special_use = \Drafts
    auto = subscribe
  }
  mailbox Spam {
    special_use = \Junk
    auto = subscribe
  }
}

Primeiro definimos que todo o escopo de caixas de correio é chamado inbox. Depois definimos que dentro dele existe um INBOX com inbox = yes.

Em seguida criamos as pastinhas que geral usa: Enviadas, Lixo, Rascunhos e Spam. Se você quiser criar mais pastinhas padrão, esse é o lugar. Não precisa se preocupar em criar essas pastinhas no filesystem. O Dovecot fará isso para cada usuário novo que se conectar. Simples e fácil.

E pra fechar, dizemos que essas pastinhas são assinadas automaticamente pelos clientes de email (auto = subscribe). Isso faz com que elas já apareçam para os usuários automaticamente quando eles configurarem suas contas nos clientes. Viu como somos legais?

Você deve ter notado que tem um bloquinho de configurações comentadas no final que eu não disse nada a respeito. Vou deixar sua imaginação correr solta sobre como usá-lo.

E fim! O Dovecot está entendido.