Postfix Trafego Intenso 434 v12

Postfix

Para tráfego intenso de e-mails

www.4linux.com.br

- 2

Sumário

Capítulo 1

Introdução ao Correio Eletrônico...............................................................................................9

1.1. Histórico ....................................................................................................................... 10

1.2. Funcionamento básico do Correio Eletrônico...............................................................11

1.3. Os Protocolos SMTP, POP e IMAP.................................................................................13

1.3.1. SMTP................................................................................................................................... 13

1.3.2. POP...................................................................................................................................... 13

1.3.3. IMAP.................................................................................................................................... 13

1.4. Comandos do SMTP, POP e IMAP.................................................................................14

1.4.1. Comandos do SMTP.............................................................................................................14

1.4.2. Códigos do SMTP ................................................................................................................18

1.4.3. Comandos POP....................................................................................................................20

1.4.4. Comandos IMAP..................................................................................................................23

1.5. Exercícios...................................................................................................................... 25

Capítulo 2

Infraestrutura de Correio Eletrônico.......................................................................................27

2.1. Considerações...............................................................................................................28

2.2. Componentes da infraestrutura de correio eletrônico..................................................28

Capítulo 3

Instalando e Configurando o DNS............................................................................................31

3.1. Introdução..................................................................................................................... 32

3.2. Pratica Dirigida.............................................................................................................37

3.2.1. Procedimentos pós-instalação:............................................................................................37

3.2.2. Instalando e configurando o DNS........................................................................................37

3.3. Laboratório.................................................................................................................... 43

3.4. Exercícios...................................................................................................................... 44

Capítulo 4

Instalando e Configurando o Postfix........................................................................................45

4.1. Introdução..................................................................................................................... 46

4.1.1. Histórico..............................................................................................................................46

4.1.2. Funcionamento do Postfix...................................................................................................48

4.1.3. Daemons do Postfix.............................................................................................................51

4.1.4. Filas de mensagens do Postfix.............................................................................................56

4.1.5. Status da entrega................................................................................................................57

4.1.6. Arquivos de configuração do Postfix....................................................................................57

- 3

4.1.7. Tabelas de Pesquisa ............................................................................................................59

4.1.8. Comandos de Administração do Postfix...............................................................................60

4.2. Pratica Dirigida.............................................................................................................61

4.2.1. Instalando e Configurando o Postfix....................................................................................61

4.2.2. Enviando o primeiro e-mail .................................................................................................62

4.2.3. Outros parâmetros do main.cf.............................................................................................63

4.2.4. Utilizando a ferramenta Postal para envio de e-mails ........................................................64

4.2.5. Criando alias para usuários locais ......................................................................................64

4.2.6. Criando mapas de acessos com o postmap .........................................................................64

4.2.7. Utilizando os comandos postcat, postqueue e postsuper ...................................................65

4.3. Exercícios ..................................................................................................................... 66

Capítulo 5

Gerenciamento de Filas no Postfix...........................................................................................69

5.1. Introdução..................................................................................................................... 70

5.2. Pratica dirigida.............................................................................................................72

5.3. Exercícios ..................................................................................................................... 73

Capítulo 6

Entendendo Restrições SMTP no Postfix.................................................................................75

6.1. Introdução..................................................................................................................... 76

6.1.1. Filtragem de conteúdo depois do enfileiramento ...............................................................76

6.1.2. Filtragem de conteúdo antes do enfileiramento .................................................................76

6.1.3. Delegação de filtragem para programas externos...............................................................76

6.1.4. Restrições com Mapas de Acesso .......................................................................................79

6.1.5. Restrições de cabeçalho e corpo da mensagem .................................................................80

6.1.6. Restrições com RBLs ..........................................................................................................81

6.2. Prática Dirigida.............................................................................................................82

6.2.1. Restrições por IP e IP Reverso ...........................................................................................82

6.2.2. Restrições HELO/EHLO ......................................................................................................83

6.2.3. Restrições Remetente (MAIL FROM) .................................................................................84

6.2.4. Restrições Destinatário (RCPT TO).....................................................................................85

6.2.5. Restrições após o comando DATA .......................................................................................85

6.2.6. Restrições Cabeçalhos da Mensagem..................................................................................86

6.2.7. Restrições do Corpo da Mensagem.....................................................................................87

6.2.8. Desabilitando comando VRFY .............................................................................................87

6.2.9. Restrições condicionais ......................................................................................................87

6.2.10. Restrições por tamanho da mensagem .............................................................................89

6.2.11. Restrições – Conformidade com RFC ................................................................................89

6.3. Exercícios ..................................................................................................................... 90

6.4. Laboratório ................................................................................................................... 92

- 4

Capítulo 7

Troubleshoot

Identificando e Resolvendo Problemas no Postfix....................................................................93

7.1. Introdução .................................................................................................................... 94

7.2. Prática Dirigida.............................................................................................................97

7.2.1. Aumentando o nível de log e debugando o Postfix .............................................................97

7.2.2. Debugando o Postfix com a ferramenta sendmail ...............................................................98

7.3. Exercícios...................................................................................................................... 99

Capítulo 8

Instalando e Configurando o OpenLDAP...............................................................................101

8.1. Introdução .................................................................................................................. 102

8.2. Comandos de Administração do OpenLDAP...............................................................103

8.2.1. Comandos do Servidor.......................................................................................................104

8.2.2. Comandos do Cliente.........................................................................................................104

8.2.3. O formato LDIF..................................................................................................................104

8.3. Prática Dirigida...........................................................................................................106

8.3.1. Editando o arquivo /etc/ldap/slapd.conf............................................................................107

8.3.2. Iniciando o slapd................................................................................................................108

8.3.3. Inserindo o domínio e os usuários através do LDIF..........................................................108

8.3.4. Modificando usuários no OpenLDAP.................................................................................111

8.3.5. Realizando troca de senhas dos usuários..........................................................................111

8.3.6. Consultando registros no OpenLDAP ...............................................................................111

8.3.7. Removendo um usuário do OpenLDAP..............................................................................112

8.4. Laboratório .................................................................................................................113

8.5. Exercícios.................................................................................................................... 114

Capítulo 9

Servidor POP/IMAP com Dovecot e Integração com o OpenLDAP e SSL..............................116

9.1. Introdução................................................................................................................... 117

9.1.1. Interface de Autenticação SASL do Dovecot.....................................................................117

9.2. Prática Dirigida...........................................................................................................117

9.2.1. Preparando o ambiente para armazenamento das caixas postais.....................................117

9.2.2. Instalando o Dovecot.........................................................................................................118

9.2.3. Integrando e Configurando o Dovecot com OpenLDAP.....................................................118

9.2.4. Configurando o Dovecot....................................................................................................118

9.2.5. Configurado o script de aviso de quota.............................................................................121

9.3. Exercícios ................................................................................................................... 124

Capítulo 10

Postfix – Integração com OpenLDAP, Dovecot e Autenticação SMTP....................................125

- 5

10.1. Introdução................................................................................................................126

10.2. Pratica Dirigida ........................................................................................................126

10.2.1. Testando os métodos de autenticação ............................................................................127

10.3. Identificando problemas de autenticação.................................................................129

10.4. Criando certificados digitais para o Postfix com OpenSSL ......................................130

10.4.1. Criptografia Assimétrica .................................................................................................130

10.4.2. Padrão X.509 ..................................................................................................................130

10.4.3. Instalando o OpenSSL: ...................................................................................................131

10.4.4. Gerando a requisição do certificado: ..............................................................................131

10.4.5. Descriptografando a chave privada: ...............................................................................131

10.4.6. Gerando um certificado auto-assinado: ..........................................................................131

10.4.7. Verificando o conteúdo do certificado: ...........................................................................131

10.4.8. Configurando o Postfix com SSL/TLS - Suporte a Certificados Digitais..........................133

10.5. Integrando e Configurando o Postfix com OpenLDAP e Dovecot ...........................133

10.5.1. Editando o arquivo /etc/postfix/master.cf no Postfix: ......................................................135

10.5.2. Editando o arquivo /etc/postfix/main.cf no Postfix: .........................................................135

10.5.3. Criando os arquivos vmd.cf e vms.cf...............................................................................135

10.5.4. Testando as consultas virtuais LDAP com o postmap: ...................................................136

10.6. Exercícios ................................................................................................................. 137

Capítulo 11

Instalando e Configurando o Cliente Thunderbird POP/IMAP............................................138

11.1. Introdução ................................................................................................................139

11.1.1. Baixando a versão ESR do Thunderbird..........................................................................139

Capítulo 12

Instalando e Configurando o Cliente Webmail RoundCube POP/IMAP...............................143

12.1. Introdução ................................................................................................................144

12.2. Instalando e Configurado o Webmail RoundCube ....................................................144

12.2.1. Finalizando a instalação do Webmail ..............................................................................150

12.2.2. Estendendo o RounCube – Plugins .................................................................................151

Capítulo 13

Antivírus e AntiSpam.............................................................................................................153

13.1. ClamAV...................................................................................................................... 154

13.1.1. Introdução.......................................................................................................................154

13.1.2. Instalando o ClamAV........................................................................................................154

13.1.3. Entendendo o Clamd.conf ...............................................................................................155

13.1.4. Testando o ClamAV..........................................................................................................156

13.2. SpamAssasin.............................................................................................................157

13.2.1. Introdução.......................................................................................................................157

13.2.2. Instalando o SpamAssassin..............................................................................................158

- 6

13.2.3. Arquivos User_prefs.cf e local.cf ....................................................................................158

13.2.4. Treinando o SpamAssassin .............................................................................................160

13.2.5. Testando o SpamAssassin................................................................................................161

Capítulo 14

Integrando AntiSpam e Antivírus com o Postfix.....................................................................162

14.1. Amavis....................................................................................................................... 163

14.1.1. Introdução.......................................................................................................................163

14.1.2. Instalando Amavis-New...................................................................................................165

14.1.3. Configurando Amavis-New..............................................................................................165

14.1.4. Configurações específicas do SpamAssassim .................................................................166

14.1.5. Outras configurações do Amavis-New.............................................................................167

14.1.6. Integrando Amavis com o Postfix.....................................................................................169

14.1.7. Testando o Amavis-New...................................................................................................170

14.2. Exercícios.................................................................................................................. 171

Capítulo 15

SPF e Greylist......................................................................................................................... 173

15.1. Introdução ................................................................................................................174

15.1.1. SPF..................................................................................................................................174

15.1.2. Greylist ...........................................................................................................................174

15.2. Prática Dirigida.........................................................................................................176

15.2.1. Configurando o seu DNS com registros TXT para SPF:...................................................176

15.2.2. Ativando o Plugin SPF do SpamAssassim........................................................................176

15.2.3. Realizando teste de SPF com a ferramenta spftool.........................................................177

15.2.4. Instalando e Configurando o Postgrey – Greylist............................................................178

15.2.5. Testando o Postgrey.........................................................................................................180

15.3. Exercícios ................................................................................................................. 181

Capítulo 16

Aumentando a Performance da infraestrutura de Correio.....................................................183

16.1. Introdução ................................................................................................................184

16.1.1. Performance no Recebimento de Mensagens..................................................................184

16.1.2. Performance na Entrega de Mensagens..........................................................................185

16.1.3. número de Processos do Postfix .....................................................................................187

16.1.4. Número de Processos do Sistema Operacional ..............................................................188

16.1.5. Número de File Descriptors por Processo ......................................................................188

16.1.6. Considerações sobre Hardware - Disco Rígido................................................................188

16.1.7. Considerações sobre Hardware – Memória.....................................................................189

16.1.8. Considerações sobre Hardware – Rede...........................................................................190


16.2.1. Melhorando a Recepção de Mensagens ..........................................................................191

- 7

16.2.2. Melhorando as Filas de Mensagens ................................................................................192

16.2.3. Melhorando a Entrega de Mensagens ............................................................................192

16.2.4. Melhorando a performance Sistema Operacional ..........................................................194

16.3. Exercícios.................................................................................................................. 195

Capítulo 17

Teste de Stress na Infraestrutura de Correio........................................................................196

17.1. Introdução................................................................................................................. 197

17.1.1. smtp-source e smtp-sink .................................................................................................197

17.1.2. qmqp-source e qmqp-sink ..............................................................................................197

17.1.3. Postal ..............................................................................................................................197


17.2.1. Entendendo do e usando o smtp-source .........................................................................198

17.2.2. Entendendo e usando o smtp-sink ..................................................................................198

17.2.3. Usando o smtp-sink em conjuto com smtp-source ..........................................................199

17.2.4. Usando o Postal ..............................................................................................................200

17.2.5. Ferramentas de monitoramento .....................................................................................200

17.2.6. Realizando os testes .......................................................................................................201

17.3. Laboratório ...............................................................................................................205

Apêndice A - CyrusIMAP.......................................................................................................207

Introdução.......................................................................................................................... 208

Prática Dirigida.................................................................................................................. 209

Instalando o SASL.......................................................................................................................209

Habilitando a autenticação SASL................................................................................................209

Integrando e Configurando o SASL com OpenLDAP...................................................................209

Testando a Autenticação SASL ...................................................................................................210

Instalando o CyrusIMAP..............................................................................................................210

CryAdm – Administração do CyrusIMAP.....................................................................................214

Domínios Virtuais no CyrusIMAP.......................................................................................218

Conceitos..................................................................................................................................... 218

Configurando o domínio virtual...................................................................................................219

Criando usuário com domínio virtual..........................................................................................219

Listando usuários do domínio......................................................................................................219

Configurando o Postfix para entrega de mensagens no Cyrus....................................................220

Criando os arquivos vmd.cf, vms.cf e vma.cf : ............................................................................220

Escalabilidade do Cyrus IMAP: Cyrus Aggregator.............................................................222

Apêndice B - Entregando mensagens com o Maildrop..........................................................224

Introdução.......................................................................................................................... 225

Configurando Maildrop para entrega de mensagens..................................................................228

Criando os arquivos vmd.cf, vms.cf e vma.cf : ............................................................................232

- 8

Testando o Maildrop....................................................................................................................233

Exercícios........................................................................................................................... 234

Apêndice C - CourierIMAP POP3/IMAP................................................................................235

Introdução ......................................................................................................................... 236

Servidor Courier ........................................................................................................................236

Instalando Courier-Imap .............................................................................................................236

Configurando Courier - Autenticação com OpenLDAP................................................................236

Reiniciando o Serviço Courier-IMAP ..........................................................................................238

Criando a caixa postal do usuário................................................................................................238

Capítulo 1 Introdução ao Correio Eletrônico - 9

Capítulo 1

Introdução ao Correio Eletrônico


1.1. Histórico

Foi em 1971 que tudo começou (na realidade começou antes, com pesquisas),

com um engenheiro de computação da BBN (Bolt Beranek e Newman), chamado Ray

Tomlinson. Utilizando um programa chamado SNDMSG, abreviação do inglês para

“Send Message”, e o ReadMail, Ray conseguiu enviar mensagens de um computador

para outro. Depois de alguns testes mandando mensagens para ele mesmo, Ray tinha

criado o maior e mais utilizado meio de comunicação através da Internet: o correio

eletrônico (do inglês, “eletronic mail”) ou, simplesmente, como todos conhecem, e-

mail.

Como não poderia deixar de ser, o primeiro endereço de e-mail foi criado por

Tomlinson, tomlinson@bbn-tenexa. Convenção utilizada até hoje, o símbolo “@” foi

utilizado para separar o nome do computador do nome do usuário e é lido no inglês

com “at”, que significa “em”. Por exemplo, o endereço tomlinson está “em” bbn-

tenexa, onde “bbn-tenexa é o nome do computador que contém a conta de e-mail do

usuário em questão.

Durante um bom tempo, o e-mail foi usado, quase que exclusivamente, por

pesquisadores da área de computação e militares. Foi com o desenvolvimento e o

aumento de usuários da Internet, que o e-mail se popularizou e passou a ser a

aplicação mais utilizada. Hoje, até mesmo os iniciantes, têm, pelo menos, um

endereço de e-mail.

O correio eletrônico se parece muito com o correio tradicional. Todo usuário

tem um endereço próprio e uma caixa postal, os carteiros são os servidores de

mensagens que comunicam-se uns com os outros através da Internet.

Mas por que o e-mail se popularizou tão depressa? Primeiro, pelo custo. Você

não paga nada por uma comunicação via e-mail, a não ser os custos de conexão à

Internet. Outro fator é a rapidez. Enquanto o correio tradicional levaria dias,

semanas e até meses para entregar uma mensagem, o seu correspondente eletrônico

faz isso quase que instantaneamente, sem utilizar papel. Por último, após a

mensagem ser processada por diferentes servidores, sistemas e protocolos e ser

depositada na caixa postal do destinatário, o usuário pode acessá-la a partir de

qualquer computador conectado à Internet.


Bem, o e-mail mesclou a facilidade de uso do correio convencional com a

velocidade do telefone, se tornando um dos melhores e mais utilizado meio de

comunicação.

1.2. Funcionamento básico do Correio Eletrônico

É importante entender como os componentes apresentados na seção anterior

se relacionam para compor um sistema de e-mails. A figura abaixo apresenta um

esquema que ilustra esse processo.

Inicialmente, um usuário utilizando o seu programa de e-mails (Thunderbird,

MS Outlook), também chamando de MUA - Mail User Agent que encaminha a

mensagem por meio do protocolo SMTP ao seu servidor de e-mails (Postfix, Qmail,

Sendmail ou MS Exchange), também chamando de MTA - Mail Tranfer Agent. Com

base no domínio do endereço de destino da mensagem, o MTA solicita ao seu

servidor de DNS que encontre o nome dos servidores de e-mail responsáveis pelo

recebimento de mensagens para esse domínio. Em outras palavras, o servidor DNS

procura pelos registros MX - Mail Exchange associados ao domínio de destino.


Uma vez de posse da relação dos nomes e dos respectivos endereços IP dos

MTAs do destinatário da mensagem, o MTA do remetente repassa a mensagem

àquele MTA indicado como sendo de maior prioridade utilizando, novamente, o

protocolo SMTP. Ao receber a mensagem após o encerramento da sessão SMTP com

o MTA do remetente, o MTA do destinatário repassa a mensagem ao seu MDA -

Mail Delivery Agent, componente responsável pela entrega da mensagem na

mailbox do destinatário(Exemplo: procmail, maildrop,courier-maildrop,CyrusIMAP e

Dovecot).

A mensagem ficará depositada na mailbox do destinatário até que ele utilize

seu MUA para, por meio dos protocolos POP3 ou IMAP, receber, finalmente, a

mensagem em seu computador.

1.3. Os Protocolos SMTP, POP e IMAP

1.3.1. SMTP

O protocolo SMTP - Simple Mail Transfer Protocol, que se pode traduzir

por Protocolo Simples de Transferência de Correio, é o protocolo padrão que

permite transferir o correio de um servidor a outro em conexão ponto a ponto, onde

as máquinas envolvidas, emissor e receptor, devem estar ligadas permanentemente.

O SMTP é um protocolo apenas para envio de mensagens, ou seja, ele não

permite que um usuário extraia as mensagens do servidor, para isso exitem os

protocolos IMAP e POP.

1.3.2. POP

O POP - Post Office Protocol é um protocolo utilizado para acesso a uma

caixa de correio eletrônico. O POP3 permite que as mensagens no servidor sejam

transferidas sequencialmente para um computador pessoal. A partir daí, o usuário

pode ler, apagar, responder e armazenar as mensagens recebidas. Outra

característica do protocolo POP é que as mensagens são por padrão removidas do

servidor e transferida para o cliente.


1.3.3. IMAP

IMAP - Internet Message Access Protocol é um protocolo de gerenciamento

de correio eletrônico similar ao POP3 porém superior em recursos e segurança. O

mais interessante, é que as mensagens ficam armazenadas no servidor. O protocolo

IMAP só apresenta os cabeçalhos da mensagem. O usuário pode ter acesso a suas

pastas e mensagens em qualquer computador, tanto por um WEBMAIL como por

cliente de correio eletrônico como o Outlook Express ou Thunderbird.

1.4. Comandos do SMTP, POP e IMAP

Os protocolos SMTP, POP e IMAP utilizam o TCP para transportar suas

informações. Uma vez estabelecida a sessão TCP através do processo conhecido

como Three-Way-Handshake, o cliente “conversa” com o servidor por meio do envio

de comandos pré-estabelecidos e devidamente documentados nas RFCs

correspondentes. Para cada comando, o servidor encaminha uma resposta que

orienta o cliente quanto as próximas ações que devem ser executadas. A seguir são

apresentados os principais comandos encaminhados pelo cliente ao servidor e seus

respectivos significados:

1.4.1. Comandos do SMTP

• HELO (Obrigatório)

Primeira mensagem encaminhada por um cliente ao servidor para iniciar uma

transação SMTP. Como parâmetro, o cliente deve submeter o seu FQDN -

Fully Qualified Domain Name ou o seu endereço IP. Em outras palavras, o

comando HELO consiste na identificação do emissor da mensagem para o

receptor.

• MAIL FROM (Obrigatório)

A mensagem MAIL FROM identifica o endereço de e-mail do emissor da

mensagem ao servidor SMTP. Esse endereço deve ser colocado como

parâmetro desse comando, entre os sinais de “<” e “>”. Por exemplo: “MAIL

FROM: <[email protected]>”.

mailto:[email protected]


• RCPT TO(Obrigatório)

Este comando identifica o endereço de e-mail do destinatário da mensagem ao

servidor SMTP. A exemplo do comando MAIL FROM, o endereço é repassado

como argumento entre os sinais de “<” e “>”. Exemplo: RCPT TO:

“[email protected]”. Esse comando pode ser utilizado mais de uma vez

em uma transação SMTP quando a mensagem possui mais de um destinatário.

• DATA (Obrigatório)

Inicializa a transmissão do conteúdo da mensagem que pode conter qualquer

um dos 128 caracteres ASCII. Após a submissão desse comando, o servidor

SMTP deve responder com o código 354. Uma vez encaminhado todo o

conteúdo da mensagem, o cliente deve especificar a finalização do conteúdo

repassado ao servidor SMTP por meio da submissão da sequência

"<CRLF>.<CRLF>", que significa uma linha que contém apenas um caracter

“.” seguido de um <ENTER>. Após esse “sinal”, se o servidor SMTP aceitar a

transmissão da mensagem, ele retornará o código 250.

• RSET

Este comando determina que a operação atual de mail deverá ser abortada.

Todos os dados trocados entre cliente e servidor serão, portanto, descartados.

• SEND

Este comando é usado para inicializar uma transação de mail na qual uma

mensagem é enviada para um ou mais terminais onde estejam os destinatários

e não para as suas mailboxes. É um comando alternativo ao comando MAIL.

• SOML


mensagem é enviada para um ou mais terminais onde estejam os destinatários

ou às suas mailboxes. A mensagem é direcionada aos terminais dos

destinatários ativos no momento (e aceitando mensagens) caso contrário é

direcionada às suas mailboxes. É alternativo ao comando MAIL.



• SAML


mensagem é enviada para um ou mais terminais dos destinatários e aos seus

mailboxes. A mensagem é direcionada aos terminais dos destinatários ativos

no momento (e aceitando mensagens) e a todas as mailboxes.

• VRFY

Este comando solicita ao servidor SMTP a confirmação de que o argumento

corresponde a um usuário ou a uma mailbox conhecidos. Caso afirmativo, é

retornado o nome completo do usuário (se este possuir) e seu mailbox

completo. Para evitar a exposição desnecessária de usuários, por questões de

segurança, muitos servidores SMTP desabilitam a resposta à mensagem VRFY

enviando uma mensagem de retorno qualquer.

• EXPN

Este comando solicita ao servidor a confirmação de que o argumento identifica

uma lista de usuários de mail (mailing list). Se for identificada corretamente, o

servidor deve retornar os membros desta lista no mesmo formato utilizado

pelo comando VRFY. Entretanto, pelo fato dessas informações poderem expor o

servidor, esse comando, a exemplo do VRFY, é desabilitado por muitos

servidores SMTP.

• HELP

Uma vez emitido pelo cliente, esse comando faz com que o servidor SMTP

encaminhe informações de ajuda. O comando pode receber como parâmetro o

nome de algum comando sobre o qual o cliente deseja obter mais informações.

• NOOP

Esse comando apenas exige que o servidor SMTP retorne o código “250 OK” ao

cliente. Nenhum comando anterior é afetado pelo envio do NOOP. Qualquer

parâmetro que seja encaminhado pelo cliente junto com o NOOP será

completamente ignorado pelo servidor.

• QUIT

Este comando determina que o servidor SMTP envie um código de retorno de

“250 OK” e, então, feche o canal de comunicação com o cliente.


• TURN

Este comando faz com que o receptor e o emissor troquem de papéis. Em

outras palavras, o receptor fica como emissor e vice-versa.

• EHLO (Opcional com relação ao HELO)

Funciona tal qual o HELO mas, nesse caso, a resposta do servidor contém uma

lista de “habilidades” que incluem os recursos suportados pelo servidor em

questão tais como suporte para mecanismos de autenticação suportados,

criptografia da sessão SMTP por meio da utilização do protocolo TLS

(Transport Layer Security), tamanho máximo permitido para a mensagem,

dentre outros. Caso o servidor não esteja apto a responder a mensagem de

EHLO, o cliente deve enviar uma mensagem de HELO em seu lugar uma vez

que essa é de implementação obrigatória para todo e qualquer comunicação via

SMTP.

• AUTH

Essa mensagem é utilizada para conduzir o processo de autenticação do cliente

junto ao servidor SMTP, desde que esse suporte essa funcionalidade. Como

parâmetro desse comando, o cliente deve apresentar ao servidor o método de

autenticação a ser utilizado (e.g. PLAIN, LOGIN e CRAM-MD5) desde que esse

esteja dentre os métodos suportados pelo servidor SMTP. No resultado do

comando EHLO o servidor apresenta quais mecanismos de autenticação são

suportados. Vale ressaltar que esses métodos possuem níveis distintos de

segurança.

• STARTTLS

Utilizado para estabelecer uma conexão segura por meio do protocolo TLS -

Transport Layer Security entre o cliente e o servidor SMTP com o intuito de

evitar a transmissão “em claro” das informações por meio da Internet, por

exemplo. Essa alternativa torna-se ainda mais segura quando combinada com

algum mecanismo de autenticação negociado por meio do comando AUTH.

Exemplo de sessão SMTP utilizando o comando “telnet”:


1 # telnet mail.dominio.com.br 25

2 Trying 1.2.3.4...

3 Connected to mail.dominio.com.br.

4 Escape character is '^]'.

5 220 mail.dominio.com.br ESMTP Postfix (Debian/GNU)

6 HELO hostname.origem.com.br

7 250 hostname.origem.com.br

8 MAIL FROM: <[email protected]>

9 250 2.1.0 Ok

10 RCPT TO: <[email protected]>

11 250 2.1.5 Ok

12 DATA

13 354 End data with <CR><LF>.<CR><LF>

14 From: Nome do Remetente <[email protected]>

15 To: Nome do Destinatário <[email protected]>

16 Subject: Teste de Comandos SMTP

17 E-mail teste - Comandos SMTP

18 .

19 250 2.0.0 Ok: queued as 38C932016

20 QUIT

21 221 2.0.0 Bye

22 Connection closed by foreign host.

1.4.2. Códigos do SMTP

Para cada comando encaminhado pelo cliente é retornado um código pelo

servidor. Por exemplo, no exemplo a seguir, em resposta ao comando HELO, o

servidor responde com o código 250:

HELO hostname.origem.com.br

250 hostname.origem.com.br

No próximo exemplo, o código 354 é retornado pelo servidor em resposta ao

comando DATA:

DATA

354 End data with <CR><LF>.<CR><LF>


Cada código possui um significado e é importante saber o seu significado,

principalmente do primeiro dígito que indica a natureza do código. A seguir são

apresentados suas descrições correspondes:

Dígito Significado

2XX O servidor aceitou o comando com sucesso e está esperando o comando seguinte.

3XX O comando foi aceito pelo servidor entretanto, trata-se de um comando que necessita de informações adicionais a serem encaminhadas pelo cliente por meio de outros comandos. O código “354”, por exemplo, é normalmente encaminhado em resposta ao comando DATA que exige outras informações para ser processo corretamente pelo servidor.

4XX O comando não foi processado com sucesso pelo servidor por conta de algum erro. Entretanto, trata-se de um erro de caráter temporário e, por conta disso, o cliente deve tentar novamente a submissão do comando após algum tempo.

5XX Da mesma forma que os erros iniciados por 4XX, os códigos 5XX indicam erros. Porém, os erros são considerados permanentes e o cliente não deve tentar submeter o comando novamente ao servidor.

O quadro abaixo apresenta alguns códigos de retorno em detalhes:

Cód - Descrição

211 - System status, or system help reply

214 - Help message (Informação de como usar o Receptor-SMTP ou algum

comando não padronizado)

220 - <domain> Service ready

221 - <domain> Service closing transmission channel

250 - Requested mail action okay, completed

251 - User not local; will forward to <forward-path>

354 - Start mail input; end with <CRLF>.<CRLF>

421 - <domain> Service not available, closing transmission channel (É

uma resposta que pode ser dada a qualquer comando; indica que

a conexão foi desfeita)

450 - Requested mail action not taken: mailbox unavailable (Ex.:

maixbox está em uso)

451 - Requested action aborted: local error in processing

452 - Requested action not taken: insufficient system storage

500 - Syntax error, command unrecognized (Usado também para casos tal

como linha muito longa)

501 - Syntax error in parameters or arguments

502 - Command not implemented

503 - Bad sequence of commands

504 - Command parameter not implemented


550 - Requested action not taken: mailbox unavailable (ex.: mailbox

não encontrado, sem acesso)

551 - User not local; please try <forward-path>

552 - Requested mail action aborted: exceeded storage allocation

553 - Requested action not taken: mailbox name not allowed

(ex.:sintaxe do mailbox errada)

554 - Transaction failed

As RFCs 5321 e 5322 abordam mais detalhes a respeito das mensagens de

retorno e de outros aspectos do protocolo SMTP.

1.4.3. Comandos POP

• USER name

Informa o usuário para a autenticação no POP

• PASS string

Informar a senha do usuário para autenticação no POP

• STAT

Significa status da caixa postal, onde: bytes + msgs OK. Onde “msgs” é o número de mensagens na caixa de correio e “bytes” é o espaço usado por todas as mensagens. Exemplo de resposta:

+ 3 OK 345.910

• LIST [msg]

Lista cada mensagem em uma linha com seu número e tamanho em “bytes”.

Exemplo:

OK + 3 messages

1 1205

2 305

3 344400

• RETR msg


Apresenta a mensagem para o usuário (exibe na tela do “telnet”). Exemplo:

RETR 2

• DELE msg

Marca a mensagem para exclusão da caixa postal, que só é apagada após o comando

• NOOP

Similar ao NOOP do SMTP faz com que o servidor responda OK

• RSET

Isso redefine (desmarca) qualquer mensagem previamente marcada para exclusão nesta sessão para que o comando QUIT não exclua as mensagens.

• QUIT

Finaliza a sessão POP e exclui as mensagens marcadas para deleção

Exemplo de sessão POP utilizando o comando “telnet”:

telnet localhost 110

Trying 127.0.0.1...

Connected to 1217.0.0.1.

Escape character is '^]'.

+OK Hello there.

user [email protected]

+OK Password required.

pass 123

+OK logged in.

STAT

+OK 2 320

LIST

+OK 2 messages (320 octets)

1 120

2 200

.

RETR 1

+OK 120 octets

<the POP3 server sends message 1>

.

DELE 1


+OK message 1 deleted

RETR 2

+OK 200 octets

<the POP3 server sends message 2>

.

DELE 2

+OK message 2 deleted

QUIT

+OK dewey POP3 server signing off (maildrop empty)

<close connection>

<wait for next connection>


1.4.4. Comandos IMAP

• LOGIN user pass

Comando para autenticação

• SELECT box

Seleciona a pasta/caixa a ser lida

• FETCH msg body[header]

Realiza a leitura da mensagem apresentando o cabeçalho

• LOGOUT

Finaliza a sessão IMAP

• CAPABILITY

Verifica as capacidades do servidor IMAP

• STARTTLS

Inicia a comunicação usando o protocolo TLS(Criptografia)

• CREATE

Cria uma pasta/caixa

• DELETE

Remove uma pasta/caixa

• RENAME

Renomeia uma pasta/caixa

Mais comandos do IMAP na RFC 3501 - http://tools.ietf.org/html/rfc3501

Exemplo de sessão IMAP utilizando o comando telnet:


1 # telnet mail.dominio.com 143

2 * OK Courier-IMAP ready. Copyright 1998-2002 Double Precision, Inc.

3 login [email protected] mypassword

4 OK LOGIN Ok.

5 select INBOX

6 * FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent)

7 * OK [PERMANENTFLAGS (\Draft \Answered \Flagged \Deleted \Seen)]

Limited

8 * 0 EXISTS

9 * 0 RECENT

10 * OK [UIDVALIDITY 1021381622] Ok

11 OK [READ-WRITE] Ok

12 logout

13 * BYE Courier-IMAP server shutting down

14 OK LOGOUT comple


1.5. Exercícios

1. Quem desenvolveu o E-mail?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

2. Qual a função do Servidor de E-mail?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

3. O que é o protocolo SMTP, POP, e IMAP?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________


4. Qual comando SMTP identifica o hostname e o remetente na sessão SMTP?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

5. Qual a vantagem do protocolo IMAP se comparado com o POP ?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

6. O que são as siglas MTA, MDA e MUA?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

Capítulo 2 Infraestrutura de Correio Eletrônico - 26

Capítulo 2

Infraestrutura de Correio Eletrônico


2.1. Considerações

Antes de apresentarmos a nossa proposta de infraestrutura de correio

eletrônico, gostaríamos de alertar que essa proposta pode não ser a ideal para o seu

ambiente. É necessário um estudo preliminar para identificar a melhor arquitetura

que se adequará a sua necessidade. Um exemplo prático: Para um cliente com 10

contas de usuários não serão necessários múltiplos servidores.

É muito importante saber mensurar recursos para uma arquitetura de e-mail,

saber quantas maquinas serão necessárias para suportar a quantidade de usuários,

se a capacidade de armazenamento é suficiente para o total de usuários, se os

servidores são capazes de aguentar a carga de e-mails, etc. Abordaremos esses

temas ao logo dessa apostila.

A arquitetura proposta nessa apostila é para fins didáticos, onde serão

apresentados os componentes que fazem parte da infraestrutura de correio

eletrônico. Presumimos que a instalação do sistema operacional já esteja efetuada e

as interfaces de rede configuradas.

Ao longo da apostila abordaremos as boas práticas de instalação,

particionamento e configuração do sistema operacional e seus componentes.

A apostila esta baseada e Debian GNU/Linux, mas os procedimentos aqui

descritos podem ser portados para uma outra distribuição de sua

preferência.

2.2. Componentes da infraestrutura de correio eletrônico

Vide figura abaixo:


Conforme apresentado na figura acima, iremos executar 7 passos para colocar

a nossa infraestrutura de e-mail funcionando.

O passo 1 compreende a instalação e configuração do nosso serviço de DNS

utilizando a ferramenta BIND, para localização de domínios externos.

No passo 2 apresenta a instalação e configuração do servidor SMTP Postfix,

que permitirá o envio e recebimento de e-mail.

O passo 3 iremos instalar e configurar OpenLDAP que será nossa base de

usuários para autenticação dos serviços SMTP e IMAP.

No passo 4, iremos configurar o serviço IMAP utilizando a ferramenta Dovecot,

que permitira aos usuários visualizarem seus e-mails.

Em sequencia, no passo 5, iremos configurar o MUA, onde utilizaremos o

Thunderbird como nosso cliente de e-mail.

O passo 6 consiste na configuração de um webmail que permitira usuários

externos acessarem suas caixas postais.

Para finalizar o passo 7 iremos instalar e configurar o serviço de Antispam e

Antivírus. Iremos utilizar o conjunto de ferramentas Amavis-New que servirá de


ponte para o SpamAssassim e Clamv Antivírus.

Em cada passo apresentado, abordaremos a instalação, configuração, resolução

de problemas e integração com os demais serviços da nossa infraestrutura de e-mail.

Capítulo 3 Instalando e Configurando o DNS - 30

Capítulo 3

Instalando e Configurando o DNS


3.1. Introdução

O DNS é um sistema hierárquico que é pode ser representada da seguinte

forma:

O DNS foi concebido para realizar a tradução de nomes para números

necessários ao estabelecimento de conexões entre computadores ligados à Internet.

Conforme apresentado anteriormente no Capítulo 1, “Funcionamento básico de

um sistema de e-mails”, o DNS - Domain Name System desempenha um papel

fundamental em qualquer sistema de e-mails. Por conta disso, instalar e configurar

um sistema de e-mail corretamente significa, necessariamente, validar ou configurar,

se for o caso, os seus servidores DNS.

As informações dispostas em um mapa de configuração DNS são classificadas

por tipo, conforme mostrado a seguir:

• “A” (Address): tipo de registro utilizado para fazer o mapeamento de um

nome para o seu respectivo endereço IP. É o tipo de registro mais comum dado que desempenha uma das funções primordiais de qualquer servidor DNS. Portanto, qualquer máquina que tenha um endereço IP associado ao seu nome precisa, necessariamente, ter uma entrada no mapa de configuração do DNS com o registro do tipo “A”;

• “NS” (Name Server): deve ser utilizado para indicar quais são os nomes dos

servidores DNS responsáveis por prover informações a respeito do domínio em questão. Esse é um tipo de registro obrigatório no sentido de que cada domínio precisa ter uma ou mais entradas “NS” para indicar, pelo menos, um servidor DNS responsável pelas informações do domínio. Será(ão) esse(s) servidor(es) que os outros servidores irão tentar contatar durante o processo de resolução de nomes e de outras informações do domínio;


• “CNAME” (Canonical Name): por meio desse tipo de registro, é possível criar

um “alias” de um nome para o outro. Por exemplo, pode-se dizer, por meio de um registro “CNAME” que o nome web.4linux.com aponta para o nome

www.4linux.com. O nome www.4linux.com pode ainda apontar para outro nome e assim sucessivamente. O mais importante, contudo, é que o último nome referenciado aponte para um endereço de fato através de um registro do tipo “A”. Cometer esse erro é bastante comum, portanto, fique atento;

• “PTR” (Pointer): esse tipo de registro desempenha o papel inverso àquele do

tipo “A”. Em outras palavras, ele mapeia um endereço IP para um nome

correspondente. É utilizado para a configuração dos mapas reversos. Apesar de não aparentar ter qualquer relação direta com um sistema de e-mails, muitos MTAs verificam a resolução reversa do endereço IP de um cliente remoto que está encaminhando uma mensagem para verificar se o seu nome corresponde ao do domínio do remetente, por exemplo. Essa prática simples e cada vez mais comum, ajuda a bloquear diversas mensagens contendo SPAM, vírus e outras pragas digitais;

• “MX” (Mail Exchanger): o MX corresponde ao principal tipo de registro

correlacionado a um sistema de e-mails. Por meio dele é possível identificar quais são os nomes dos servidores de e-mails (ou MTAs, como queira) responsáveis por receber as mensagens eletrônicas do domínio para o qual esse servidor DNS está configurado. Um mesmo domínio pode conter vários registros do tipo “MX” cada um contendo uma prioridade que deve ser levada

em consideração pelos clientes que desejam encaminhar mensagens aos usuários desse domínio. O servidor de maior prioridade é contatado primeiro e, caso não seja possível repassar a mensagem a ele, o próximo na lista de prioridades é considerado.

Existem outros tipos de registros DNS que fogem do escopo desse treinamento.

Maiores informações podem ser consultadas na documentação do próprio

BIND.

Como um servidor SMTP descobre, então, o endereço IP do servidor para o

qual uma mensagem para certo domínio deve ser entregue? O domínio do

destinatário é, não surpreendentemente, utilizado como a chave em uma ou mais

pesquisas DNS. Obviamente que o servidor SMTP conta com a ajuda dos seus

servidores de DNS para obter as informações a respeito do MTA do destinatário. Por

exemplo, para encaminhar um e-mail para o usuário [email protected]. br , o nome

do domínio “4linux.com.br” será utilizado para que o MTA do emissor consiga

identificar quais são os servidores de e-mail responsáveis por tratar as mensagens



http://www.4linux.com/

http://www.4linux.com/


do domínio “4linux.com.br”. Esse processo segue, em linhas gerais, os seguintes

passos:

1. Encontra-se os endereços dos servidores DNS responsáveis pelo domínio. Essa

informação será provida por meio dos registros “NS”. No exemplo do domínio

4linux.com.br, citado anteriormente, os servidores ns1.4linux.com.br e

ns2.4linux.com.br serão retornados.

2. De posse dessa informação, um dos servidores DNS é selecionado e uma nova

consulta DNS é realizada, dessa vez, para saber qual o endereço IP do servidor

DNS selecionado através de uma informação do tipo “A”;

3. Tendo o endereço IP do servidor DNS selecionado, o próximo passo consiste em

entrar em contato com ele para identificar a lista de MTAs responsáveis por

esse domínio por meio de uma consulta do tipo “MX”. No caso do domínio

4linux.com.br, o servidor boca.4linux.com.br é o MTA responsável.

4. Com essa informação, uma nova consulta do tipo “A” é realizada para

determinar o endereço IP correspondente.

Todo esse processo pode ser realizado manualmente para fins didáticos e de

depuração do seu ambiente por meio do comando “host”, conforme apresentado no

quadro abaixo:

Obs.: Caso você não possua o comando “host” instalado execute os

seguintes comandos: aptitude install host

PASSO 1: encontrando os servidores DNS responsáveis por 4linux.com.br

# host -t NS 4linux.com.br

4linux.com.br name server ns2.4linux.com.br.

4linux.com.br name server ns1.4linux.com.br.

PASSO 2: buscando pelo endereço IP do servidor DNS selecionado

# host -t A ns1.4linux.com.br

ns1.4linux.com.br has address 200.212.122.137


PASSO 3: Perguntando ao servidor ns1.4linux.com.br o MTA responsável

pelo domínio

# host -t MX 4linux.com.br 200.212.122.137

Using domain server:

Name: 200.212.122.137

Address: 200.212.122.137#53

Aliases:

4linux.com.br mail is handled by 10 boca.4linux.com.br.

PASSO 4: Determinando o endereço IP do servior boca.4linux.com.br

# host -t A boca.4linux.com.br

Os passos anteriores são apresentados de maneira resumida apenas para fins

didáticos e focando apenas nas informações relevantes no que diz respeito a relação

que existe entre um servidor de e-mails e os servidores DNS.

A tabela abaixo apresenta um modelo de configuração do DNS utilizando o

software BIND da ISC - Internet Systems Consortium


1 $TTL 604800

2 @ IN SOA ns1.dominio.com.br. root.ns1.dominio.com.br. (

3 1 ; Serial

4 604800 ; Refresh

5 86400 ; Retry

6 2419200 ; Expire

7 604800 ) ; Negative Cache TTL

8 ;

9 @ IN NS ns1.dominio.com.br.

10 @ IN MX 10 mail1.dominio.com.br.



13 ns1 IN A 192.168.1.1

14 mail1 IN A 192.168.1.2

15 mail2 IN A 192.168.1.3

16 mail3 IN A 192.168.1.4

17 www IN A 192.168.1.5

18 ftp IN A 192.168.1.6

As linhas em negrito mostram a configuração realizada para tratamento de

entrega de e-mail. Observe que as linhas 10,11 e 12 apresentam três registros do

tipo MX. Isso é utilizado para aumentar o nível de disponibilidade do sistema de e-

mails apresentando através do DNS mais de um MTA responsável pelo domínio.

O valor ao lado do “MX” indica a prioridade daquele servidor de e-mails.

Sempre o servidor com o valor menor é considerado primeiro por parte de um MTA

que quer encaminhar uma mensagem ao domínio em questão. Quando o valor da

prioridade é igual o cliente pode selecionar qualquer um deles para encaminhar a

mensagem. Essa pode ser uma boa alternativa para balancear de maneira simples a

carga de processamento de e-mails entre dois ou mais servidores. Observe no

quadro abaixo que os servidores mail1.dominio.com.br e mail2.dominio.com.br

possuem prioridades iguais.

Quando todos os servidores de prioridade mais baixa não estão disponíveis, o

MTA do remetente de uma mensagem tenta encaminhá-la a outro MTA com

prioridade mais baixa.





Se o servidor mail3.dominio.com.br não estiver apto a receber a mensagem, o MTA do

remetente tentará entregá-la posteriormente conforme sua configuração interna para tratar

mensagens que tiveram problemas em seu encaminhamento.

Como já mostrado anteriormente, para verificar registros "MX” pode-se utilizar o comando

“host”, presente na grande maioria das distribuições GNU/Linux. O quandro abaixo apresenta sua

a utilização para determinar os MTAs responsáveis pela entrega de e-mails para o domínio

gmail.com, por exemplo:

1 host -t mx gmail.com

2 gmail.com mail is handled by 50 gsmtp183.google.com.

3 gmail.com mail is handled by 5 gmail-smtp-in.l.google.com.

4 gmail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.

5 gmail.com mail is handled by 10 alt2.gmail-smtp-in.l.google.com.

6 gmail.com mail is handled by 50 gsmtp147.google.com.

3.2. Pratica Dirigida

3.2.1. Procedimentos pós-instalação:

Configurar o VIM para enumeração de linhas e destaque da sintaxe de scripts:

1 aptitude update

2 aptitude install vim

3 aptitude install rpl

4 echo “syntax on” >> /etc/vim/vimrc

3.2.2. Instalando e configurando o DNS

Par iniciar a instalação do BIND execute, como super usuário, o seguinte

comando:

# aptitude install bind9 dnsutils

Agora será configurado o DNS para atender às requisições do Postfix. Para tal


edite o arquivo /etc/bind/named.conf.local:

# vim /etc/bind/named.conf.local

Configure as zonas primária e reversa para o domínio “matrizX.com.br” e

“filialX.com.br”

1 zone "matrizx.com.br" {

2 type master;

3 file "/etc/bind/db_matrizX.conf";

4 };

5 zone "filialx.com.br" {

6 type master;

7 file "/etc/bind/db_filialX.conf";

8 };

9 zone "200.168.192.in-addr.arpa" {

10 type master;

11 file "/etc/bind/db_reverso.conf";

12 };

As linhas de 8 a 19 demonstram as configurações necessárias para criação de

zonas para os domínios matrizX.com.br e filialX.com.br, bem como para a zona

reversa para os endereços 192.168.0. A configuração das demais opções do servidor

DNS bem como o detalhamento de seus parâmetros vai além do escopo deste curso.

O próximo passo consiste em configurar as zonas criadas, detalhando suas

associações de nomes e endereços IP, referências aos servidores responsáveis pelo

processamento de emails para o domínio, dentre outras informações. Para isso,

devem ser criados os arquivos db_matrizX.conf, db_filiaX.conf e

db_dominio_reverso.conf, conforme apresentado a seguir:

# vim /etc/bind/db_matrizX.conf


1 $TTL 1D

2 @ IN SOA mailx.matrizx.com.br. postmaster.matrizx.com.br. (

3 2011070101 ; Serial

4 3H ; Refresh

5 1H ; Retry

6 24H ; Expire

7 24H ) ; Negative Cache TTL

8 ;

9 @ IN NS mailx.matrizx.com.br.

10 @ IN MX 5 mailx.matrizx.com.br.

11 mail IN A 192.168.200.X

12 smtp IN CNAME mailx.matrizx.com.br.

13 imap IN CNAME mailx.matrizx.com.br.

A linha 10 faz referência ao registro MX (descrito no início desse capítulo)

para o domínio matrizX.com.br onde a máquina com o nome “mailX.matrizX.com.br”

é o servidor de e-mail para recepção de mensagens. Isso irá permitir que outros

servidores DNS encontrem seu servidor de e-mail para a entrega de mensagens

através dos MTAs correspondentes.

O último mapa a ser criado para a configuração do servidor DNS é o chamado

reverso, que mapeia endereços IP para os seus nomes correspondentes. A seguir é

apresentado o formato desse arquivo para o exemplo considerado no estudo de caso:

# vim /etc/bind/db_reverso.conf


1 $TTL 1D

2 @ IN SOA mailx.matrizx.com.br. postmaster.mailx.matrizx.com.br.

(

3 2011070101 ; Serial

4 3H ; Refresh

5 1H ; Retry

6 24H ; Expire

7 24H ) ; Negative Cache TTL

8 ;

9 @ IN NS mailx.matrizx.com.br.

10 X IN PTR mailx.matrizx.com.br.

Muitos administradores de sistemas, fundamentalmente os menos experientes,

negligenciam a configuração do mapa reverso, responsável pelo mapeamento dos

seus endereços IP para os nomes correspondentes. Essa medida, entretanto, pode

provocar problemas uma vez que muitos servidores, por questões de segurança,

costumam validar se o endereço IP de um MTA possui um nome associado. Caso

negativo, aquela mensagem é rejeitada. Outros, que possuem configurações mais

restritivas, verificam se o IP do MTA que está mandando a mensagem corresponde a

um nome válido para o domínio do e-mail do remetente. Ambas as configurações

ajudam a prevenir a ação de “spammers” que se valem de servidores mal

configurados para enviar mensagens com publicidade, vírus, worms, pishing, dentre

outro.

Em seguida, deve-se configurar o servidor de e-mails para solicitar as

requisições de resolução de nomes para o DNS que acabou de ser instalado,

configurado e testado:

# echo “mailX” > /etc/hostname

Editando o resolv.conf

# vim /etc/resolv.conf

1 search matrizX.com.br

2 nameserver 127.0.0.1

3 nameserver 8.8.8.8

Configurando o arquivo hosts


# vim /etc/hosts

1 192.168.200.X mail.matrizX.com.br mailX

Checando a syntax dos aquivos de configuração:

#Verificando o named.conf

named-checkconf

# Verificando os arquivos de zona(domínios)

named-checkzone matrizX.com.br /etc/bind/db_matrizX.conf

zone matrizX.com.br/IN: loaded serial 1

OK

Reinicie o Bind

/etc/init.d/bind9 restart

ou

invoke-rc.d bind9 restart

Testando a resolução de nomes usando o comando “dig” e o comando “host”:

# dig @localhost any matrizX.com.br

; <<>> DiG 9.6-ESV-R1 <<>> @localhost any matrizX.com.br

; (2 servers found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57110

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:

;matrizX.com.br. IN ANY

;; ANSWER SECTION:

matrizX.com.br. 604800 IN SOA mailX.matrizX.com.br.

root.mail.matrizX.com.br. 1 604800 86400 2419200 604800

matrizX.com.br. 604800 IN NS mailX.matrizX.com.br.

matrizX.com.br. 604800 IN MX 10 mailX.matrizX.com.br.

;; ADDITIONAL SECTION:

mailX.matrizX.com.br. 604800 IN A 192.168.200.X

;; Query time: 1 msec


;; SERVER: 127.0.0.1#53(127.0.0.1)

;; WHEN: Fri Aug 27 14:24:53 2010

;; MSG SIZE rcvd: 130

Verificando o reverso

# host 192.168.200.X

X.200.168.192.in-addr.arpa domain name pointer

mail.matrizx.com.br.200.168.192.in-addr.arpa.


3.3. Laboratório

Configurar o domínio filialX.com.br conforme exemplo descrito na sessão 3.2 prática

dirigida.


3.4. Exercícios

1. Qual a importância do DNS na infraestrutura de correio eletrônico?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

2. Qual a importância do reverso para infraestrutura de correio eletrônico?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

3. O que é o registro MX no DNS e qual a importância dele para o correio

eletrônico?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

Capítulo 4 Instalando e Configurando o Postfix - 44

Capítulo 4

Instalando e Configurando o Postfix


4.1. Introdução

4.1.1. Histórico

A ideia inicial do Postfix era a de produzir um substituto para o Sendmail que

fosse “rápido, fácil de administrar e seguro”. Trata-se de um projeto OpenSource

patrocinado pela IBM, criado e , Ph.D. em Física pela Groningen University na

Holanda. Segundo seu criador, o projeto e o desenvolvimento do Postfix foram

norteados pelas seguintes diretrizes:

• Confiabilidade: o sistema é capaz de manter seu funcionamento mesmo diante

de condições adversas como falta de memória ou mesmo espaço em disco.

Nesses casos, o sistema tenta reduzir sua atividade para facilitar a retomada de

condições por parte do servidor;

• Segurança: o Postfix é composto por componentes diferentes. Cada

componente é executado com o mínimo de privilégios necessários para o

desempenho de suas funções, de forma que um componente com níveis mais

elevados de privilégios nunca “confie” em outros que possuam níveis inferiores.

Além disso, o sistema possui recursos para minimizar a possibilidade de

ataques dos tipos buffer overflow e DoS (Denial of Service), dentre outros. Um

dos próprios slogans do Postfix é “Security by Design” que ratifica o fato de

que aspectos de segurança foram considerados desde sua concepção;

• Desempenho: o Postfix possui recursos capazes de colaborar com o

desempenho geral do sistema operacional no qual está sendo executado por

meio da limitação, por exemplo, dos processos criados e dos acessos ao sistema

de arquivos necessários para o processamento de mensagens;

• Flexibilidade: essa diretriz diz respeito ao fato dos componentes do Postfix

serem independentes permitindo customizações individuais que facilitam a

especialização das configurações e a manutenção de suas funcionalidades.


• Simplicidade de uso: comparado a outros servidores de e-mails, o Postfix é

um dos que possui uma das configurações mais simplificadas e organizadas. Os

parâmetros seguem uma lógica de simples compreensão. Com poucas linhas de

configuração já é possível ter um servidor de e-mails funcionando. Entretanto,

para um ambiente de produção, mais diretrizes, além daqueles contidas na

instalação padrão, são necessárias para tornar o ambiente seguro;

• Compatibilidade com Sendmail: o sistema adota configurações e convenções

criadas pelo Sendmail por questões de compatibilidade. Esse é um recurso que

tem por objetivo facilitar a adoção do Postfix. Mais informações sobre essa

característica serão discutidas a seguir.

O Postfix possui suporte para diversos sistemas operacionais dentre os quais

AIX, BSD, HP-UX, IRIX, LINUX, MacOS X, Solaris, Tru64 UNIX e outros sistemas

baseados em UNIX. Atualmente, a “release” estável encontra-se na versão 2.7.

Entretanto, como o desenvolvimento do Postfix é constante e dinâmico é sempre

importante consultar o site do projeto para estar atualizado quanto aos novos

recursos, correçõs e outras novidades.

Apesar da “release” experimental estar sempre disponível para download,

considere utilizar a versão estável, principalmente nos servidores de e-mail de

produção.

Para o nosso treinamento iremos utilizar a versão estável disponível nos

repositórios do Debian

O Postfix se consolidou como uma alternativa ao Sendmail em razão de suas

características técnicas tais como maior robustez, melhor desempenho e maior

facilidade na manutenção e configuração. Entretanto, conforme citado

anteriormente, para facilitar sua adoção em ambientes Unix, onde o Sendmail era (e

ainda é) bastante popular, o Postfix manteve diversos comandos e arquivos

compatíveis com os do Sendmail. Essa alternativa evita, por exemplo, a necessidade

de mudança de scripts e softwares já desenvolvidos considerando os recursos do

Sendmail.


4.1.2. Funcionamento do Postfix

Outra característica importante do Postfix é a sua construção modular. Ou seja,

ao contrário da estrutura monolítica do Sendmail onde apenas um processo é o

responsável por todas as atividades relacionadas com o processamento de

mensagens, no caso do Postfix vários componentes são os responsáveis pelo

funcionamento do sistema. Essa arquitetura, além de facilitar a manutenção do

código e a implementação de novas funcionalidades, agrega algumas importantes

características de segurança dentre as quais a possibilidade de evitar e/ou minimizar

os impactos de eventuais ataques como os de buffer overflow, por exemplo.


Programas o Postfix Daemons

Filas do Postfix

Tabelas de Pesquisa – Lookup

Tables

A arquitetura interna do sistema funciona com a ideia de processos

cooperativos. As tarefas que o compõem o Postfix são independentes e provêem

serviços umas às outras. Por exemplo, há uma tarefa que provê reescrita/tradução de

endereços para todos os outros processos do Postfix.

O processo principal é o "master", que tem a função de administrar os outros

daemons do Postfix: carregar o "smtpd" quando há necessidade de atender a porta

SMTP; manter o "trivial-rewrite" em execução para fazer a manipulação dos

endereços de correio; chamar o "qmgr" para gerenciar a fila de e-mails ainda não

entregues; chamar o "pickup", que pega novas mensagens e as joga na fila para

entrega; dentre outros.


O "master" também se encarrega de manter uma espécie de cache dos

daemons que já foram iniciados, reutilizando processos ou removendo-os depois de

um tempo específico de ociosidade. Isso diminui bastante o tempo e o esforço

dispendidos na maneira mais tradicional, chamando o processo e removendo-o logo

que este acabe sua tarefa. Há sempre um tempo que leva para carregar um processo

e todas as suas bibliotecas do disco, alocar memória, etc.

O modo pelo qual o "master" gerencia isso, implica que esse tempo é

praticamente nulo, uma vez que o processo já esta no ar; ao mesmo tempo, o

"master" mantém o sistema sob controle, não deixando que processos inúteis ocupem

recursos da máquina.

Os arquivos de configuração são responsáveis por definir o comportamento de

cada “daemon” do Postfix sendo que os principais arquivos são: “main.cf” e

“master.cf”, contidos, normalmente, dentro do diretório /etc/postfix. Mais detalhes


sobre ambos os arquivos serão apresentados a seguir.

4.1.3. Daemons do Postfix

O Postfix é constituído por um número pequeno de daemons que interagem

com o usuário (sendmail, postqueue, postsuper, e assim por diante) e os demais

“daemons” são executados em segundo plano sendo controlados pelo “master”, cuja

função principal é identificar a o processo e direcioná-lo ao “daemon” apropriado.

Este design modular permite um maior nível de segurança, pois cada “daemon” é

executado com os privilégios mínimos necessários para cumprir suas funções,

conforme dito anteriormente.

bounce e defer

Um MTA deve notificar o remetente sobre a não entrega do e-mail. No Postfix

os daemons “bounce” e “defer” são os responsáveis por essa tarefa, que é solicitado

pelo “daemon” gestor da fila de mensagens, (qmgr). Especificamente, os dois tipos

de eventos que causam envio de avisos são erros irrecuperáveis e um destino que é

inacessível por um determinado período de tempo.

error

O error é o “daemon” agente de entrega entre o “daemons” local ou smtp. É

um agente de entrega que cria um e-mail para ser devolvido, e-mail de erro. Se um e-

mail é enviado para o “daemon” error ele informa o “daemon” bounce para gravar

um destinatário que foi “undeliverable”.

trivial-rewrite

O “daemon” trivial-rewrite, a pedido do “daemon” cleanup, reescreve

endereços para o padrão “user@fqdn”, onde FQDN - Fully Qualified Domain

Name é o nome completamente qualificado de um domínio (e.g. 4linux.com.br,

gmail.com, dominio.com.br, dentre outros). Este “daemon” também é o responsável

pela resolução de destinos, a pedido do qmgr. Por padrão, o trivial-rewrite apenas

distingue destinos locais e remotos.

showq

O “daemon” showq lista as filas do Postfix e é o programa por detrás do

comando mailq.


flush

O “daemon” flush é o responsável por limpar a fila de e-mails pendentes.

qmgr

O qmgr - queue manager ou ainda gerenciador de filas, em português, é um

dos principais “daemons” do Postfix, uma vez que é o responsável, como o próprio

nome sugere, pelo gerenciamento das filas de mensagens incoming, active, deferred

e corrupt

Ao receber uma nova mensagem por qualquer um dos seus componentes que

possuem essa finalidade, o “daemon” cleanup, após realizar algumas das verificações

de sua competência, coloca a mensagem na fila incoming e notifica o “daemon” qmgr.

A partir desse momento, o qmgr solicita ao trivial-rewrite que determine

algumas informações importantes para o processamento da mensagem tais como o

método de transporte a ser utilizado, dados para o roteamento do e-mail, eventuais

ajustes no endereço dos destinatários e ainda o próximo “host” que deve receber

essa mensagem.

Em seguida, a mensagem é movida para a fila active e o próprio qmgr invoca o

“daemon” correspondente ao agente que será responsável pela entrega da

mensagem. Vale a pena ressaltar que o qmgr pode atrasar o repasse da mensagem

caso os recursos de memória e carga de operações de I/O do servidor de e-mails

estejam escassos, por exemplo.

Caso um determinado e-mail, por alguma razão, não puder ser entregue, ele

será depositado na fila deferred.

Outra atividade importante desempenhada pelo qmgr consiste em comunicar-

se com os “daemons” bounce e defer para gerar mensagens de status referentes ao

processamento de e-mails que tiveram problemas em suas entregas. Essas

mensagens podem ser encaminhadas ao remetente e/ou ao próprio administrador do

sistema de e-mails, conhecido por postmaster, conforme já discutido anteriormente.

proxymap

Os processos clientes do Postfix podem obter acesso apenas de leitura à mapas

através do “daemon” proxymap. Ao compartilhar um único mapa aberto entre muitos


daemons Postfix, o proxymap contorna restrições de chroot e reduz o número de

lookup tables abertas.

spawn

O spawn cria um processo não Postfix. A sua utilização é somente para

filtragem externa de conteúdo. Exemplo: Greylist.

local

Como o próprio nome sugere, o “daemon” local é o responsável pela entrega de

e-mails cujos destinatários são contas de usuários locais em um determinado

servidor. Por exemplo, se o destinatário de uma mensagem é

[email protected] e o servidor de e-mails que está processando essa

mensagem é o encarregado pelo tratamento das mensagens desse domínio, o

“daemon” local será o responsável por depositar essa mensagem na caixa postal

(mailbox) do usuário “joao.silva”.

Esse componente também tem como função analisar se o endereço do

destinatário consiste de um alias, por meio de uma tabela de mapeamento que

historicamente fica no arquivo “/etc/aliases” ou no arquivo “.forward”, localizado

dentro do diretório home do usuário.

Caso o destinatário seja, de fato, um alias, a mensagem precisa ser

reencaminhada ao servidor de e-mails como se fosse uma nova mensagem cujo

destinatário consiste do(s) novo(s) endereço(s) obtido(s) a partir de um dos arquivos

mencionados anteriormente, por exemplo.

Os agentes de entrega, como o próprio “daemon” local, também precisam estar

preparados para adversidades. Portanto, caso uma mensagem não possa ser

entregue por conta de problemas de natureza temporária, o qmgr (queue manager) é

notificado e a mensagem é posta na fila deferred para que ocorram outras tentativas

de entrega. Se o erro for de caráter permanente, a mensagem é repassada ao qmgr

que, por sua vez, comanda o processo de retorná-la ao seu remetente.

O “daemon” local pode escrever para caixas de e-mails nos formatos “mbox” e

“maildir”. No caso do primeiro, todas as mensagens de um usuário são acumuladas

em um único arquivo enquanto que no formato “maildir” as mensagens são salvas em

arquivos separados dispostos em um conjunto de diretórios. Ambos possuem


vantagens e desvantagens. Por conta disso, é importante fazer um levantamento mais

apurado sobre ambas as alternativas para selecionar aquela que irá atender melhor

às suas necessidades.

É possível ainda delegar a tarefa de depositar as mensagens nas caixas dos

usuários à agentes de entrega local (LDA) como o “procmail” e o “maildrop” que

fornecem recursos mais avançados como a filtragem de conteúdo e a tomada de

decisões como descarte de mensagem, encaminhamento a outro servidor e/ou

usuário, dentre outros.

virtual

Desempenha um papel semelhante ao agente de entrega local entretanto, o

“daemon” virtual tem esse nome pelo fato de lidar com domínios virtuais utilizados

para que um único servidor de e-mails consiga hospedar, ao mesmo tempo, múltiplos

domínios com usuários independentes em cada um deles.

Nesse caso, os usuários, diferentemente daqueles que recebem mensagens por

meio do “daemon” local, não possuem contas de usuários com acesso a “shell” no

servidor de e-mails. Em outras palavras, nesse caso, as contas de e-mails não estão

atreladas a usuários de sistema.

smtp

O “daemon” smtp transporta as mensagens para destinos remotos, ou seja,

para outros servidores MTA.

lmtp

O “daemon” lmtp comunica com servidores de e-mail local e remoto usando o

protocolo LMTP definido na RFC 2033. É frequentemente utilizado com o servidor

IMAP Cyrus.

A principal vantagem em utilizar o LMTP é poder direcionar mensagens para

múltiplos servidores de caixas de e-mail. Exemplo o Cyrus IMAP.

pipe

O “daemon” pipe é a saída para outros mecanismos de transporte de e-mail. Ele

invoca programas com os parâmetros e os pipes necessários para seu padrão de


entrada.

pickup

O “daemon” pickup pega as mensagens colocadas na fila maildrop pelo

programa sendmail. Depois de realizar algumas checagens,pickup passa as

mensagens para o “daemon” cleanup.

smtpd

O “daemon” smtpd manipula a comunicação dos clientes que se conectam ao

Postfix para entregar as mensagens através do protocolo SMTP. É a porta de entrada

de mensagens vindas de clientes ou de servidores MTAs remotos.

O smtpd executa uma série de checagens, cujo objetivo é proteger o resto do

sistema Postfix e pode ser configurado para implementar retenção de SPAM

utilizando, por exemplo, controles baseados em listas negras (blacklists).

cleanup

O “daemon” cleanup é a etapa de transformação para novas mensagens.

Acrescenta qualquer cabeçalhos exigidos que estejam faltando, manda para o

endereço reescrevendo-o, e (opcionalmente) extrai endereços do destinatário do

cabeçalho da mensagem . O “daemon” cleanup insere o resultado na fila incoming e,

em seguida, notifica o gerente de fila que chegou um novo e-mail.

sendmail

O sendmail do Postfix é um comando que substitui e emula o seu

correspondente do Sendmail original. Seu objetivo é fornecer uma interface

compatível com aquela provida pelo Sendmail de forma que aplicações que a

utilizavam continuem a operar normalmente quando o servidor de e-mails for o

Postfix. Ele interage com o postdrop para colocar mensagens na fila maildrop para,

posteriormente, serem resgatadas pelo “daemon” pickup.

QMQP

O daemon QMQP implementa protocolo o Quick Mail Queuing Protocol (QMQP;

ver http://cr.yp.to/proto/qmqp.html) para tornar o Postfix compatível com o qmail,

ezmlm.


anvil

O “daemon” anvil é a defesa preliminar contra clientes SMTP e ataques de

denial-of-service que inundam o servidor SMTP com inúmeras tentativas simultâneas

ou sucessivas de conexão. Ele vem com uma lista branca com capacidade para

desabilitar restrições para clientes autorizados.

4.1.4. Filas de mensagens do Postfix

O diretório das filas de mensagens do Postfix é definido pelo parâmetro

queue_direcory no “main.cf”. Cada fila tem seu próprio subdiretório com um nome

para identificá-la. As filas que o Postfix trabalha são: incoming, maildrop, deferred,

active, hold e corrupt.

Incoming - Esta é a fila de e-mails entrantes a partir da rede,

repassados pelo maildrop;

Active - Esta é a fila de e-mails que foram abertos pelo gerenciador

da fila, para entregas. Essa fila tem um número limite para

entrada de mensagens;

Deferred - Esta é a fila de mensagens que não conseguiram ser

entregues na primeira tentativa. O gerenciador da fila vai

seguir as configurações do “main.cf” para novas tentativas de

entregas. Por padrão ele vai dobrando o tempo de entrega a

cada tentativa;

Corrupt - As mensagens das filas que não conseguem ser lidas ou que

estão danificadas, são movidas para esta fila para uma

inspeção;

Hold - Mensagens que são colocadas em espera pelo administrador

vão para esta fila até que alguém especifique que ela deva ser

liberada.


4.1.5. Status da entrega

O “daemon” QMGR mantém um arquivo com o mesmo nome da fila em outros

diretórios com informações sobre o estado da mensagem. A seguir estão listados os

status possíveis:

Bounce - Informação sobre os motivos da mensagem ter recebido um

bounce (mensagem de erro). Estas informações são gerenciadas

pelo “daemon” bounce;

Defer - Informação sobre os motivos da mensagem estar com o envio

atrasado. Gerenciadas pelo daemon defer;

Trace - Informação sobre requisições com o comando “sendmail -v” ou

“sendmail -bv” do Postfix.

Sent - Sucesso! Mensagem entregue.

4.1.6. Arquivos de configuração do Postfix

O Postfix lê suas configurações a partir dos arquivos de texto localizados no

diretório /etc. Arquivos de configuração do Postfix normalmente são armazenados

em /etc/postfix, mas você pode configurar o Postfix para que utilize um outro

diretório qualquer. O Postfix usa dois arquivos de configuração principais:o

master.cf e o main.cf (abordados no Capítulo 4) e quaisquer arquivos auxiliares

que você mesmo configurar. Após alguma alteração nesses arquivos, será necessário

recarregar o Postfix para que as modificações entre em vigor.

O arquivo que você editará com mais frequência é o main.cf. Esse arquivo

define os parâmetros que controlam o comportamento dos “daemons” do Postfix. Sua

sintaxe é bem simples obedecendo as seguintes formatação geral:

parâmetro = valor

Um parâmetro só pode ser especificado apenas uma vez no main.cf, caso

ocorra a duplicação o Postfix assumira a última ocorrência. Outra característica é

que a ordem dos parâmetros no main.cf não é relevante. Se um valor não é

especificado no main.cf o Postfix assume o valor padrão que está no código-fonte.


Abaixo um trecho do main.cf:

# mydestination = host.dominio.com.br, localhost.dominio.com.br,

localhost

O arquivo master.cf configura o “daemon” master do Postfix, e cada linha no

master.cf define um serviço que um programa executa. Por exemplo, o “daemon” que

recebe e processa as conexões SMTP, smptd, é um serviço. Abaixo segue um exemplo

do master.cf:

======================================================================

# service type private unpriv chroot wakeup maxproc command + args

# (yes) (yes) (yes) (never) (100)

#

======================================================================

# smtp inet n - - - 300 smtpd

# 628 inet n - - - - qmqpd

# pickup fifo n - - 60 1 pickup

# cleanup unix n - - - 0 cleanup

# qmgr fifo n - n 300 1 qmgr

# qmgr fifo n - - 300 1 oqmgr

Como no exemplo acima a sintaxe do master.cf é composta por:

• Service – nome do serviço declarado conforme o tipo de serviço;

• Type – especifica a tipo do serviço os tipo disponíveis são:

◦ inet – O serviço ira escutar em um soquete tcp/ip e está acessível a rede;

◦ unix – O serviço ira escutar em um soquete de domínio Unix e acessível

clientes apenas locais;

◦ fifo - O serviço ira escutar em FIFO(pipe) e acessível apenas clientes

locais;

• Private – Coloca o serviço restrito ao Postfix. Serviços do type “inet” não

podem ser privados. O padrão é sim(y);


• Unpriv – O serviço e executado com privilégios de root, ou como

proprietário do Postfix.O padrão é sim(y);

• Chroot – Coloca o serviço em CHROOT. O padrão é sim(y);

• WakeUp – Executa o serviço em um determinado período de tempo. Um

exemplo é o “daemon” flush que executa a cada 1000 segundos;

• Maxproc – O número máximo de processos que podem executar esse serviço

simultâneo;

• Command + args – Comando a ser executado mais os seus argumentos,

exemplo:

maildrop unix - n n - - pipe

flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}

4.1.7. Tabelas de Pesquisa

Algumas informações não podem ser convenientemente representadas nos

arquivos main.cf e marster.cf. O conceito do Postfix para tabelas de pesquisa permite

que as informações sejam armazenadas em arquivos externos, banco de dados

relacionais ou ainda em diretórios LDAP.

Para o Postfix, uma tabela de pesquisa é uma entidade abstrata que mapeia

uma “string”, a chave da pesquisa, para uma outra “string”, o resultado da pesquisa.

É como uma lista telefônica onde você pesquisa o nome e obtém o número

correspondente. Esse processo é realizado pelo comando postmap que constrói um

arquivo indexado. Para cada atualização realizada na tabela/arquivo é necessário

executar o postmap para que seja recriado o arquivo indexado. Não e necessário

recarregar o Postfix quando haver uma mudança na tabela.

Essas tabelas podem ser usada para diversos tipo de ações como:

• Restrição de acesso de clientes ao Postfix - Mapas de Acesso;

• Consulta a nomes e apelidos (alias);


• Contas e domínios virtuais.

Finalizando, o main.cf e master.cf são bem simples de configurar, basta apenas

declarar o parâmetro e o valor no caso main.cf e no master.cf o serviço e seus

argumentos. No momento da instalação do Postfix, o pacote já pré configura o

main.cf e master.cf com opções padrões. São eles quem definem o comportamento

dos “daemons” do Postfix.

4.1.8. Comandos de Administração do Postfix

O Postfix possui comandos para administração de filas de mensagens, criação

de apelidos, edição do main.cf , manipulação de logs etc. Abaixo a lista desses

comando e respectiva sua função:

Comando Função

postcat Permite leitura de uma mensagem enquanto estiver na fila de mensagens. Ex: postcat /var/spool/postfix/active/A/A44BD17D18

postalias Cria o arquivo base de apelidos. Ex: postalias /etc/postfix/aliases

postlog Escreve textos personalizados no log do PostfixEx: postlog -p info -t TITULO “TEXTO”

postmap Cria a base hash de arquivos de mapasEx: posmap /etc/postfix/check_access

postqueue Usado para controlar as filas de e-mail do PostfixEx: postqueue -i F2AF0111029

postsuper Tem as mesmas funções do posqueue, porém é utilizado por usuários privilégiados. Tem a capacidade de mover e excluir mensagens da fila.Ex: postsuper -d ALL

postconf Utilizado para manipulação e leitura de parâmetros no main.cfEx: postconf -d



4.2.1. Instalando e Configurando o Postfix

aptitude install postfix postfix-ldap postfix-pcre

Obs.: Quando o instalador do Postfix apresentar a tela de opções selecione

“Internet site” e logo após coloque o nome do servidor, ou seja, o FQDN,

exemplo: mailx.matrizX.com.br

Configurando o main.cf com o comando postconf:

postconf -e “smtpd_banner = Bem Vindo - \$myhostname”

#É uma saudação do Posfix ao receber uma conexão na porta 25. Você pode

colocar o nome da empresa, por exemplo.

#O mydestination é muito importante para o Postfix pois informa os

domínios que são considerados locais, isto é, quais domínios devem ter

suas mensagens entregues para as contas UNIX nessa máquina.

postconf -e “mynetworks = 127.0.0.1/32 192.168.1.0/24”

#Aqui você deve informa apenas as redes que poderão fazer relay no seu

servidor. Se especificar as redes incorretamente, seu servidor poderá

ser alvo de spammers.

postconf -e “inet_interfaces = all”

#Qual interface de rede o Postfix irá escutar para recepção e envio de

mensagens. Caso tenha múltiplas placas de rede e seja necessário que o

Postfix atenda em todas, basta apenas comentar esse parâmetro. Outra

alternativa para que o Postfix atenda em todas as interfaces é utilizar

a palavra-chave “all” para o valor do parâmetro. Caso seja necessário

que o Postfix atenda por duas interfaces, basta ainda colocar o valor

dos endereços IP correspondentes separados por espaço.

postconf -e “mydomain = matrizX.com.br”


#Define domínio de Internet do Postfix.

postconf -e “myorigin = matrizX.com.br”

#Geralmente possui o hostname da máquina, mas é utilizado para

qualificar endereços de e-mail que não possuem domínio como por

exemplo, mensagens enviadas através do comando “sendmail”.

postconf -e “myhostname = mailX.matrizX.com.br”

#Define o nome da máquina, ou seja, o host mais o domínio. É

importante que seja um domínio que seja resolvido pelo DNS.

Reiniciando o Postfix

/etc/init.d/postfix restart

4.2.2. Enviando o primeiro e-mail

O exemplo a seguir utiliza o comando telnet para realizar envio de um e-mail

de teste. Entretanto, antes desse teste, devemos criar nosso usuário chamado fulano:

1 #adduser fulano

2 → Coloque a senha 123

3

4 telnet localhost 25

5 HELO mail.matrizX.com.br

6 MAIL FROM: <[email protected]>

7 RCPT TO: <[email protected]>

8 DATA

9 From: Nome do Remetente <[email protected]>


10

11 To: Nome do Destinatário <[email protected]>

12 Subject: Teste de Comandos SMTP

13 E-mail teste - Comandos SMTP

14 .

15 QUIT

Verifique se a mensagem foi entregue em /var/mail/fulano

cat /var/mail/fulano

4.2.3. Outros parâmetros do main.cf

O arquivo main.cf possui mais de 500 parâmetros configuráveis, muitos deles

estão por padrão pré configurados, porém nem todos são contemplados no main.cf.

O core do Postfix já está pré configurado com valores padrões. Serão abordados

alguns parâmetros úteis:

always_bcc - Envia cópia de todas as mensagens para um destinatário

defer_trasports - Contém nomes dos transportes cujas entregas devem

ser temporariamente adiadas. Isso permite suspender entregas locais

de mensagens se o sistema de arquivos para os diretórios iniciais não

estiver disponíveis.

delay_warning_time – Por padrão o Postfix não envia um aviso se a

mensagem está demorando para ser entregue, caso deseje isso coloque o

tempo desejado nesse parâmetro, exemplo “4h”.

mailbox_size_limit – Controla o tamanho máximo de uma caixa de

correio local ou o tamanho máximo de uma mensagem ao utilizar caixa

em formato “maildir”.

maximal_queue_life_time – Especifica quanto tempo o Postfix tentara

novamente a entrega das mensagens que falharam antes de serem

retornadas ao remetente. Padrão e 5 dias.

message_size_limit – Tamanho máximo de uma mensagem


4.2.4. Utilizando a ferramenta Postal para envio de e-mails

Para simularmos um pequeno tráfego de e-mail, será utilizada a ferramenta

Postal. Discutiremos sobre a ferramenta Postal mais adiante.

# aptitude install postal

# echo “[email protected]” > /home/lista-email.txt

# postal -t 1 -m 5 -c 5 -r 5 -a localhost /home/lista-email.txt

# tail -f /var/spool/mail/fulano

4.2.5. Criando alias para usuários locais

O exemplo a seguir cria um apelido (alias) para o usuário fulano:

# postconf -n | grep alias

# echo “geral: fulano” >> /etc/aliases

# postalias /etc/aliases

4.2.6. Criando mapas de acessos com o postmap

Os mapas de acessos(tabelas de pesquisas) são largamente utilizados em

conjunto com parâmetros de restrição do Postfix. Se você deseja bloquear conexão de

clientes maliciosos, os mapas de acesso podem contribuir muito com essa tarefa. Por

exemplo:

# printf “192.168.1.x\tREJECT Bloqueado” > /etc/postfix/client_access

# postmap /etc/postfix/client_access

# ls /etc/postfix

# postconf -e “smtpd_client_restrictions = check_client_access

hash:/etc/postfix/client_access”

# invoke-rc.d postfix reload


4.2.7. Utilizando os comandos postcat, postqueue e postsuper

Para que seja possível realizar a leitura e a manipulação das mensagens na fila,

vamos gerar tráfego de e-mail com a ferramenta postal:

# postal -t 5 -m 10 -c 5 -r 120 -a localhost /home/lista-email.txt

Verificando o status da fila

# postqueue -p

Lendo a mensagem com o postcat

# postcat /var/spool/postfix/active/id_da_mensagem

removendo mensagens da fila

# postsuper -d ALL


4.3. Exercícios

1. Qual a função dos arquivos main.cf e master.cf?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

2. Qual o parâmetro é responsável pelos domínios que o postfix irá responder?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

3. Estou tentando mensagem de 20 MB mas o meu servidor não está

permitindo. O que pode estar ocorrendo?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________


4. A empresa Domínio S/A tem uma filial em Anápolis-GO. Essa filial está

conectada à matriz em São Paulo-SP. O servidor já possui todas a contas de e-

mails de cada usuário da filial, porém, os usuários estão reclamando que não

conseguem enviar e-mails e estão relatando a seguinte mensagem de erro:

“554 – Relay Access Denied “. O que pode estar ocorrendo?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

5. Qual a diferença entre os comandos postmap e o postalias?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

6. Qual a diferença entre os comandos postqueue e o postsuper?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________


7. Qual a diferença entre os comandos “postconf -d” e “postconf -n”? Explique.

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

8. Após executado o comando postmap, é necessário recarregar o Postfix?

Explique.

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

Capítulo 5 Gerenciamento de Filas no Postfix - 68

Capítulo 5

Gerenciamento de Filas no Postfix


5.1. Introdução

O Postfix possui diferentes filas para tratamento do sistema de correio. O

“daemon” que controla as filas do Postfix é QMGR(Queue Manager), onde, em

segundo plano, gerencia as filas active, bounce, corrupt, deferred, e hold.

As filas estão localizadas por padrão em “/var/spool/postfix” e cada uma possui

seu próprio diretório. As filas mais ativas nesse processo são: active e incoming.

Fila Função

Active Esta é a fila de e-mails que foram abertos pelo gerenciador da fila para entregas. Essa fila tem um número limite para entrada de mensagens. qmgr_message_active_limit (default 20000)

Corrupt Os arquivos das filas que não conseguem ser lidos ou que estão danificados são movidos para esta fila para uma inspeção.

Deferred Esta é a fila de mensagens que não conseguiram ser entregues na primeira tentativa. O gerenciador da fila vai seguir as configurações do main.cf para novas tentativas de entregas. Por padrão ele vai dobrando o tempo de entrega a cada tentativa.

Incoming Esta é a fila de e-mails que estão entrando a partir da rede, repassados pelo maildrop.

Hold Mensagens que são colocadas em espera pelo administrador vão para esta fila até que alguém especifique que ela deva ser liberada.

Status da Entrega Função

Bounce Informação sobre os motivos da mensagem ter recebido um bounce (mensagem de erro).

Defer Informação sobre os motivos da mensagem estar com o envio atrasado.

Trace Informação sobre requisições com o comando sendmail -v ou sendmail -bv do MTA postfix.

O “daemon” QMGR possui parâmetros configuráveis em main.cf, vejamos os

mais usuais:

Parâmetro Descrição

qmgr_clog_warn_time (300) Intervalo minimo de advertências

qmgr_message_active_limit (20000) Número máximo de mensagens na fila

qmgr_message_recipient_limit (20000) Número máximo de destinatários realizada em memória

qmgr_message_recipient_minimum (10) Número mínimo de destinatários em memória

maximal_queue_lifetime O tempo máximo de uma mensagem na fila antes que seja devolvida como “undeliverable”

queue_directory Diretório onde estão as filas do Posfix

http://www.postfix.org/postconf.5.html#qmgr_message_active_limit


O Postfix também possui ferramentas para gerenciamento de filas.

Comando/Parâmetro Função

postqueue -p Verificar como está a fila

postqueue -f Para dar um “flush” na fila e enviar mensagens que estão aguardando (deferred)

postqueue -i id_da_mensagem Para iniciar a entrega imediata de uma mensagem na fila deferred

postqueue -s dominio.com Para iniciar a entrega imediata de mensagens na fila para um domínio especifico

postsuper -h id_fila Colocando mensagem em HOLD (espera).

postsuper -H id_fila Libera mensagem colocada em HOLD

postsuper -d ALL Remove mensagem das filas

postsuper -p Faz um “purge” na nos arquivos temporários da fila

postsuper -s Verifica a estrutura das filas e repara a fila caso exista algum problema.

postsuper -r id_fila Recoloca a mensagem na fila

qshape nome_fila Ferramenta de análise estatística do Postfix

Postcat -d id_mensagem Realiza leitura da mensagem enquanto na fila


5.2. Pratica dirigida

Verificar o estado das filas

# postqueue -p

Verificando o estado das filas de um domínio especifico

# postqueue -p | grep matrizX.com.br

Reprocessando as mensagens

# postsuper -r ALL

Removendo mensagens

# postsuper -d 45ADF5

Lendo uma mensagem

# postcat -q 45ADF5

Verificando a estatística de filas com o “qshape“:

# qshape

T 5 10 20 40 80 160 320 640 1280 1280+

TOTAL 655 60 111 0 43 0 7 6 120 150 158

matriz.com.br 151 40 111 0 0 0 0 0 0 0 0

dominioY.com.br 109 0 0 0 0 0 0 0 0 50 59

dominioZ.com.br 55 0 0 0 0 0 0 0 55 0 0

dominioW.com.br 35 0 0 0 0 0 0 0 0 14 21

dominioK.com.br 31 0 0 0 4 0 0 0 27 0 0

Estatísticas da fila active com qshape:

# qshape active


5.3. Exercícios

1. Qual a diferença entre os comando postqueue e postsuper?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

2. Quais os motivos levam uma mensagem ir para fila deferred?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

3. Muitas mensagens não entregues(erro, destinatário não encontrado, etc)

estão ficando na fila, como posso melhorar esse cenário?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________


4. Cite fatores que contribuem para o crescimento das filas no Postfix.

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

Capítulo 6 Entendendo Restrições SMTP no Postfix - 74

Capítulo 6

Entendendo Restrições SMTP no

Postfix


6.1. Introdução

O Postfix fornece alguns métodos que podem ser utilizados para ajudá-lo no

combate a SPAM.

• Restrições SMTP

• Listas de bloqueio do DNS

• Correspondência às expressões regulares

Adicionalmente o Postfix fornece os métodos a seguir para filtragem de spam:

6.1.1. Filtragem de conteúdo depois do enfileiramento

O Postfix aceita a mensagem e entrega para filtragem. A desvantagem é que o

Postfix sempre aceitara a mensagem.

6.1.2. Filtragem de conteúdo antes do enfileiramento

Filtros de conteúdo antes do enfileiramento recebem a mensagem durante a

sessão SMTP e pode escolher rejeitá-las. A desvantagem é que a filtragem de

conteúdo sempre é exigida a cada sessão SMTP. Esse tipo de conteúdo não é

escalonável e não adequado para sites de alto tráfego.

6.1.3. Delegação de filtragem para programas externos

Se as restrições não forem suficientemente boas, você poderá gerar seu próprio

mecanismo de filtragem.

O Postfix tem uma notação simples, porém, bem expressiva para definição das

regras que serão aplicadas às mensagens que chegam via SMTP. O Postfix define

alguns parâmetros que contêm listas de restrições. Cada lista de restrição pode

conter zero ou mais restrições e cada restrição pode ou não retornar algo quando

avaliada. Como em alguns outros locais no Postfix, o principio “primeira

correspondência vence” também prevalece aqui. Isso significa que as restrições são

avaliadas na ordem que elas são especificadas, e a primeira restrição que retornar

algo termina a avaliação da lista de restrição atual. As listas são avaliadas durante a


sessão SMTP. A tabela abaixo mostra as listas de restrições que o Postfix utiliza e

mostra a fase dentro de uma sessão SMTP.

Parâmetros Ponto de avaliação

smtpd_client_restrictions Diretamente na conexão, ou seja, faz testes no IP do cliente.

smtpd_helo_restrictions Depois que o cliente enviou o comando HELO ou o EHLO.

smtpd_sender_restrictions Depois que o cliente enviou o endereço do remetente através do comando MAIL FROM.

smtpd_recipient_restrictions Depois que o cliente enviou o endereço do destinatário em RCPT TO

smtpd_data_restrictions Depois que o cliente enviou o comando DATA para repassar o conteúdo da mensagem.

smtpd_end_of_data_restrictions Depois que o cliente enviou a mensagem completa finalizando com o “.”.

Cada restrição tem um contexto isolado onde os testes são feitos na ordem

especificada, e cada teste pode retornar 3 status: OK, REJECT e DUNNO. OK e

REJECT são ações finais dentro de uma restrição. O status OK faz com que os

próximos testes desta restrição não sejam processados. O REJECT faz o bloqueio da

conexão, informando a restrição que não foi atendida. O DUNNO apenas faz com que

não seja bloqueado neste teste, e passe para o próximo teste.

Exemplo:

smtpd_client_restrictions = permit_mynetworks,

permit_sasl_authenticated,

check_client_access hash:/etc/postfix/client_access,

reject_unknown_client_hostname

Digamos que eu conecte no servidor por um provedor internet que não me dá

IP reverso, e meu IP é 192.168.0.1. O Postfix vai agir da seguinte forma:

• O IP 192.168.0.1 está em permit_mynetworks? Não, então -> DUNNO

• O IP 192.168.0.1 se autenticou? Não, então = DUNNO

• O IP 192.168.0.1 está em client_access Não, então = DUNNO

• O IP 192.168.0.1 possui DNS reverso? Não, então = REJECT

Se meu IP estivesse em client_access, no mynetworks, ou eu tivesse me

autenticado, estes testes retornariam OK e eu não seria bloqueado pelo teste de IP

reverso.


O parâmetro “smtpd_delay_reject” tem seu valor default YES, isso significa que

todas as rejeições serão adiadas até ocorrer um RCPT TO. A razão disso é que alguns

clientes de e-mail não gostam de ser rejeitados antes do RCPT TO, assim eles se

desconectarão e tentarão novamente.

Um mal-entendido comum é acreditar que, somente restrições no endereço de

destinatário podem ser colocados em “smtpd_recipient_restrictions”. O Nome da lista

de restrições só informa em qual fase na sessão SMTP as restrições listadas serão

aplicadas, mas, em razão do “smtpd_delay_restrictions”, isso não é verdadeiro. Por

padrão o Postfix não tem restrições para o cliente, HELO ou remetente.

Os parâmetros citados acima tratam momento da sessão SMTP, dentro deles

existem as restrições que serão aplicadas. O Postfix possui mais de 50 restrições

SMTP. Vamos analisar as mais usuais:

Restrições Descrição

permit_mynetworks Permitir se o cliente conectado estive listado em mynetworks

permit_sasl_autenticated Permitir se o cliente que está se conectado autenticou-se

reject Rejeitar incondicionalmente

reject_invalid_hostname Rejeitar se o hostname for inválido.

reject_non_fqdn_hostname Rejeitar se o hostname HELO/EHLO dado pelo cliente não for um nome de domínio completamente qualificado

reject_non_fqdn_recipient Rejeitar se a parte do domínio do endereço do destinatário não for um nome de domínio completamente qualificado

reject_non_fqdn_sender Rejeitar se a parte do domínio do endereço do remetente não for um nome de domínio completamente qualificado

reject_unauth_destination Rejeitar a solicitação a menos que o domínio do destinatário seja um dos domínios que o servidor Postfix hospeda

reject_unknown_recipient_domain Rejeitar se a parte domínio do endereço do destinatário não tiver nenhum registros A, MX no DNS

reject_unknown_sender_domain Rejeitar se a parte domínio do endereço do remetente não tiver nenhum registros A, MX no DNS

reject_unknown_cliente_hostname Rejeitar se o não tiver nenhum registros A, MX no DNS – Verifica reverso

reject_unlisted_recipient Rejeitar se o destinatário não for um endereço de e-mail válido pertencente ao Postfix. Por padrão essa restrição é avaliada implicitamente ao final de smtpd_recipient_restrictions.

reject_unlisted_sender Rejeitar se a origem não for um endereço de e-mail válido, ou seja, endereços de remetente não pertence ao Postfix.

permit Permitir incondicionalmente

warn_if_reject Gera apenas em caso de rejeição mas não rejeita a mensagem. Útil quando queremos testar um regra.


6.1.4. Restrições com Mapas de Acesso

O Postfix define algumas restrições pesquisando informações em mapas de

acesso.

Por exemplo, a restrição “check_client_access” pequisa o endereço IP e o

hostname do cliente em uma tabela de pesquisa, permitindo, por exemplo, banir

clientes que reconhecidamente enviam spam. Junto com o nome dessa restrição você

também declara o tipo e o nome da tabela de pesquisa

smtpd_client_restrictions =

check_client_access hash:/etc/postfix/client_access

Segue, abaixo, as restrições mais usuais:

Nome da Restrição Chave de pesquisa

check_client_access Endereço IP e hostname do cliente

check_sender_access Endereço do remetente da mensagem

check_recipient_access Endereço do destinatário da mensagem

check_helo_access O hostname HELO/EHLO

Os resultados a seguir são reconhecidos para um determinada chave de

pesquisa.

Resultado Descrição

OK Permitir a solicitação

REJECT[texto opcional] Rejeitar a solicitação com um código de erro e com uma mensagem de erro

DISCARD[texto opcional] Se a mensagem for aceita, ela será descartada e não será entregue

HOLD[texto opcional] Coloca a mensagem na fila de espera

WARN [texto opcional] Coloca mensagem de alerta no arquivo de log

Vejamos um exemplo do arquivo client_access:

# Bloqueio as redes RFC 1918

10 REJECT RFC 1918 endereço não permitido

192.168 REJECT RFC 1918 endereço não permitido

smtp.spammer.com REJECT Você é um spammer


6.1.5. Restrições de cabeçalho e corpo da mensagem

Algumas mensagens não podem ser examinadas sem a analise de seu conteúdo. O

Postfix, fornece algumas ferramentas não muito sofisticadas, porém muito úteis ,

para esse propósito. As verificações de cabeçalho e corpo da mensagem podem

ajudar a solucionar os seguintes problemas:

• Reagindo a mensagem que contém anexos com nomes de aquivos

proibidos;

• Detendo rapidamente grandes epidemias de vírus;

• Registro em log de personalização de certos campos de cabeçalhos;

• Removendo os cabeçalhos de algumas mensagens.

Os parâmetros “body_checks”, “header_checks”, “mime_header_checks” e

“nested_header_checks” são responsáveis por esse trabalho e esses recursos podem

estar associados a tabelas de pequisas aliadas a expressões regulares. Vejamos o

exemplo:

Parâmetro do main.cf:

header_checks = regexp:/etc/postfix/header_checks

O conteúdo do arquivo header_checks

/.*(file)?name=.*\.(bat|exe|src|scr|pif|chm|hta|vbs)/ REJECT ATTACH

TAG: EXEC.

/*[vV][iI][aA][gG][rR][aA]? REJECT SPAM TAG: Viagra

Parâmetro do main.cf:

body_checks = regexp:/etc/postfix/body_checks


O conteúdo do arquivo body_checks

((https?|ftp):(//)+[\w\d:#@%/;$()~_?\+-=\\\.&]*) REJECT Urls não

permitidas

/^(Return-Path|From):.*<.*_.*_.*_.*@.*/ REJECT SPAM TAG:

_.

/^Subject:.*([Rr][Ee](:)?( )?\[[0-9]{1,2}\](:)?)/ REJECT SPAM TAG:

re[].

/^Subject:.*([oO0][eE][mM]).*/ REJECT SPAM TAG:

OEM.

6.1.6. Restrições com RBLs

Desde 1997, DNS é utilizado contra spam. O método, DNS-based Blackhole

List(DNSBL) ou Real-time Blackhole List(RBL), também como lista negra, utiliza o

DNS para publicar informações sobre os domínio de alguns clientes ou remetentes.

Quando um servidor de correio como o seu for contatado por um cliente, seu servidor

poderá combinar o endereço IP desse cliente ou o endereço de remetente dado com o

domínio de um ou mais DNSBL e realizar uma pequisa de DNS. Se o endereço for

listado pela DNSBL, a pesquisa será bem sucedida e seu servidor poderá rejeitar a

mensagem.

O Postfix suporta três tipos de pesquisas DNSBL: endereço do cliente,

hostname do cliente e domínio do remetente. Cada tipo de pesquisa tem uma

restrição própria e todos exigem que você especifique o nome do domínio DNSBL

depois do nome da restrição

Tipo de DNSBL Sintax Descrição

Endereço do cliente host reject_rbl_client_rbl_domain O endereço IP do cliente que está se contatando é pesquisado.

Hostname do Cliente reject_rhsbl_client_rbl_domain O hostname do cliente que está se conectando é pesquisado

Domínio do endereço do remente

reject_rhsbl_sender_rbl_domain O domínio de um dado endereço de remetente é pequisado


Exemplo de uso:

smtpd_recipient_restrictions=

permit_mynetworks,reject_unauth_destination, reject_rbl_client

relay.ordb.org, reject_rhsbl_sender dns.rfc-ignorant.org

Listas DNSBL úteis:

relays.ordb.org, list.dnsbl.org, sbl.spamhaus.org, xbl.spamhaus.org, sbl-

xbl.spamhaus.org

6.2. Prática Dirigida

Vamos agora aplicar as regras apresentadas:

6.2.1. Restrições por IP e IP Reverso

A regra de restrição abaixo esta associada na 1ª etapa da sessão SMTP, ou seja,

no momento da conexão do cliente. Edite o arquivo main.cf:


permit_mynetworks,


reject_unknown_client_hostname,

check_client_access hash:/etc/postfix/black_list,

reject_rbl_client zen.spamhaus.org,

reject_rbl_client bl.spamcop.net

Conteúdo do arquivo /etc/postfix/black_list

192.168.1.10 REJECT

192.168.1.11 REJECT

Executar o postmap para criar os mapas do arquivo

# postmap /etc/postfix/black_list


Vamos entendê-la:

• permit_mynetworks – Permitir conexão das redes declaradas no

parâmetro “$mynetworks”

• permit_sasl_authenticated - Permitir todos cliente autenticados (SMTP

autenticado).

• check_client_access – Permitir o conexão dos clientes que estão nos

mapas de acesso conforme regras estabelecidas nos mapas

• reject_unknown_client_hostname – Rejeitar clientes com hostnames

desconhecidos

• reject_rbl_client – Rejeitar clientes que estejam cadastrados em RBLS

Como exemplo de teste, coloque o IP de qualquer colega no arquivo

client_blacklist e gere novamente o mapa com o comando postmap. Depois peça ao

colega para tentar conectar em seu servidor com o comando “telnet” para realizar o

teste e veja se ele é rejeitado.

6.2.2. Restrições HELO/EHLO

Está próxima regra é similar a anterior porém acontece no momento após a

conexão do cliente na 2ª etapa da sessão SMTP no comando HELO. Edite o arquivo

main.cf:

smtpd_helo_required = yes

smtpd_helo_restrictions =

check_helo_access hash:/etc/postfix/helo_blacklist,

permit_mynetworks,


reject_non_fqdn_helo_hostname,

reject_invalid_helo_hostname,

reject_unknown_helo_hostname


Entendendo as Regras:

• smtpd_helo_required – Obriga o cliente a se apresentar informando o seu

FQDN

• As demais regras são idênticas a do smtpd_client_restrictions exceto

reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname e

reject_unknown_helo_hostname.

Conteúdo do arquivo /etc/postfix/helo_blacklist

192.168.1.10 REJECT

192.168.1.11 REJECT

Executar o postmap para criar os mapas do arquivo

# postmap /etc/postfix/helo_blacklist

6.2.3. Restrições Remetente (MAIL FROM) .

Está próxima regra trata a 3º etapa da sessão SMTP, no comando MAIL FROM,

ou seja, na apresentação do remetente. Edite o arquivo main.cf:

smtpd_sender_restrictions =

reject_non_fqdn_sender,

reject_unknown_sender_domain,

reject_authenticated_sender_login_mismatch,


reject_unlisted_sender

Nesta regra temos dois parâmetros que merecem destaque:

reject_authenticated_sender_login_mismatch – Esse parâmetro funciona assim: o

usuário se autenticou no servidor SMTP com o login [email protected],

porém no momento de anunciar o MAIL FROM ele coloca [email protected],

ou seja, ele anuncia outro remetente e não o que foi anunciado no login. Então, essa

regra negará o envio do e-mail por não apresentar coerência entre o usuário

autenticado e remetente anunciado.


OBS: para que estas duas regras citadas acima funcionem é necessário o

uso da autenticação que será abordada mais adiante nessa apostila

reject_unlisted_sender – Esse parâmetro rejeita remetentes que não estão na lista

de domínios válidos em seu servidor, ou seja, presente no parâmetro $mydestination

ou em outras bases como LDAP, mapas etc. Isso impede ataques de vírus e worms na

sua rede interna. Só deve ser usado em casos específicos

6.2.4. Restrições Destinatário (RCPT TO)

Esta regra trata a 4ª etapa da sessão SMTP que é referente ao destinatário

smtpd_recipient_restrictions =

reject_non_fqdn_recipient,

reject_unknown_recipient_domain,

reject_unlisted_recipient,


reject_unauth_destination

O smtpd_recipient_restrictions também é similar ao smtpd_sender_restrictions.

Você também pode acrescentar outros parâmetros nessa regra como blacklists e

RBLs.

6.2.5. Restrições após o comando DATA

Essa regra trata da 5º etapa da sessão SMTP, no comando DATA:

smtpd_data_restrictions =

reject_unauth_pipelining,

reject_multi_recipient_bounce

# reject_unauth_pipelining - bloqueia o cliente caso ele tente acelerar

o envio de mensagens sem aguardar as respostas do servidor SMTP.

#reject_multi_recipient_bounce - Rejeita múltiplos destinatários e

destinatários nulos isso dentro do envelopamento.


6.2.6. Restrições Cabeçalhos da Mensagem

Nesta seção as regras de restrições se aplicam já nas mensagens envelopadas.

Nesta regra iremos bloquear o cabeçalho e corpo da mensagem veja a figura abaixo:

A regra abaixo é utilizada para tratar restrições de cabeçalhos na mensagem.

Se você tem conhecimento em Expressões Regulares pode criar filtros

personalizados conforme a sua necessidade. Edite o main.cf

header_checks = regexp:/etc/postfix/header_checks

Conteúdo do arquivo header_checks:

/.*(file)?name=.*\.(bat|exe|src|scr|pif|chm|hta|vbs)/ REJECT ATTACH

TAG: EXEC.

/^(Return-Path|From):.*<.*_.*_.*_.*@.*/ REJECT SPAM TAG:

_.

/^Subject:.*([Rr][Ee](:)?( )?\[[0-9]{1,2}\](:)?)/ REJECT SPAM TAG:

re[].

/^Subject:.*([oO0][eE][mM]).*/ REJECT SPAM TAG:

OEM.


6.2.7. Restrições do Corpo da Mensagem

A regra abaixo é utilizada para tratar restrições de corpo na mensagem . Edite

o main.cf

body_checks = regexp:/etc/postfix/body_checks

Conteúdo do arquivo body_checks:

/(http|https|ftp):\/\/.*\/.*\.(bat|pif|scr|[eE][xX][eE]).*(\s|\")/

REJECT PHISHING

A expressão regular acima bloqueia ataques de Phishing ou seja, url's

apontando para possíveis executáveis.

6.2.8. Desabilitando comando VRFY

Este comando solicita ao Receptor-SMTP a confirmação de que o argumento

identifica um usuário conhecido. Se for identificado é retornado o nome completo do

usuário (se este possuir) e seu mailbox completo. Essa parâmetro é importante estar

desativado isso impedirá que spammers tentem coletar endereços de e-mail em seu

servidor. Edite o main.cf

disable_vrfy_command = yes

6.2.9. Restrições condicionais

As restrições condicionais permitem ao administrador criar regras

personalizadas e é comum o seu uso para tratamento de “maillist” e bloqueio de

spammers.

Nesta configuração vamos fazer o necessário para proteger uma lista,

determinando quem pode enviar para a mesma. Quem não estiver permitido será

negado.

Criar os usuários teste1, teste2 e teste3

# useradd teste1

# useradd teste2

# useradd teste3


Criar o alias lista em /etc/aliases com o seguinte conteúdo:

lista: teste1, teste2, teste3, fulano

Execute o postalias

postalias /etc/aliases

Criar o arquivo minha_lista em /etc/postfix com o seguinte conteúdo:

lista@matriz X .com.br protege_lista

Criar o arquivo users_liberados em /etc/postfix com o seguinte conteúdo:

fulano@matriz X .com.br OK

Execute o postmap

postmap /etc/postfix/minha_lista

postmap /etc/postfix/users_liberados

Edite o main.cf

smtpd_restriction_classes = protege_lista

protege_lista = check_sender_access hash:/etc/postfix/users_liberados,

reject

# Este parâmetro deve ser adicionado ao “smtpd_recipient_restrictions”

# existente no main.cf

smtpd_recipient_restrictions = check_recipient_access

hash:/etc/postfix/minha_lista

A regra que fizemos irá bloquear usuários não listados em

/etc/postfix/users_liberados que tentarem enviar mensagens para a lista que esta

em /etc/postfix/minha_lista








6.2.10. Restrições por tamanho da mensagem

message_size_limit = 20480000

6.2.11. Restrições – Conformidade com RFC

Esse parâmetro força o cliente de e-mail a envelopar o remetente e os

destinatários conforme a RFC determina.

strict_rfc821_envelopes = yes


6.3. Exercícios

1. Quais as vantagens e desvantagens da filtragem de conteúdo depois do

enfileiramento?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

2. Explique porque a filtragem de conteúdo antes do enfileiramento não é

escalonável?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

3. Qual o função do parâmetro smtpd_delay_reject?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________


4. Observe o seguinte parâmetro:


reject_rbl_client bl.spamcop.net ,

reject_rbl_client dnsbl.njabl.org ,

permit_mynetworks,


check_client_access hash:/etc/postfix/client_whitelist,

check_client_access hash:/etc/postfix/client_blacklist,

reject_unknown_client_hostname

Alguns clientes estão reclamando da demora no envio de e-mails.

Identifique o motivo.

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

5. Qual os tipos de DNSBLs suportadas pelo Postfix?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________


6.4. Laboratório

1. Crie uma regra que bloqueie a palava “viagra”.

2. Crie uma regra de DNSBL com exceção para o IP 192.168.X.Y.

3. Crie uma regra que bloquei arquivos com extensão ZIP

4. Para realizar os testes utilize as ferramentas telnet e postal

Capítulo 7 TroubleshootIdentificando e Resolvendo Problemas no Postfix - 92

Capítulo 7

Troubleshoot

Identificando e Resolvendo Problemas

no Postfix


7.1. Introdução

Um elemento-chave na solução de problemas do Postfix é ser capaz de ler e

interpretar as mensagens de log que o Postfix gera. Como essas mensagens são

arquivos de texto simples com uma mensagem de log por linha, não é necessário

nenhum programa especial para leitura. Postfix registra todas as operações

realizadas, incluindo as bem ou mal sucedidas. Como muitos outros serviços dentro

de um ambiente Unix/Linux, o Postfix utiliza o sistema syslog para registrar suas

mensagens de log.

Os aquivos de log do Postfix ficam, por padrão, no diretório /var/log/mail. O

formato de cada mensagem de log tem o seguinte formato:

O Postfix fornece uma quantidade razoável de informação valiosa por meio de

seus logs. Portanto, tenha o hábito de analisá-los com frequência. Atente-se

especialmente aos erros e aos avisos de alerta. Utilitários Unix como o

grep/egrep/fgrep, awk e perl são ferramentas valiosas para manipular, filtrar e

extrair informações precisas de seus arquivos de log. Por exemplo, você pode

executar o seguinte comando regularmente para verificar a existência de quaisquer

entradas de log que possam identificar problemas.

egrep '(reject|warning|error|fatal|panic):' /var/log/mail.log

Você pode encontrar mensagens reportadas pelo “daemon” master indicando

uma falha que ocorreu e o respectivo PID do processo correlacionado à falha,

conforme mostrado no quadro a seguir:


postfix/master[3158]: warning:

process /usr/libexec/postfix/smtpd pid 3163

exit status 1

postfix/master[3158]: warning:

/usr/libexec/postfix/smtpd:

bad command startup -- throttling

Identificado o PID do processo, localize no arquivo “mail.log” qual o motivo do

problema por meio de uma pesquisa utilizando, nesse exemplo, o grep e usando como

chave de busca o PID do processo encontrado na verificação anterior:

grep 3136 /var/log/maillog

postfix/smtpd[3163]: fatal: open database /etc/postfix/aliases.db:

No such file or directory

Nesse caso, conforme indica a mensagem apresentada, o problema está

relacionado com a ausência do arquivo “/etc/postfix/aliases.db”. O próximo passo,

portanto, para certificar-se disso é verificar a presença (ou ausência, provavelmente)

desse arquivo no servidor de e-mails.

Se quiser saber o destino e todo o processamento realizado em uma

determinada mensagem, o log tem a resposta. Quando um e-mail é recebido pelo

Postfix ele imediatamente é associado a um ID de fila. Você, portanto, pode rastreá-

lo completamente ao olhar para todas as entradas de log que possuem esse ID. Por

exemplo, quando um cliente se conecta ao seu servidor para entregar uma

mensagem, o servidor registra a entrada apresentada no quadro a seguir:

postfix/smtpd[1677]: connect from mail.example.com[192.168.100.45]

postfix/smtpd[1677]: 9634B16F7F7:

client=mail.example.com[192.168.100.45]

A primeira linha registra a conexão inicial. A próxima linha mostra o ID da fila

que foi atribuído a esta mensagem: no caso, “9634B16F7F7”. Quando outros

componentes Postfix manipularem a mensagem, eles farão referência ao mesmo ID,

de acordo como mostrado no quadro seguinte:


postfix/smtpd[1434]: 4F9D116F7F7: client=localhost[127.0.0.1]

postfix/cleanup[1436]: 4F9D116F7F7:

message-id=<[email protected]>

postfix/qmgr[1431]: 4F9D116F7F7: from=<[email protected]>,

size=344, nrcpt=1 (queue active)

postfix/smtp[1438]: 4F9D116F7F7: to=<[email protected]>,

relay=mail.example.com[216.150.150.131], delay=11,

status=sent (250 Ok: queued as 51DCA20DD70)

Se a mensagem foi entregue com sucesso, o servidor remoto informa o ID de

fila da sua mensagem. Isso é útil caso seja necessário contatar o postmaster do

servidor remoto.

Além desses erros, é importante ressaltar a análise dos recursos que o Postfix

utiliza para determinar possíveis erros de entrega e recepção de mensagens ou de

problemas com o próprio Postfix, como por exemplo:

• Problema de inicialização: permissão de arquivos, dependência ou

inexistência de bibliotecas compartilhadas;

• Problemas de DNS: DNS inexistente, cache não atualizado ou mal

configurado;

• Problemas de rede: gateway, rotas e firewall;

• Erros de sintaxe nos aquivos main.cf e master.cf;

• Problema com sistema de arquivos: espaço em disco esgotado ou

corrompimento do sistema de arquivos.

Outra alternativa consiste em utilizar uma ferramenta para análise de logs

como o pacote “pflogsumm”, presente na maioria das distribuições GNU/Linux. No

caso das distribuições como Debian GNU/Linux ou o Ubuntu Linux, é possível instalá-

lo simplesmente utilizando o comando a seguir:


# aptitude -y install pflogsumm

# pflogsumm.pl -d today /var/log/mail.log

Mais informações a respeito do pflogsumm podem ser obtidas nas próprias man

pages inclusas no pacote.


7.2.1. Aumentando o nível de log e debugando o Postfix

Se você tiver um problema com um determinado domínio, mas não encontrar

erros no seu registro, você pode aumentar o nível de log para o problema com

parâmetro debug_peer_list. Com isso, o Postfix irá gravar informações adicionais,

como toda a transação entre o cliente e o servidor. Esse parâmetro é definido por

uma lista de domínios para os quais o Postfix deve aumentar o nível de registro. O

quadro a seguir apresenta um exemplo da utilização desses dois recursos. Edite o

main.cf:

debug_peer_list = matrizX.com.br

debug_peer_level = 2

Você também pode obter logs mais detalhados adicionando o parâmetro “-v”

nos daemons do Postfix editando o arquivo /etc/postfix/master.cf, conforme

apresentado no exemplo a seguir:

smtp unix - - n - - smtp -v -v

Outra alternativa consiste em habilitar o modo Debug. Para isso,

primeiramente é necessário editar o arquivo /etc/postfix/master.cf para adicionar o

parâmetro “-D” ao “daemon” smtpd:

smtp unix - - n - - smtpd -D

Em seguida, é necessário editar o arquivo /etc/postfix/main.cf para habilitar a

utilização da ferramenta strace, de acordo como exibido no quadro abaixo:


debugger_command =

PATH=/bin:/usr/bin:/usr/local/bin;

(strace -p $process_id 2>&1 | logger -p mail.info) & sleep 5

Por fim, é necessário instalar o strace e reiniciar o Postfix por meio do script

/etc/init.d/postfix:

aptitude install strace


7.2.2. Debugando o Postfix com a ferramenta sendmail

A ferramenta sendmail do Postfix, pode produzir relatórios para fins de

depuração. Estes relatórios mostram dados como: emissor/receptor, reescrita de

endereços, alias e encaminhamento, além de apresentar informações sobre a entrega

de mensagens nas caixas postais. O sendmail possui dois métodos de testes,

apresentados a seguir:

What-if: relata o que iria acontecer, mas, na verdade, não entrega, de fato, o e-

mail.

# sendmail -bv [email protected]

What happened: entrega o e-mail e relata o sucesso e/ou falha, incluindo as

respostas de servidores SMTP remotos.

# sendmail -v [email protected]

Os relatórios de ambos os comandos, irão para a caixa de e-mail do usuário que

executou o comando. Para verificar o resultado, acesse a caixa de e-mail do usuário

com o comando mail ou “cat /var/mail/usuario”, tomando o cuidado de trocar o

parâmetro do comando cat pelo caminho do arquivo que contém a “mailbox” do

usuário.


7.3. Exercícios

1. Qual o diretório dos logs do Postfix?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

2. Para que serve o ID de fila no Postfix?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

3. Para que serve o ID de mensagem?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________


4.Observe o seguinte trecho do log:

Apr 13 11:16:12 srv postfix/pickup[18919]: 324285506B: uid=0 from=<root>

Apr 13 11:16:12 srv postfix/cleanup[18962]: 324285506B: message-

id=<[email protected]>

Apr 13 11:16:12 srv postfix/qmgr[18921]: 324285506B:

from=<[email protected]>, size=290, nrcpt=1 (queue active)

Apr 13 11:16:15 srv postfix/smtp[18964]: 324285506B: host

g.mx.mail.yahoo.com[209.191.118.103] refused to talk to me: 421 Message from

(200.198.212.34) temporarily deferred - 4.16.50. Please refer to

http://help.yahoo.com/help/us/mail/defer/defer-06.html

Apr 13 11:16:16 srv postfix/smtp[18964]: 324285506B: lost connection with

a.mx.mail.yahoo.com[67.195.168.31] while sending RCPT TO

Apr 13 11:16:17 srv postfix/smtp[18964]: 324285506B: to=<[email protected]>,

relay=b.mx.mail.yahoo.com[66.196.97.250]:25, delay=4.9,

delays=0.04/0.01/4.6/0.2, dsn=2.0.0, status=deliverable (250 recipient

<[email protected]> ok)

Explique o que ocorreu:

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

5. Como posso “debugar” um domínio específico?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

Capítulo 8 Instalando e Configurando o OpenLDAP - 100

Capítulo 8

Instalando e Configurando o

OpenLDAP


8.1. Introdução

O OpenLDAP é um software livre que implementa o protocolo LDAP -

Lightweight Directory Access Protocol que constitui-se como uma simplificação

do complexo e oneroso padrão X.500. A função principal do LDAP é prover um

serviço de diretórios onde informações podem ser dispostas de maneira hierárquica

para facilitar operações de leitura e busca. Atualmente, o LDAP é um serviço

presente em muitos ambientes de TI com o intuito de centralizar informações e

configurações comuns a diversos clientes e sistemas.

No contexto do Postfix, a integração com o LDAP constitui-se em uma maneira

robusta e organizada de centralizar informações a respeito das contas de e-mails com

suas respectivas senhas e demais informações correlatas, tais como identificações

pessoais, caminho para a sua “mailbox”, dentre outras.

Neste caso, ao invés dos seus usuários possuírem contas válidas no sistema

operacional do servidor de e-mails, toda a base de usuários ficará em um diretório

estruturado que pode ser mantido e gerenciado com muito mais facilidade e

segurança. Outras informações como as tabelas de pesquisa (lookup tables) para os

aliases (Falaremos sobre trabelas de pesquisas e aliases no capítulo 10) também

podem ser, perfeitamente, consolidadas, armazenadas e mantidas em servidores

LDAP.

O OpenLDAP possui a mesma estrutura do DNS, ou seja, armazena as

informações hierarquicamente.


A figura acima, representa a estrutura organizacional que utilizaremos para

armazenar as informações dos nossos domínios e usuários. O objeto “pai” ou RAIZ, é

o topo da estrutura, seguindo a lógica hierárquica, os demais níveis possuem a

referencia do objeto pai e seus subníveis.

O OpenLDAP possui basicamente 2 arquivos de configuração: “splad.conf” e

“ldap.conf”. Além deles, existem os arquivos de schema que são um conjunto de

regras que define os atributos e controles indicando onde cada dado pode ser

armazenado. Se um objeto não obedecer ás regras do schema então ele não pode ser

inserido no serviço de diretório.

Não nos aprofundaremos na ferramenta OpenLDAP, vamos apenas abordar

as configurações necessários para a nossa infraestrutura de correio

eletrônico. Para mais detalhes sobre o OpenLDAP acesse

http://www.openldap.org/ .

8.2. Comandos de Administração do OpenLDAP

O OpenLDAP possui comandos que auxiliam o administrador a incluir, alterar,

excluir e pesquisar informações dentro do serviço de diretório. Os comandos estão

divididos em: cliente e servidor.

http://www.openldap.org/


8.2.1. Comandos do Servidor

Os comando do servidor só pode ser executado na máquina em que o

OpenLDAP está instalado.

• slapd – Deamon do OpenLDAP

• slapadd – Para adição de informações através de arquivos LDIF

• slapindex – Utilizado para reindexar a base de dados utilizado pelo OpenLDAP

DICA – Assim como em banco de dados relacionais, o procedimento de

reindexação é importante para performance do OpenLDAP, especialmente

nas consultas.

• slaptest – Para testar se o arquivo de configuração está correto

• slappasswd – Usado para gerar a senha (Hash) para o atributo de senhas do OpenLDAP (userPassword)

ATENÇÃO – Para usar os comandos do servidor é necessário que o “daemon

slapd” esteja parado, ou seja, o OpenLDAP não pode estar ativo.

8.2.2. Comandos do Cliente

• ldapsearch – Permite realizar consultas no serviço de diretório

• ldapadd – Assim com slapadd, insere informações no serviço de diretório usando o formato de arquivo LDIF, porém com o OpenLDAP ativo.

• ldapmodify – Altera informações no serviço de diretório usando formato de arquivo LDIF.

• ldapdelete – Deleta informações no serviço de diretório usando formato de arquivo LDIF.

• ldappasswd – Troca senha de usuários. Esse comando afeta diretamente o atributo userPasswd que armazena as senhas no OpenLDAP.

8.2.3. O formato LDIF

As informações em um diretório LDAP podem ser inseridas, removidas ou

alteradas por meio do LDIF - LDAP Interchange Format, um formato criado e

especificado como parte integrante do próprio protocolo LDAP para essa finalidade.


O quadro abaixo mostra um exemplo de arquivo LDIF para representar uma

estrutura composta por um nó principal (“dc=dominios,dc=empresa”) que contém

dois “containers” para armazenar as contas de e-mails dos usuários dos domínios

matrizX.com.br e filialX.com.br, representados pelas entradas cujo DN é

“ou=matrizX.com.br,dc=dominios,dc=empresa” e “ou=filialX.com.br,

dc=dominios,dc=empresa”, respectivamente. Em seguida, existem mais duas

entradas LDIF que representam uma conta de e-mail em cada um dos domínios

citados.

dn: dc=dominios,dc=empresa

dc: dominios

o: dominios

objectClass: top

objectClass: dcObject

objectClass: organization

dn: ou=matrizX.com.br,dc=dominios,dc=empresa

ou: matriz.com.br

objectClass: top

objectClass: organizationalUnit

dn: ou=filialX.com.br,dc=dominios,dc=empresa

ou: filial.com.br

objectClass: top


dn: cn=Joao Cunha,ou=matrizX.com.br,dc=dominios,dc=empresa

telephoneNumber: (11)3333-9999

displayName: Joao Cunha

objectClass: person

objectClass: organizationalPerson

objectClass: inetOrgPerson



Instalando o OpenLDAP

# aptitude install slapd ldap-utils

Caso, dentre os seus repositórios de pacotes, estejam os DVDs/CDs da

distribuição instalada em seu servidor, é possível que o comando aptitude solicite a

inserção de algum ou alguns desses DVDs/CDs. Para mais informações a respeito dos

mecanismos de instalação e manutenção dos pacotes de seu servidor, consulte a

documentação da sua distribuição GNU/Linux.

Após baixar os pacotes, dependendo da configuração de seu sistema operacional, é

possível que a execução do comando anterior já solicite algumas informações para

compor a configuração do LDAP. Responda a todas as questões considerando os

valores default já sugeridos. Não se preocupe. Todas as configurações serão refeitas

a partir da edição do arquivo /etc/ldap/slapd.conf que será apresentado adiante.

Terminada a instalação dos pacotes, pare o servidor LDAP, siga os procedimentos

descritos abaixo com os seguintes comandos:

Pare o OpenLDAP

# /etc/init.d/slapd stop

Edite o /etc/default/slapd e modifique o parâmetro:

#vim /etc/default/slapd

SLAPD_CONF=/etc/ldap/slapd.conf

Remova a base de dados criada no momento da instalação

# rm /var/lib/ldap/*

Copie o exemplo do arquivo slapd.conf

# cp /usr/share/doc/slapd/examples/slapd.conf /etc/ldap/

Mude o dono e o grupo do arquivo slapd.conf

# chown openldap.openldap slapd.conf


8.3.1. Editando o arquivo /etc/ldap/slapd.conf

Será utilizado o schema “qmail.schema” para organizar os atributos das contas

de e-mails, apesar de ser possível utilizar outros schemas como o “authldap.schema”

provido por um dos pacotes do Courier. Outra possibilidade, apesar de mais

trabalhosa, é criar um schema próprio. Essa alternativa, entretanto, pode dificultar

também a integração dessa base LDAP com outros aplicativos. . O motivo da escolha

do “qmail.schema” é que este schema oferece diversas funcionalidades interessantes

dentre as quais o suporte à cotas de e-mail por tamanho da caixa postal e/ou por

número de de mensagens.

Antes de criar suas contas de e-mails utilizando o “qmail.schema”, é

necessário incorporá-lo ao seu servidor LDAP. Para tanto, o primeiro passo consiste

em obtê-lo a partir da Internet. Isso pode ser feito diretamente na Internet em

diversos sites.

Dica o qmail.schema pode ser obtido em

wget "http://trac.expressolivre.org/export/5192/branches/2.2/doc-

expressolivre/debian/arqs-conf/etc/ldap/schema_utf8/qmailuser.schema" -O

qmail.schema

Em seguida, salve-o no diretório /etc/ldap/schema. Por fim, edite o arquivo

/etc/ldap/slapd.conf, que controla o funcionamento do daemon do LDAP e adicione a

cláusula “include /etc/ldap/schema/qmail.schema”, e demais configurações

apresentadas no quadro a seguir:

# vi /etc/ldap/slapd.conf

include /etc/ldap/schema/qmail.schema

suffix "dc=empresa"

rootdn "cn=admin,dc=empresa"

rootpw "123"

Você pode usar o slappasswd para gerar em rootpw senha hash ex:

# slappasswd -s 123

## Indexando os campos para performance nas consultas

index objectClass eq


index cn,sn,ou eq,sub,approx

index uid,uidNumber,gidNumber eq

index mail,mailAlternateAddress eq,pres,sub

## Ajustando os permissionamentos

access to attrs=userPassword,shadowLastChange

by dn="cn=admin,dc=empresa" write

by anonymous auth

by self write

by * none

access to *

by dn="cn=admin,dc=empresa" write

by * read

É possível ainda incorporar mais funcionalidades ao esquema LDAP que está

sendo utilizado para o registro das contas de e-mails através do patch qmail-ldap.

Mais informações podem ser obtidas diretamente no site do

projeto(www.qmail-ldap.org), onde é possível encontrar as versões mais recentes do

patch, documentação e características.

8.3.2. Iniciando o slapd

Uma vez configurado o servidor LDAP, esse serviço deve ser inicializado

através do script /etc/init.d/slapd, conforme apresentado no comando seguinte:

# /etc/init.d/slapd start

8.3.3. Inserindo o domínio e os usuários através do LDIF

Crie o seguinte arquivo “/opt/estrutura_correio.ldif” contendo o seguinte conteúdo:

# vi /opt/estrutura_correio.ldif

dn: dc=empresa

dc: empresa

o: empresa

objectClass: top

objectClass: dcObject

objectClass: organization

http://www.openldap.org/


dn: ou=matrizx.com.br,dc=empresa

ou: matrizx.com.br

objectClass: top


dn: ou=filialx.com.br,dc=empresa

ou: filialx.com.br

objectClass: top


dn: uid=12345678900,ou=matrizx.com.br,dc=empresa


displayName: Joao Cunha

objectClass: person



objectClass: qmailUser

o: Empresa Matriz

mobile: (11)3333-9999

sn: Cunha

mail: [email protected]

homePhone: (11)3333-9999

givenName: Joao

cn: Joao Cunha

uid: 12345678900

mailHost: localhost

mailQuota: 1024

mailMessageStore:

maildir:/home/vmail/domains/matrizx.com.br/joao/Maildir/

homeDirectory: /home/vmail/domains/matrizx.com.br/joao/

accountStatus: A

mailAlternateAddress: [email protected]

userPassword: 123

dn: uid=98765432100,ou=filialx.com.br,dc=empresa


displayName: Maria Neves


objectClass: person



objectClass: qmailUser

o: Empresa Filial

mobile: (11)3333-9999

sn: neves

mail: [email protected]

homePhone: (11)3333-9999

givenName: Maria

cn: Maria Neves

uid: 98765432100

mailHost: localhost

mailQuota: 1024

mailMessageStore:

maildir:/home/vmail/domains/filialx.com.br/maria/Maildir/

homeDirectory: /home/vmail/domains/filialx.com.br/maria/

accountStatus: A


userPassword: 123

Agora vamos inseri-lo com o com o seguinte comando:

ldapadd -x -D “cn=admin,dc=empresa” -W -h localhost -f

/opt/estrutura_correio.ldif

Onde:

• -h – host no qual se vai conectar

• -p – porta de conexão. Por padrão é a 389-x – usa a autenticação simples

• -x – Autenticação sem encriptação

• -D – “cn=admin,dc=dominios,dc=empresa” - usuário que irá autenticar com permissão para incluir registros dentro do OpenLDAP

• -W – pede o “prompt” de senha

• -f – arquivo LDIF que será interpretado


8.3.4. Modificando usuários no OpenLDAP

Crie o seguinte arquivo em /opt/modifica.ldif.

dn: uid=98765432100,ou=filialx.com.br,dc=empresa

changetype: modify

replace: mailAlternateAddress


O parâmetro “changetype: modify” informa para o interpretador que a

operação será de alteração. O parâmetro “replace: mailAternateAddress” informa

para o interpretador qual atributo sofrerá alteração e por ultimo,

“mailAlternateAddress: [email protected]”, que é o valor propriamente

dito.

Para realizar a alteração, execute o comando:

ldapmodify -x -D “cn=admin,dc=empresa” -W -h localhost -f

/opt/modifica.ldif

8.3.5. Realizando troca de senhas dos usuários

Para realizar a troca de senha de um determinado usuário execute o comando:

ldappasswd -x -W -D "cn=admin,dc=empresa"

"uid=98765432100,ou=filialx.com.br,dc=empresa" -s senha_nova

Onde:

• -s – Informa a senha nova do usuário

Os demais parâmetros são iguais aos dos comandos anteriores.

8.3.6. Consultando registros no OpenLDAP

Para consultar registros no OpenLDAP digite o comando:

ldapsearch -x -D "cn=admin,dc=empresa" -b "dc=empresa" -W -h localhost

-LLL


Onde:

-LLL – imprime o resultado sem os comentários

Para consultar um atributo específico:

ldapsearch -x -D "cn=admin,dc=empresa" -b "dc=empresa" 'mail=maria*'

-W -h localhost -LLL

Atente para a parte do comando que está em negrito, neste caso estamos

pesquisando o atributo “mail”.

8.3.7. Removendo um usuário do OpenLDAP

Execute o seguinte comando:

ldapdelete -x -D "cn=admin,dc=empresa" -W -h localhost

"uid=98765432100,ou=filialx.com.br,dc=empresa"


8.4. Laboratório

1. Conforme apresentado no item 4.3 – Pratica Dirigida, incluir os usuários:

1. Maria Neves em filialx.com.br

2. Fulano de Ciclano em matrizx.com.br

3. Beltrano de Fulano em matrizx.com.br

4. Ciclano de Beltrano em filialx.com.br

2. Mude a senha para todos usuários para “4linux”

3. Realize uma consulta de todos usuários apresentado somente o atributo “cn” e

jogue no arquivo usuarios.ldif


8.5. Exercícios

1. O que é o OpenLDAP?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

2. O que é um arquivo em formato LDIF?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

3. Qual a diferença entre os comandos slapadd e ldapadd?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________


4. O que são os “schemas” para o OpenLDAP?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

Capítulo 9 Servidor POP/IMAP com Dovecot e Integração com o OpenLDAP e SSL - 115

Capítulo 9

Servidor POP/IMAP com Dovecot e

Integração com o OpenLDAP e SSL


9.1. Introdução

Uma das grandes vantagens do Dovecot é a sua integração, e conforme

descrito no Capítulo 8 – Instalação do OpenLDAP, integraremos o Dovecot para fins

de autenticação de usuários. Além disso, essa integração permitirá a consulta de

informações de caixas postais(usuário,apelidos e local de armazenamento) e

domínios. Vamos entender também os recursos que o Dovecot oferece.

9.1.1. Interface de Autenticação SASL do Dovecot

O SASL é um serviço que manipula requisições de autenticação, sendo

normalmente utilizado em conjunto com serviços de correio. Suas funcionalidades

são estendíveis a qualquer software que necessite validar usuários. O SASL do

Dovecot tem suporte a validar usuários através de vários métodos

(AUTHENTICATION MECHANISMS), dentre os mais utilizados estão o PAM, LDAP,

MySQL e PostgreSQL. Existe também o SASL do Cyrus denominado saslauthd que é

largamente utilizado. Com vistas a atender o nosso curso o SASL utilizado será o que

vem presente junto ao pacote do Dovecot


9.2.1. Preparando o ambiente para armazenamento das caixas postais

Nesse usar nesse modelo o formato Maildir para isso iremos criar o usuário

VMAIL e o grupo VMAIL para realizar as gestão das mensagens para o Dovecot e

Postfix.

Criando o usuário, grupo e diretório dos e-mails – vmail (VAR MAIL):

# groupadd -g 240 vmail

# useradd -m -g 240 -u 240 -d /home/vmail -s /bin/false vmail

# mkdir -p /home/vmail/domains/matrizX.com.br

# mkdir -p /home/vmail/domains/filialX.com.br

# chown -R vmail.vmail /home/vmail


9.2.2. Instalando o Dovecot

# aptitude install dovecot-common dovecot-imapd

9.2.3. Integrando e Configurando o Dovecot com OpenLDAP

Edite o arquivo /etc/dovecot/dovecot-ldap.conf e configure os parâmetros

conforme o modelo:

hosts = localhost

dn = cn=admin,dc=empresa

dnpass = 123

base = dc=empresa

scope = subtree

user_attrs = homeDirectory=home, uidNumber=uid, gidNumber=gid,

mailMessageStore=mail, mailQuota=userdb_quota=*:bytes=%$K

user_filter = (&(objectClass=qmailUser)(accountStatus=A)(|(mail=%u)

(mailAlternateAddress=%u)))

pass_attrs = uid=mail,userPassword=password

pass_filter = (&(objectClass=qmailUser)(accountStatus=A)(|(mail=%u)

(mailAlternateAddress=%u)))

default_pass_scheme = PLAIN

Observação: o valor “mailQuota=userdb_quota=*:bytes=%$K ” é o formato

para a quota no dovecot.

Veja mais detalhes em http://wiki.dovecot.org/Quota/Maildir

9.2.4. Configurando o Dovecot

Edite o arquivo /etc/dovecot/dovecot.conf

# Habilitando os Protocolos

protocols = imap imaps managesieve

# Definindos em quais portas os protocolos responderam

protocol imap {

listen = *:143

ssl_listen = *:943

}

protocol managesieve {

http://wiki.dovecot.org/Quota/Maildir


listen = *:2000

}

# Permitindo autenticação em PLAIN text

disable_plaintext_auth = no

shutdown_clients = yes

log_timestamp = "%Y-%m-%d %H:%M:%S "

# Ativando o SSL

ssl = yes

ssl_cert_file = /etc/ssl/certs/dovecot.pem

ssl_key_file = /etc/ssl/private/dovecot.pem

# Usuário que tem permissão para manipular as caixas e mensagens no

Dovecot, neste caso o VMAIL

mail_uid = 500

mail_gid = 500

mail_privileged_group = vmail

# Essas opções afeta o desempenho do servidor IMAP

dotlock_use_excl = yes

fsync_disable = yes

# Gerente do protocolo imap, habilitando os plugins que serão

utilizados

protocol imap {

mail_plugins = quota imap_quota autocreate

}

# Gerente do protocolo POP3

protocol pop3 {

pop3_uidl_format = %08Xu%08Xv

}

# Gerente do filtro, permite você a gerir os filtros do Dovecot

protocol managesieve {

}

# Ativando o protocolo de entrega do Dovecot, responsável por receber

do postfix e entregar na caixa postal do usuário

protocol lda {

postmaster_address = [email protected]

hostname = mailx.matrizx.com.br

mail_plugins = quota sieve


mail_plugin_dir = /usr/lib/dovecot/modules/lda

deliver_log_format = msgid=%m: %$

sendmail_path = /usr/sbin/sendmail

rejection_subject = Rejeitado: %s

rejection_reason = Sua mensagem para <%t> foi rejeitada: %n%r

}

# Ativando os debugs de login para ratreio de problemas

auth_verbose = yes

auth_debug = yes

auth_debug_passwords = yes

# Configurando o mecanismo de autenticação do Dovecot que será

utilizando tanto pelo Dovecot quanto para o Postfix para autenticação

SMTP e IMAP e entregas de mensagens via LDA do Dovecot

auth default {

mechanisms = plain login

passdb ldap {

args = /etc/dovecot/dovecot-ldap.conf

}

userdb ldap {


}

user = root

socket listen {

master {

path = /var/run/dovecot/auth-master

mode = 0600

user = vmail

group = vmail

}

client {

path = /var/spool/postfix/private/auth

mode = 0660

user = postfix

group = postfix

}

}

}


# Configuração de plugins

plugin {

# Definido Quotas Padrão

quota = maildir:User quota

quota_rule = *:storage=521000

quota1_rule = Trash:storage=50000

quota2_rule = Spam:storage=50000

# Aviso de Quota aproximando do limite

quota_warning = storage=80%% /usr/local/sbin/quota-warning.sh 80

# Definindo local onde ficara os arquivos de filtro do usuário

sieve=/home/vmail/domains/%d/%n/%n.sieve

# Pastas que serão criadas no 1º login do usuário

autocreate = Spam

autocreate2 = Trash

autocreate3 = Drafts

autocreate4 = Sent

autosubscribe = Spam

autosubscribe2 = Trash

autosubscribe3 = Drafts

autosubscribe4 = Sent

}

9.2.5. Configurado o script de aviso de quota

Crie o arquivo /usr/local/sbin/quota-warning.sh com o seguinte conteúdo:

#!/bin/sh

PERCENT=$1

FROM="[email protected]"

msg="From: $FROM

To: $USER

Subject: Alerta de quota - $PERCENT% em uso

Content-Type: text/plain; charset=UTF-8

Prezado Usuário,

Esta mensagem e apenas para informar que sua caixa postal esta

atingindo $PERCENT%.


E recomendado que voce exclua mensagens irrelevantes, esvazie a pasta

Lixeira e a pasta Spam.

Atenciosamente,

Postmaster"

echo -e "$msg" | /usr/sbin/sendmail -f $FROM "$USER"

exit 0

Reiniciando o Dovecot

# /etc/init.d/dovecot restart

Testando o Dovecot

# telnet localhost 143

Trying 127.0.0.1...

Connected to localhost.


* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE

STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.

a login [email protected] 123

a OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE

SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT

IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE

QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS

QUOTA] Logged in

Se o resultado for com apresentado acima o usuário [email protected] esta

logado no Dovecot.

Caso não tenha dado certo verifique os logs em mail.log

Observe se esse erro é apresentado:

Nov 29 10:22:53 mailx dovecot: IMAP(12345678900): mail_location:

Ambiguous mail location setting, don't know what to do with it:

/home/vmail/domains/matrizx.com.br/joao/Maildir/ (try prefixing it with

mbox: or maildir:)

Esse erro é devido a falta do valor “maildir” no atributo

“mailMessageStore” no OpenLDAP



Verifique se o Dovecot criou as pastas do usuário joao em:

# ls -la /home/vmail/domains/matrizx.com.br/joao/Maildir/


9.3. Exercícios

1. Qual a diferença entre o protocolo POP e IMAP?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

2. Qual a função do “LDA” no Dovecot ?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

3. Qual a função do usuário VMAIL?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

Capítulo 10 Postfix – Integração com OpenLDAP, Dovecot e Autenticação SMTP - 124

Capítulo 10

Postfix – Integração com OpenLDAP,

Dovecot e Autenticação SMTP


10.1. Introdução

O Postfix possui grande flexibilidade quando o assunto é integração,

especialmente com base de dados como mysql, PostgreSQL e LDAP.

Neste capitulo iremo aprender como realizar essa integração e como o Postfix

se comporta. Também veremos conceitos de usuários e domínios virtuais

possibilitando a hospedagem de múltiplos domínios.

Além disso vamos configurar o SMTP Autenticado para garantir que os

usuários internos ou externos possam se autenticar antes de enviar uma mensagens

através do Postfix.


Verificando se o módulo do ldap para o Postfix esta instalado

# postconf -m

btree

cidr

environ

hash

internal

ldap

nis

pcre

proxy

regexp

sdbm

static

tcp

unix

Veja que o LDAP aparece na consulta aos módulos disponíveis no Postfix. Caso

não tenha basta instalar o módulo com o comando aptitude. Veja:


# aptitude install postfix-ldap

Como vamos utilizar a interface de autenticação SASL do Dovecot se faz

necessário verificar se o Postfix tem suporte ao SASL do Dovecot, para isso execute o

seguinte comando:

# postconf -a

Se o resultado abaixo aparecer é que o Postfix esta em conformidade

cyrus

dovecot

Além da alteração do arquivo master.cf deve-se alterar também o main.cf do

Postfix e adicionar as seguintes linhas:

# vi /etc/postfix/main.cf

smtpd_sasl_type = dovecot

smtpd_sasl_path = private/auth

smtpd_sasl_auth_enable = yes

Após essas configurações, reinicie o Postfix:

# /etc/init.d/postfix restart

10.2.1. Testando os métodos de autenticação

1 - MÉTODO PLAIN


1 # perl -MMIME::Base64 -e 'print

encode_base64("\000joao\@matrizX.com.br\000123");'

2 telnet localhost 25

3 Trying 127.0.0.1...

4 Connected to localhost.

5 Escape character is '^]'.

6 220 mail.matriz.com.br - Empresa DOMINIO S/A

7 helo mail.matriz.com.br

8 250 mail.matriz.com.br

9 auth plain AGpvYW9AbWF0cml6LmNvbS5icgAxMjM=

10 235 2.0.0 Authentication successful

11 quit

12 221 2.0.0 Bye

13 Connection closed by foreign host.

2 - MÉTODO LOGIN

# perl -MMIME::Base64 -e 'print encode_base64("joao\@matrizX.com.br");'

Y2ljbGFub0Bkb21pbmlveC5jb20uYnI=

# perl -MMIME::Base64 -e 'print encode_base64("123");'

MTIz

# telnet localhost 25

Trying 127.0.0.1...

Connected to localhost.



220 mail.matriz.com.br - Empresa DOMINIO S/A

helo mail.matriz.com.br

250 mail.matriz.com.br

auth login

334 VXNlcm5hbWU6

Y2ljbGFub0Bkb21pbmlveC5jb20uYnI=

334 UGFzc3dvcmQ6

MTIz

235 2.0.0 Authentication successful

quit

221 2.0.0 Bye

Connection closed by foreign host.

10.3. Identificando problemas de autenticação

Como estamos utilizando o OpenLDAP como nossa base de usuários é

necessário aumentar a verbosidade de seu log para isso edite o arquivo slapd.conf e

coloque o parâmetro “log level” para “256” como no exemplo:

# vi /etc/ldap/slapd.conf

loglevel 256

Reiniciar o slapd

# /etc/init.d/slapd restart

Verifique o que esta chegando de parâmetros no syslog use o comando tail -f.

Veja o exemplo:

# tail -f /var/log/syslog | grep slapd

Verifique também o arquivo mail.log e veja o que o Postfix e o Dovecot esta

reclamando. Abaixo um trecho de log:

May 7 16:47:25 tine postfix/smtpd[1657]: connect from

localhost[127.0.0.1]

May 7 16:47:38 tine dovecot: auth(default): client in:


AUTH#0112#011plain#011service=smtp#011nologin#011lip=127.0.0.1#011rip=127

.0.0.1#011resp=UzQ1Njc4OTAwADEyMw==

May 7 16:47:38 tine dovecot: auth(default): plain(?,127.0.0.1): invalid

input

May 7 16:47:40 tine postfix/smtpd[1657]: warning: localhost[127.0.0.1]:

SASL plain authentication failed:

May 7 16:47:40 tine dovecot: auth(default): client out: FAIL#0112

May 7 16:47:42 tine postfix/smtpd[1657]: disconnect from

localhost[127.0.0.1]

10.4. Criando certificados digitais para o Postfix com OpenSSL

O OpenSSL é uma implementação de código aberto dos protocolos SSL e TLS.

A biblioteca, escrita na linguagem C, implementa as funções básicas de criptografia e

disponibiliza várias funções utilitárias.

10.4.1. Criptografia Assimétrica

Este tipo de criptografia usa um par de chaves diferentes em que, não sendo

possível obter uma chave a partir da outra, as duas estão relacionadas

matematicamente, conseguindo uma decifrar o que foi cifrado pela outra. Com esta

característica é possível que uma das chaves seja publicada, a chave pública.

Esta forma de criptografia tem como vantagens o fato da chave privada se

manter protegida e ser só do conhecimento do seu titular. Como desvantagens tem o

fato do seu desempenho ser mais lento em consequência de utilizar um processo

algorítmico mais complexo.

10.4.2. Padrão X.509

Os certificados digitais X.509 incluem não apenas o nome e a chave pública de

um usuário, mas também outras informações sobre o usuário. Esses certificados são

mais que um ponto de partida em uma hierarquia digital de confiança. Eles permitem

que a autoridade de certificação ofereça ao receptor de um certificado um meio de

confiar não apenas na chave pública do indivíduo do certificado, mas também em


outras informações sobre o indivíduo do certificado. Essas outras informações podem

incluir, entre outras coisas, um endereço de e-mail, uma autorização para assinar

documentos de um determinado valor ou a autorização para se tornar uma

autoridade de certificação e assinar outros certificados. Os certificados X.509 e

muitos outros certificados têm um prazo de validade. Um certificado pode expirar e

não ser mais válido. Uma autoridade de certificação pode revogar um certificado por

vários motivos. Para processar as revogações, uma autoridade de certificação

mantém e distribui uma lista de certificados revogados chamada CRL (lista de

certificados revogados). Os usuários da rede acessam a CRL para determinar a

validade de um certificado.

10.4.3. Instalando o OpenSSL:

# aptitude install openssl

10.4.4. Gerando a requisição do certificado:

# mkdir /etc/postfix/ssl

# cd /etc/postfix/ssl

# openssl req -new -out servidor.reg -keyout servidor.privkey

10.4.5. Descriptografando a chave privada:

Esse processo se faz necessário para que os serviços que não solicitem a senha

de descriptografia da chave privada.

# openssl rsa -in servidor.privkey -out servidor.key

10.4.6. Gerando um certificado auto-assinado:

# openssl x509 -in servidor.reg -out servidor.cer -req -signkey

servidor.key -days 365

10.4.7. Verificando o conteúdo do certificado:

# openssl x509 -noout -text -in servidor.cer

Certificate:

Data:


Version: 1 (0x0)

Serial Number:

a2:fa:48:48:18:9c:24:d0

Signature Algorithm: sha1WithRSAEncryption

Issuer: C=BR, ST=Goias, L=Anapolis, O=DOMINIO, OU=CPD,

CN=srv/[email protected]

Validity

Not Before: Apr 13 18:25:11 2009 GMT

Not After : Apr 11 18:25:11 2019 GMT

Subject: C=BR, ST=Goias, L=Anapolis, O=DOMINIO, OU=CPD,

CN=srv/emailAddress=tornis@matriz .com.br

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

RSA Public Key: (1024 bit)

Modulus (1024 bit):

00:ca:c9:d6:95:d8:5e:d5:bc:86:46:02:f0:cf:eb:

cc:c7:78:2f:48:94:19:66:20:a2:6c:73:77:42:ab:

39:2c:fc:3f:99:3e:b7:d2:7f:eb:98:95:66:65:7c:

0c:91:1b:0d:ff:e2:54:9f:ec:8a:11:06:69:d1:6d:

5a:85:73:58:de:1d:9e:ac:5d:0a:fd:fb:cb:94:fb:

69:08:66:55:1d:65:b9:c7:c6:93:8e:82:e6:c4:bb:

3d:de:50:31:d5:3a:1d:9f:98:06:53:2e:c6:de:32:

50:a4:67:f5:db:84:5b:2d:c1:cf:f1:e9:9e:64:e4:

0e:21:ea:9a:68:b9:c8:40:1b

Exponent: 65537 (0x10001)

Signature Algorithm: sha1WithRSAEncryption

30:9f:92:41:73:8a:2b:52:e8:b2:2f:97:7f:6f:e6:c1:bd:7e:

40:03:16:da:8b:96:38:01:90:63:7a:d7:a1:42:99:4c:05:e0:

96:9c:80:06:78:c5:70:c1:c7:85:3a:b6:19:ac:c7:ec:81:6a:

1d:26:b4:e4:54:99:6b:c4:44:fd:af:dd:93:51:2d:d8:53:33:

ff:01:fe:6f:85:8b:29:2f:e1:f3:0b:e5:55:c8:50:22:96:38:

47:55:e8:f6:6d:55:52:b2:63:f5:54:cf:87:43:24:2a:26:95:

fd:a5:ea:e1:4a:60:d8:b9:1e:c5:12:80:a9:8f:da:24:b2:ef:

89:0d


10.4.8. Configurando o Postfix com SSL/TLS - Suporte a Certificados Digitais

Altere os parâmetros do arquivo /etc/postfix/main.cf para suporte ao TLS:

smtpd_tls_cert_file=/etc/postfix/ssl/servidor.cer

smtpd_tls_key_file=/etc/postfix/ssl/servidor.key

smtpd_use_tls=yes

Altere os parâmetros do arquivo /etc/postfix/master.cf para suporte ao SSL:

#

======================================================================



#

======================================================================

smtp inet n - - - - smtpd

#submission inet n - - - - smtpd

# -o smtpd_enforce_tls=yes

# -o smtpd_sasl_auth_enable=yes

smtps inet n - - - - smtpd

-o smtpd_tls_wrappermode=yes

-o smtpd_sasl_auth_enable=yes

10.5. Integrando e Configurando o Postfix com OpenLDAP e Dovecot

A integração com uma base dedados qualquer é bastante simples e suportada

pelos mapas de pesquisa oferecidos pelas bibliotecas correspondentes. No caso do

OpenLDAP. Conforme descrito no capitulo anterior a estrutura que iremos utilizar

para armazenar de caixas postais será o MAILDIR. E o responsável por entragar as

mensagens até o Dovecot será o Postfix através do programa “Deliver” do Dovecot.

Para que o Postfix possa receber e enviar essas mensagens se faz necessário a

integração com o LDA(Deliver do Dovecot). Vimos anteriormente no tópico 9.2.4 do

capitulo 9 que o protocolo LDA está configurado para aceitar realizar a autenticação

e entregas das mensagens vindas do Postfix.


Para relembrar veja a configuração feira no arquivo /etc/dovecot/dovecot.conf

# Configuração do Protocolo LDA para entrega de mensagens na caixa

postal do usuário e com plugins de quotas e filtros

protocol lda {

postmaster_address = [email protected]

hostname = mailx.matrizx.com.br

mail_plugins = quota sieve

mail_plugin_dir = /usr/lib/dovecot/modules/lda

deliver_log_format = msgid=%m: %$

sendmail_path = /usr/sbin/sendmail

rejection_subject = Rejeitado: %s

rejection_reason = Sua mensagem para <%t> foi rejeitada: %n%r

}

# Configurando o mecanismo de autenticação do Dovecot que será

utilizando tanto pelo Dovecot quanto para o Postfix para autenticação

SMTP e IMAP e entregas de mensagens via LDA do Dovecot

auth default {

mechanisms = plain login

passdb ldap {


}

userdb ldap {


}

user = root

socket listen {

master {

path = /var/run/dovecot/auth-master

mode = 0600

user = vmail

group = vmail

}

client {

path = /var/spool/postfix/private/auth

mode = 0660


user = postfix

group = postfix

}

}

}

Observando as linhas em negrito acima, identificamos a configuração

necessária para o funcionamento da entrega de mensagens.

10.5.1. Editando o arquivo /etc/postfix/master.cf no Postfix:

## Entrega via LDA Dovecot

dovecot unix - n n - - pipe

flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f $

{sender} -d ${recipient}

10.5.2. Editando o arquivo /etc/postfix/main.cf no Postfix:

# Definindo para onde o Postfix terá que transportar a mensagem

dovecot_destination_recipient_limit = 1

# Dominios virtuais cadastrado no OpenLDAP

virtual_mailbox_domains = ldap:/etc/postfix/ldap/vmd.cf

# local para onde o Postfix irá realizar o transporte da mensagem

virtual_transport = dovecot

# Mapeamento de usuários logados. Necessário para impedir que um

usuário logado envie mensagens em nome de outro remetente

smtpd_sender_login_maps = ldap:/etc/postfix/ldap/vms.cf

10.5.3. Criando os arquivos vmd.cf e vms.cf

# mkdir /etc/postfix/ldap

# vi /etc/postfix/ldap/vmd.cf

server_host = localhost

server_port = 389

bind_dn = cn=admin,dc=empresa

bind_pw = 123

search_base = dc=empresa


query_filter = (&(ou=%s))

result_attribute = ou

version = 3

bind = yes

timeout = 30

# vi /etc/postfix/ldap/vms.cf


server_port = 389

bind_dn = cn=admin,dc=empresa

bind_pw = 123

search_base = dc=empresa

query_filter = (&(objectClass=qmailUser)(mail=%s))

result_attribute = mail

version = 3

bind = yes

timeout = 30

Após essas configurações, reinicie o Postfix:


10.5.4. Testando as consultas virtuais LDAP com o postmap:

# postmap -q matrizX.com.br ldap:/etc/postfix/ldap/vmd.cf

# postmap -q filialX.com.br ldap:/etc/postfix/ldap/vmd.cf

# postmap -q [email protected] ldap:/etc/postfix/ldap/vms.cf

# postmap -q [email protected] ldap:/etc/postfix/ldap/vms.cf


10.6. Exercícios

1. Qual o objetivo da ativação do SSL/TLS no Postfix?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

2. Qual o objetivo da ferramenta SASL quando integrada ao Postfix?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

3. Qual a vantagem de usar o OpenLDAP integrado ao Postfix?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

Capítulo 11 Instalando e Configurando o Cliente Thunderbird POP/IMAP - 137

Capítulo 11

Instalando e Configurando o Cliente

Thunderbird POP/IMAP


11.1. Introdução

Thunderbird é um cliente livre de correio eletrônico e notícias criado pela

Mozilla. Oferece recursos necessários a empresas, tais como S/MIME, assinaturas

digitais, criptografia de mensagens, suporte a certificados e dispositivos de

segurança. Permite ainda adicionar novo recursos a medida que precisar através de

extensões. As extensões são ferramentas poderosas que auxiliam a criar um cliente

de e-mail de acordo com as necessidades.

Atualmente o Mozilla concentra esforços para manter um versão enterprise que

tem i seu ciclo de vida maior chamada de ESR, nesse momento a versão que esta na

ESR e a 10.0

11.1.1. Baixando a versão ESR do Thunderbird

Acesso o seguinte endereço:

http://www.mozilla.org/en-US/thunderbird/organizations/all-esr.html

Baixe a versão correspondente português Brasil

Descompacte o arquivo:

# tar jxfv thunderbird-10.0.4esr.tar.bz2

Acesse o diretório criado e execute o thunderbird:

# cd thunderbird

# ./thunderbird

Configure os campos conforme a figura abaixo:

http://www.mozilla.org/en-US/thunderbird/organizations/all-esr.html


Clique em no botão “continuar” e depois em “Configuração Manual” e

preencha os campos conforme a figura abaixo:

Após preenchido todos os campos clique no botão Criar Conta


Obs: Caso aparecer a tela de certificados aceite todos tanto o servidor

IMAP quando do servidor SMTP

Realize os testes de envio e recebimento para o usuário [email protected]

O Thunderbird oferece um gama de extensões e plugins que aumenta a

produtividade recomendamos alguns:

Contacts Side Bar – Barra de contatos

https://addons.mozilla.org/en-US/thunderbird/addon/70

Signature Switch - Multiplas assinaturas


Lightning - Calendário e Agenda


Display Quota – Visualizar a quota de sua caixa postal

https://addons.mozilla.org/pt-br/thunderbird/addon/display-quota/?src=search

https://addons.mozilla.org/pt-br/thunderbird/addon/display-quota/?src=search





Capítulo 12 Instalando e Configurando o Cliente Webmail RoundCube POP/IMAP - 142

Capítulo 12

Instalando e Configurando o Cliente

Webmail RoundCube POP/IMAP


12.1. Introdução

O RoundCube é uma solução de webmail gratuito e de código aberto com uma

interface de usuário de desktop fácil de instalar/configurar e que roda em um

servidor Apache/PHP padrão. O interessante é que ele é desenvolvido com recentes

padrões da Web, como XHTML e CSS 2. Roundcube inclui outras sofisticadas

bibliotecas open-source como o PEAR, uma biblioteca IMAP derivado IlohaMail o

editor de texto rico TinyMCE, Googiespell biblioteca para verificação ortográfica.

12.2. Instalando e Configurado o Webmail RoundCube

O RoundCube tem uma grande vantagem que é trabalhar com os bancos de

dados Mysql, PostgreSQL, MSSQL ou Sqlite. Para o nosso ambiente iremos utilizar o

banco de dados PostgreSQL. Siga os passos abaixo para a instalação da

infraestrutura do RoundCube:

# aptitude install postgresql-8.4 apache2 php5 php5-pgsql php5-gd

O próximo passo é criar o banco de dados. Para isso siga os passos a seguir:

# su – postgres

$ createuser roundcube -P -s

Digite a senha para a nova role: 123

Digite-a novamente: 123

$ createdb -O roundcube roundcube

No passo anterior criamos o usuário roundcube e o banco de dados roundcube

Agora vamos baixar a ultima versão “Stable” do RoundCube em:

http://roundcube.net/download

Coloque o arquivo no diretório /var/www

# mv roundcubemail-0.7.2.tar.gz /var/www

# tar zxfv roundcubemail-0.7.2.tar.gz

# mv roundcubemail-0.7.2 webmail

http://roundcube.net/download


# chown -R www-data.www-data webmail/temp

# chown -R www-data.www-data webmail/logs

# chown -R www-data.www-data webmail/config

Agora abra o seu navegador e vamos iniciar o processo de instalação e

configuração do RoudCube. Para isso acesse http://ip_do_servidor/webmail/installer/

A seguinte tela ira aparecer:

Clique no botão “START INSTALATION”.

A próxima tela irá realizar um teste de dependências do PHP. Verifique se todas

as dependências estão satisfeitas. Dependências em laranja são opcionais e as

vermelhas são obrigatórias. Veja a tela abaixo:

http://ip_do_servidor/webmail/installer/


Neste caso o RoundCube esta reclamando de uma parâmetro do PHP que não

esta com o valor certo para a aplicação. Para realizar essa correção siga os passos:

Altere o arquivo /etc/apache2/sites-enabled/000-default e procure o seguinte

trecho e altere o parêmetro “AllowOverride” para All conforme o Exemplo:

# vi /etc/apache2/sites-enabled/000-default

<Directory /var/www/>

Options Indexes FollowSymLinks MultiViews

AllowOverride All

Order allow,deny

allow from all

</Directory>

Reinicie o Apache

# /etc/init.d/apache2 restart

Agora em seu navegado digite as teclas juntas CTRL+F5 para atualizar a

pagina do RonudCube. Observe que as dependências fora satisfeitas:


Agora clique no botão “Next”. Essa tela tem o objetivo de configurar o

comportamento do RoundCube, abaixo segue a relação dos campos que deve ser

alterados:

• General configuration

◦ product_name = Dominio S/A

• Data Base Setup

◦ Driver=PgSQL

◦ Database server=localhost

◦ Database name=roundcube

◦ Database user name = roundcube

◦ Database password=123

• IMAP Settings

◦ default_host=localhost


◦ default_port=143

◦ auto_create_user=Marque

• SMTP Settings

◦ smtp_server=localhost

◦ smtp_port=25

◦ Use the current IMAP username and password for SMTP

authentication=Maque

• Display settings & user prefs

◦ language=pt_BR

Após configurado os parâmetros acima clique no botão “CREATE CONFIG”

Nesse momento o instalado do RoundCube cria 2 arquivos:

main.inc.php

db.inc.php

Você deve realizar o Donwload desses aquivos e coloca-los em

/var/www/webmail/config.

Após realizado o Download de a permissão para o usuário do Apache realizar a

leitura dos aquivos:

# chown -R www-data.www-data /var/www/webmail/config -R

Volte para o instalador do RoundCube e clique no botão “CONTINUE”

Se tudo estiver correto a seguinte tela ira aparacer


Nesta mesma página podemos realizar um teste de conectividade com os

serviços SMTP e IMAP para isso basta preencher os campos. Veja o exemplo:

A fim de garantir a segurança do RoundCube vamos desabilitar o instalar

configurando o arquivo /var/www/webmail/config/main.inc.php no “enable_installer”

para false.


12.2.1. Finalizando a instalação do Webmail

Acesse o RoundCube:

http:// seu_ip / webmail/

http://seu_ip/webmail/





12.2.2. Estendendo o RounCube – Plugins

Assim com o Thunderbird o RoundCube possui plugins que ajudam na

produtividade do usuário uma deles é o plugin de filtros Sieve. O Sieve é uma

linguagem de filtros para e-mail (http://en.wikipedia.org/wiki/Sieve_

%28mail_filtering_language%29) que tem se tornado comum em servidores IMAP.

Por ser padronizada é possível migar os filtros de uma servidor para outro sem

grande esforço. Abaixo segue um trecho de um filtro:

# Sieve filter

# Declare the extensions used by this script.

#

require ["fileinto", "reject"];

# Messages bigger than 100K will be rejected with an error message

#

if size :over 100K {

reject "I'm sorry, I do not accept mail over 100kb in size.

Please upload larger files to a server and send me a link.

Thanks.";

}

Para habiliar o plugin de filtros no RoundCube siga os seguintes passos:

# cd /var/www/webmail/plugins/managesieve/

# mv config.inc.php-dist config.inc.php

# cd /var/www/webmail/config

Agora habilite o plugin em /var/www/webmail/config/main.inc.php

$rcmail_config['plugins'] = array("managesieve");

Agora no Webmail RoundCube acesse:

• Configurações Pessoais → Clique na Abra Filtro

Veja a figura abaixo:

http://en.wikipedia.org/wiki/Sieve_(mail_filtering_language)

http://en.wikipedia.org/wiki/Sieve_(mail_filtering_language)


Crie o filtro conforme a sua necessidade, para conferir se o filtro foi criado liste

o diretório do usuário joao em;

# ls -l /home/vmail/domains/matrizx.com.br/joao/

o resultado é “joao.sieve”

Capítulo 13 Antivírus e AntiSpam - 152

Capítulo 13

Antivírus e AntiSpam


13.1. ClamAV

13.1.1. Introdução

O ClamAV é um conjunto de ferramentas antivírus de código aberto para Linux.

O principal recurso do projeto foi integrá-lo a servidores de e-mail para realizar

varredura de anexos e ajudar a filtrar vírus conhecidos. O pacote fornece um

“daemon” de múltiplas linhas de execução flexível e escalonável.

O ClamAV oferece proteção a maioria de tipo de documentos:

• Arquivos executáveis

• Documentos Microsoft: MS OLE,Cabinet, CHM

• Outros formatos: RAR, ZIP, GZIP, BZIP2, TAR

O ClamAV é formado pelo serviço “clamd” que recebe requisições de analise de

arquivos pelo pipe /var/run/clamav/clamd.ctl e pelo “daemon” Freshclam,

responsável pelas atualizações da base de vírus conhecidos. Enquanto o “daemon”

freshclam estiver atualizando a base de informações de vírus o arquivo de lock

/var/lib/clamav/.dbLock existirá, fazendo com que o serviço de atualização não altere

a base de definições de vírus /var/lib/clamav e o clamd estará disponível para uso

após a atualização.

13.1.2. Instalando o ClamAV

A versão do ClamAV disponível nos repositórios do Debian Lenny não são

funcionais. Portanto instalaremos os pacotes do repositório oficial do projeto. Para

isso, será necessário adicioná-los ao nosso “sources.list”, para em seguida, instalar o

ClamAV. Seguem os passos:

# echo “deb http://volatile.debian.org/debian-volatile stable/volatile

main contrib non-free” >> /etc/apt/sources.list

# aptitude update


# aptitude install clamav-daemon clamav-freshclam arj bzip2 cabextract

cpio file gzip lha nomarch pax rar unrar unzip zip zoo

13.1.3. Entendendo o Clamd.conf

LocalSocket /var/run/clamav/clamd.ctl

FixStaleSocket true

User clamav

AllowSupplementaryGroups true

ScanMail true

ScanArchive true

ArchiveLimitMemoryUsage false

ArchiveBlockEncrypted false

MaxDirectoryRecursion 15

FollowDirectorySymlinks false

FollowFileSymlinks false

ReadTimeout 180

MaxThreads 12

MaxConnectionQueueLength 15

StreamMaxLength 10M

LogSyslog true

LogFacility LOG_LOCAL6

LogClean false

LogVerbose true

PidFile /var/run/clamav/clamd.pid

DatabaseDirectory /var/lib/clamav

SelfCheck 3600

Foreground false

Debug false

ScanPE true

ScanOLE2 true

ScanHTML true

DetectBrokenExecutables false

MailFollowURLs false

ExitOnOOM false

LeaveTemporaryFiles false

AlgorithmicDetection true


ScanELF true

IdleTimeout 30

PhishingSignatures true

PhishingScanURLs true

PhishingAlwaysBlockSSLMismatch false

PhishingAlwaysBlockCloak false

DetectPUA false

ScanPartialMessages false

HeuristicScanPrecedence false

StructuredDataDetection false

LogFile /var/log/clamav/clamav.log

LogTime true

LogFileUnlock false

LogFileMaxSize 0

Seguem alguns comentários a respeito dos parâmetros em destaque:

• User clamav - Usuário que executará o daemon;

• ScanMail true - Habilita o clamav para scanear e-mails;

• ScanArchive true - Habilita o clamav para scanear arquivos (usado com o Samba);

• MaxThreads 12 - Número máximo de threads como recomendação configura-se o MaxThreads ~ 2 * Nº de cores + 1

• MaxConnectionQueueLength 15 - Número máximo de conexões em fila de espera;

• StreamMaxLength 10M - Tamanho máximo do arquivo, utilizado quando trabalha em cluster. Deve ter o mesmo tamanho permitido pelo seu MTA;

• Debug false - Desabilita o debug.

13.1.4. Testando o ClamAV

Para testar o ClamAV pode-se utilizar um arquivo que é um falso vírus. Chama-

se “eicar_com” e pode ser baixado da URL abaixo:

# wget --no-check-certificate https://secure.eicar.org/eicar_com.zip

# clamdscan eicar_com.zip

https://secure.eicar.org/eicar_com.zip


13.2. SpamAssasin


SpamAssassin é um consolidado filtro de spam distribuído através da licença

Apache. O filtro SpamAssassin funciona dando uma pontuação a cada mensagem que

entra, baseado em diferentes analises feitas em todo o conteúdo da mensagem. De

acordo com esta análise, ele acrescenta cabeçalhos na mensagem que informam o

seu "nível de spam", e os testes nos quais ela não passou. No final, a mensagem

recebe uma pontuação ("score").

Se o score fica acima de certo limite (5 por default), a mensagem é colocada

num arquivo chamado "bulk" dentro da pasta "mail" do usuário. Portanto, será

colocada em mail/bulk. Mas, se a mensagem tem um score muito alto , ela é

caracterizada SPAM. Entretanto, se o score for inferior a 5, a mensagem é deixada na

pasta usual (Inbox).

Uma das grandes vantagens do SpamAssassin é que ele "aprende" na medida

em que é usado. Ele observa, pela pontuação das mensagens, quais são os tipos de

SPAM que você recebe e quais são os tipos de mensagens "limpas" também. Desta

maneira ele passa a ser mais rigoroso com os SPAMS e menos rigoroso com as

mensagens que ele acha que não são SPAM.

Outra característica do SpamAssassin é a modificação de e-mail, ou seja, caso

ele classifique a mensagem como SPAM além de modificar os cabeçalhos da

mensagem ele também modifica o corpo da mensagem, ele convertera a mensagem

original em um anexo de e-mail, com um e-mail simples em torno dele.


13.2.2. Instalando o SpamAssassin

Seguem os passos:

# aptitude install spamassassin pyzor razor

Edite /etc/default/spamassassin para ativar o SpamAssassin daemon

ENABLED=1

Inicie o Spamassassin:

# /etc/init.d/spamassassin start

13.2.3. Arquivos User_prefs.cf e local.cf

Os arquivos user_prefs e local.cf contem parâmetros que definem o

comportamento do Spamassasin. O user_prefs.cf foi criado para permitir que cada

usuário possa configurar o spamassassin, já o local.cf é para uso global, ou seja, o

comportamento do spamassassin será aplicado a todos os usuários. Entretantoo

user_prefs.cf tem preferência e suas configurações prevalecerão sobre as

configurações gerais.

Porém se o uso do Spamassassin for como um “daemon”, no Postfix essa

configuração se torna global para todos usuários. Geralmente esse é lido pelo

Spamassassin nos seguintes diretórios:

• /usr/share/spamassassin

• /etc/mail/spamassassin

• ~/.spamassassin/user_perfs

Abaixo temos um exemplo do arquivo user_prefs:

use_bayes - utiliza deteção de spam através do algoritmo Bayes

auto_learn – utiliza o sistema de auto-aprendizado do Bayes.

ok_languages - mensagens nas linguagens especificadas são consideradas

válidas, a qualquer outra será atribuido o valor de

UNWANTED_LANGUAGE_BODY (padrão 2.800).


ok_locales - permite apenas determinados códigos de caracteres.

skip_rbl_checks – habilita a execução de testes RBL, e atribui valores

baseados nos resultados.

use_razor2 - utiliza base de dados centralizada do Razor para deteção

de spam conhecido.

use_dcc/use_pyzor - dois outros sistemas similares ao Razor

dns_available - verifica existência dos domínios através de queries

DNS.

use_auto_whitelist - gera listas brancas baseadas no comportamento de

longo termo de um determinado remetente (não utilizado no momento).

score SYMBOLIC_TEST_NAME n.nn [ n.nn n.nn n.nn ] - aumenta ou diminui

os scores padrão de determinadas regras, onde “SYMBOLIC_TEST_NAME” é o

nome da regra que será tratada e “n.nn” é a pontuação desejada.

report_safe (0 | 1 | 2) (padrão: 1) - Se esta opção estiver definida

como 1, se uma mensagem recebida é marcada como spam, em vez de

modificar a mensagem original, SpamAssassin irá criar uma nova mensagem

e anexar a mensagem original. Se esta opção estiver definida como 2, em

seguida, a original será anexado com um tipo de conteúdo text / plain .

Esta configuração pode ser necessária a certos clientes de email que

pode corromper anexos. Se esta opção estiver definida como 0, só é

modificado adicionando alguns X-Spam-cabeçalhos e nenhuma alteração

será feita no corpo da mensagem. X Além disso, um cabeçalho com o

nome-Spam-Report será adicionado ao spam. Você pode usar a opção

remove_header para remover esse cabeçalho após o ajuste report_safe a

0.

rewrite_header { subject | from | to } STRING - Ao definir esta opção,

o cabeçalho será marcado com o valor em STRING para indicar que uma

mensagem é spam.


trusted_networks - Que redes ou hosts são "confiáveis" em sua

configuração.

O exemplo acima ilustra a configuração do arquivo user_prefs, apenas alguns

parâmetros estão citados, para mais detalhes acesse:

http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html

13.2.4. Treinando o SpamAssassin

O SpamAssassin necessita de treinamento afim de melhorar a sua detecção de

spam, a funcionalidade bayesiana só ativada após 200 registros de SPAM e 200 não

SPAM. Apesar de ser uma árdua esse procedimento se faz necessário para que o

SpamAssassim possa atingir de 95% a 100% o acerto de mensagens que são SPAM e

que não são SPAM.

Para baixar spams de exemplo acesse o site:

http://spamassassin.apache.org/publiccorpus/20050311_spam_2.tar.bz2

http://spamassassin.apache.org/publiccorpus/20030228_spam_2.tar.bz2

http://spamassassin.apache.org/publiccorpus/20030228_hard_ham.tar.bz2

http://spamassassin.apache.org/publiccorpus/20030228_easy_ham_2.tar.bz2

Para treinar o SpamAssassin digite:

# tar jxfv 20050311_spam_2.tar.bz2

# sa-learn --spam --progress spam_2

# rm -rf spam_2

# tar jxfv 20030228_spam_2.tar.bz2

# sa-learn --spam --progress spam_2

# tar jxfv 20030228_hard_ham.tar.bz2


# sa-learn --spam --progress hard_ham

# tar jxfv 20030228_easy_ham_2.tar.bz2

# sa-learn --ham --progress easy_ham_2

Você pode criar um script que automatiza esse processo, e claro, contar com a

ajuda de seus usuários mover as mensagens pasta SPAM em seu webmail.

Criar o script:

# vi /usr/bin/autolearn_spam.sh

#!/bin/sh

/usr/bin/find /home/vmail/domains/*/*/Maildir -type d -name .Spam

-exec sa-learn --spam {} \;

Salve em /usr/bin/autolearn_spam.sh e coloque a seguinte entrada no

/etc/cron.d/

# chmod 755 /usr/bin/autolearn_spam.sh

# vi /etc/crond.d/autolearn_spam

0 0 * * * root /usr/bin/autolearn_spam.sh >/dev/null

13.2.5. Testando o SpamAssassin

Pode-se utilizar o cliente do SpamAssasin para testar o seu daemon e ainda ver

o resultado do relatório de pontuação do mesmo.

Em um terminal execute:

# spamc -R < /usr/share/doc/spamassassin/examples/sample-spam.txt

Capítulo 14 Integrando AntiSpam e Antivírus com o Postfix - 161

Capítulo 14

Integrando AntiSpam e Antivírus com

o Postfix


14.1. Amavis


O Amavisd-new é um módulo Perl que desempenha a ponte entre MTA e

antivírus ou SpamAssassin. Ele se comunica com com MTA através do protocolo

SMTP ou LMTP, ou usando programas. Possui boa performance na filtragem de e-

mails e boa integração com o Postfix e possuindo as seguintes características:

Lista das checagens executadas pelo Amavis (não necessariamente na ordem

em que ocorrem):

• Checagem de vírus usando ClamAV (clamd).

• Checagem de spam usando SpamAssassin (stand-alone).

• Anexos:

◦ Extensões proibidas – exe|vbs|pif|scr|bat|cmd|com|cpl

◦ Extensões que não podem ser duplicadas - exe|vbs|pif|scr|bat|cmd|

com|cpl|dll (ex.: arquivo.src.exe)

◦ Tipos MIME proibidos - application/x-msdownload|application/x-

msdos-program|application/hta

◦ Cabeçalhos e textos que aumentam o score de spam - (verificar

variável @score_sender_maps no arquivo amavisd.conf)


Funcionamento do Amavis-New:

Por padrão o amavis-new possui o arquivo amavisd.conf que concentra todos

parâmetros para sua configuração. Eles esta dividido em 9 seções de configurações:

• Seção I - Configurações essenciais do amavis e MTA

• Seção II - Configuração do MTA do amavis-new

• Seção III - Configuração e comportamento do Log do amavis-new

• Seção IV - Mensagens de Notificações do amavis-new

• Seção V - Configuração e tratamento de remetentes e destinatários,

incluindo exceções, notificações listas brancas e destino final caso uma

mensagem esteja marcada como spam ou vírus.

• Seção VI - Configuração dos limites de recursos para o amavis-new

• Seção VII - Integração e Configuração de programas externos, anti-

virus e SpamAssassin

• Seção VIII - Debugging

• Seção IX - Policy banks (dynamic policy switching)


No Debian a amavisd.conf está dividido em arquivos localizados em

/etc/amavis/conf.d:

01-debian

05-domain_id

05-node_id

15-av_scanners

15-content_filter_mode

20-debian_defaults

25-amavis_helpers

30-template_localization

50-user

Cada aquivo desse representa uma seção do arquivo amavisd.conf, por exemplo

o arquivo 20-debian_defaults é o arquivo responsável pelas configurações de

parâmetros do SpamAssassim e ClamAV e o 15-av_scanners é responsável pela

configuração dos possíveis antivírus que podem ser utilizados.

14.1.2. Instalando Amavis-New

# aptitude install amavisd-new

14.1.3. Configurando Amavis-New

# vi /etc/amavis/conf.d/15-content_filter_mode

use strict;

# You can modify this file to re-enable SPAM checking through

spamassassin

# and to re-enable antivirus checking.

#

# Default antivirus checking mode

# Uncomment the two lines below to enable it

#

@bypass_virus_checks_maps = (

\%bypass_virus_checks, \@bypass_virus_checks_acl, \

$bypass_virus_checks_re);

#


# Default SPAM checking mode

# Uncomment the two lines below to enable it

#

@bypass_spam_checks_maps = (

\%bypass_spam_checks, \@bypass_spam_checks_acl, \

$bypass_spam_checks_re);

1; # insure a defined return

Configurando o Amavis para entregar mensagens marcadas como SPAM

# vi /etc/amavis/conf.d/20-debian_defaults

$final_spam_destiny = D_PASS;

Adicionar o usuário clamav no grupo amavis e o usuário amavis no grupo

clamav

adduser clamav amavis

adduser amavis clamav

Reinicie o Amavis

# /etc/init.d/amavis restart

O SpamAsssassin detecta automaticamente os componentes opcionais e irá

utilizá-los se eles estiverem presentes. Isto significa que não há nenhuma

necessidade para configurar o cliente DCC, Pyzor e Razor.

14.1.4. Configurações específicas do SpamAssassim

Usar o SpamAssassin integrado ao amavis-new tem a vantagem de desempenho

e é importante verificar as versões de ambos pois pode haver incompatibilidade caso

o SpamAssassin tenha uma versão atualizada.

Algumas configurações precisão ser feitas no aquivo /etc/amavis/conf.d/20-

debian_defaults

$sa_spam_subject_tag = '[SPAM]';

# Nivel de legitimidade do e-mail acima desse valor é considerado o

cabeçalhos X-Spam-Satus e X-Spam-Level

$sa_tag_level_deflt = 3.0;


$sa_tag2_level_deflt = 6.31;

# Nivel que é SPAM é rejeitado

$sa_kill_level_deflt = 12;

# Spam com o nível acima de 12 é entregue de qualquer forma.

$final_spam_destiny = D_PASS;

Vamos entender as linhas acima:

• $sa_spam_subject_tag = '[SPAM]' – A tag que será adicionado caso uma

mensagem for detectada como spam no, caso é [SPAM]

• $sa_tag_level_deflt = 3.0 - Acima desse Score a mensagem não é

considerada SPAM, o amavis ira adicionar no cabeçalho as tags X-Spam-

Status e X-Spam-Level

• $sa_tag2_level_deflt = 6.31 – As mensagens acima desse Score será

considerada SPAM e sera adicionado ao cabeçalho as tags X-Spam-Flag:

YES' e no assunto SPAM

• $sa_kill_level_deflt = 12 - Mensagens acima deste nível dependerá da Tag

$final_spam_destiny.

• $final_spam_destiny = D_PASS – Neste caso mensagens de Score igual

ou acima definido em $sa_kill_level_deflt serão entregues. Caso deseje

que elas sejam descartadas altere para D_DISCARD.

14.1.5. Outras configurações do Amavis-New

# vi /etc/amavis/conf.d/20-debian_defaults

$virus_admin = “postmaster\@matrizX.com.br”;

$inet_socket_port = 10024

$sa_local_tests_only = 0;

$final_virus_destiny = D_DISCARD; #(data not lost, see virus

quarantine)

$final_banned_destiny = D_BOUNCE; #D_REJECT when front-end MTA


$final_spam_destiny = D_DISCARD;

$final_bad_header_destiny = D_PASS; #False-positive prone (for

spam)

$banned_filename_re = new_RE(

# qr'ÛNDECIPHERABLE$', # is or contains any undecipherable

components

# block certain double extensions anywhere in the base name

qr'\.[^./]*\.(exe|vbs|pif|scr|bat|cmd|com|cpl|dll)\.?$'i,

qr'\{[0-9a-f]{8}(-[0-9a-f]{4}){3}-[0-9a-f]{12}\}?'i,

# Windows Class ID CLSID, strict

qr'âpplication/x-msdownload$'i, # block these MIME types

qr'âpplication/x-msdos-program$'i,

qr'âpplication/hta$'i,

# qr'âpplication/x-msmetafile$'i, # Windows Metafile MIME type

# qr'^\.wmf$', # Windows Metafile file(1) type

# qr'^message/partial$'i, qr'^message/external-body$'i, # rfc2046 MIME

types

# [ qr'^\.(Z|gz|bz2)$' => 0 ], # allow any in Unix-

compressed

# [ qr'^\.(rpm|cpio|tar)$' => 0 ], # allow any in Unix-type

archives

# [ qr'^\.(zip|rar|arc|arj|zoo)$'=> 0 ], # allow any within such

archives

# qr'.\.(exe|vbs|pif|scr|bat|cmd|com|cpl)$'i, # banned extension -

basic

# qr'.\.(ade|adp|app|bas|bat|chm|cmd|com|cpl|crt|emf|exe|fxp|grp|hlp|

hta|

# inf|ins|isp|js|jse|lnk|mda|mdb|mde|mdw|mdt|mdz|msc|msi|msp|

mst|

# ops|pcd|pif|prg|reg|scr|sct|shb|shs|vb|vbe|vbs|


# wmf|wsc|wsf|wsh)$'ix, # banned ext - long

# qr'.\.(mim|b64|bhx|hqx|xxe|uu|uue)$'i, # banned extension - WinZip

vulnerab.

qr'^\.(exe-ms)$', # banned file(1) types

# qr'^\.(exe|lha|tnef|cab|dll)$', # banned file(1) types

Alguns dos parâmeros acima está comentado, você pode descomentá-los

conforme a sua necessidade. Perceba que é possível adicionar mais extensões para as

regras.

14.1.6. Integrando Amavis com o Postfix

Vamos editar o master.cf

# vi /etc/postfix/master.cf

smtp-amavis unix - - y - 2 smtp

-o smtp_data_done_timeout=1200

-o smtp_send_xforward_command=yes

-o disable_dns_lookups=yes

-o max_use=20

127.0.0.1:10025 inet n - y - - smtpd

-o content_filter=

-o local_recipient_maps=

-o relay_recipient_maps=

-o smtpd_restriction_classes=

-o smtpd_delay_reject=no

-o smtpd_client_restrictions=

-o smtpd_helo_restrictions=

-o smtpd_sender_restrictions=

-o smtpd_recipient_restrictions=permit_mynetworks,reject

-o smtpd_data_restrictions=reject_unauth_pipelining

-o smtpd_end_of_data_restrictions=

-o mynetworks=127.0.0.0/8

-o smtpd_error_sleep_time=0

-o smtpd_soft_error_limit=1001

-o smtpd_hard_error_limit=1000


-o smtpd_client_connection_count_limit=0

-o smtpd_client_connection_rate_limit=0

-o receive_override_options=no_header_body_checks,

no_unknown_recipient_checks

Edite o main.cf e adicione a seguinte linha:

content_filter=smtp-amavis:127.0.0.1:10024

Edite o arquivo /etc/mailname e tenha certeza de que o seu domínio está

contido nele:

# vi /etc/mailname

matrizX.com.br

filialX.com.br

Reinicie todos os serviços envolvidos:



# /etc/init.d/spamassassin restart

# /etc/init.d/clamav-daemon restart

14.1.7. Testando o Amavis-New

Utilize o Cliente de E-mail (ICE-Dove ou Evolution) anexando o vírus de testes

EICAR e verifique os logs do Postfix.

Faça o mesmo enviando uma mensagem com o arquivo

“/usr/share/doc/spamassassin/examples/sample-spam.txt” como anexo. E fique de

olho nos logs.


14.2. Exercícios

1. Qual a função do Amavis-New?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

2. É possível colocar o Amavis para rodar em um servidor separado ?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

3. O Amavis pode trabalhar com mais de um anti-vírus simultâneo?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________


4. Descreva o processo de funcionamento do Amavis-New integrado ao

Postfix(Apenas conceitual)?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

Capítulo 15 SPF e Greylist - 172

Capítulo 15

SPF e Greylist


15.1. Introdução

15.1.1. SPF

Sender Policy Framework ou SPF é um sistema que evita que outros domínios

(endereço da internet) enviem mensagens forjando seu domínio, ou seja, fazendo-se

passar por um domínio que o servidor de envio não é o MX publicado pelo DNS. O

SPF verifica no cabeçalho de internet se o SMTP6(servidor de emails) utilizado para

enviar a mensagem, está autorizado na relação de IP's que respondem pelo domínio

do remetente. Também informa se o domínio autoriza ou não que outros IP's fora

desta relação enviem e-mails em seu nome. O administrador configura esta relação

na entrada TXT da zona de DNS seguindo as regras da RFC 4408 SPF homepage.

Caso este sistema esteja ativo e o IP solicitado seja diferente dos autorizados, o

e-mail será rejeitado. Para incluir este registro é necessário atualizar a zona DNS que

corresponde pelo respectivo domínio

A checagem SPF possui sete mecanismos:

• PASS(+) – O host verificado está autorizado a enviar e-mail do domínio - Aceite

• FAIL(-) – O host verificado não está autorizado a enviar e-mail do domínio - Rejeite

• SOFTFAIL(~) – O host verificado não esta autorizado, mas esta em processo de liberação – Aceite mas maque a mensagem

• NEUTAL(?) – Sem informações do host verificado – Aceite

• NONE – O domínio não possui registro SPF - Aceite

• PERMERROR – Erro permanente – Não Especificado

• TEMPERROR- Erro temporário – Aceite ou Rejeite

15.1.2. Greylist

Este termo refere-se a um método de filtragem de spams, implantado

diretamente no servidor de e-mails, que recusa temporariamente um e-mail e o

recebe somente quando ele é reenviado. Servidores de e-mails legítimos, que se


comportam de maneira correta e de acordo com as especificações dos protocolos,

sempre reenviam as mensagens. Este método parte do princípio que spammers

raramente utilizam servidores legítimos e, portanto, não reenviam suas mensagens. A

Greylist se torna ineficaz contra SPAMs provenientes de servidores com Open Relay,

visto que são MTAs válidos.



15.2.1. Configurando o seu DNS com registros TXT para SPF:

# vi /etc/bind/db_matrizX.conf

$TTL 604800

@ IN SOA mail.matrizX.com.br. root.mail.matrizX.com.br.

(

1 ; Serial

604800 ; Refresh

86400 ; Retry

2419200 ; Expire

604800 ) ; Negative Cache TTL

;

@ IN NS mail.matrizX.com.br.

@ IN MX 10 mail.matrizX.com.br.

@ IN TXT “v=spf1 ip4:192.168.1.X -all”

mail IN A 192.168.1.X

Reinicie e bind

# /etc/init.d/bind9 restart

15.2.2. Ativando o Plugin SPF do SpamAssassim

Umas das grandes vantagens do SpamAssassim e sua capacidade de extensão.

Por padrão o SpamAssassim vem com o Plugin SPF habilitado. No Debian o arquivo

que habilita esse plugin esta em /etc/spamassassim/init.pre

loadplugin Mail::SpamAssassin::Plugin::SPF

Você pode ajustar os scores das regras do SPF com intuito de aumentar e

diminuir a pontuação padrão do SpamAssassim. Isso pode ser feito em

/etc/spamassassim/local.cf. Abaixo segue as pontuação padrão do SFP:

score SPF_FAIL 0 1.333 0 1.142

score SPF_HELO_FAIL 0

score SPF_HELO_NEUTRAL 0


score SPF_HELO_SOFTFAIL 0 2.078 0 2.432

score SPF_NEUTRAL 0 1.379 0 1.069

score SPF_SOFTFAIL 0 1.470 0 1.384

15.2.3. Realizando teste de SPF com a ferramenta spftool

Altere o registro DNS da zona matrizx.com.br conforme o modelo:

# vi /etc/bind/db_matrizx.conf

@ IN TXT "v=spf1 ip4:10.196.16.86 -all"

Salve e restarte o Bind


Instale o SPFQTOOL

# aptitude install spfqtool

Execute o Teste de SPF

# spfqtool -i 192.168.1.2 -s [email protected] -h mail.matrizX.com.br

SPF short result: fail

SPF verbose result: policy result: [fail] from rule [-all]

RFC2822 header: Received-SPF: fail (mail.matrizx.com.br: domain of

[email protected] does not designate 192.168.1.2 as permitted sender)

receiver=mail.matrizx.com.br; client_ip=192.168.1.2; envelope-

[email protected];

Agora mude novamente o registro /etc/bind/db_matrizx.conf conforme o

modelo abaixo:

# vi /etc/bind/db_matrizx.conf

@ IN TXT "v=spf1 ip4:10.196.16.86 ~all"

Salve e reinicie o Bind



Faça novamente o teste com o SFPQTOOL e veja o resultado

# spfqtool -i 192.168.1.2 -s [email protected] -h mail.matrizX.com.br

SPF short result: softfail

SPF verbose result: policy result: [softfail] from rule [~all]

RFC2822 header: Received-SPF: softfail (mail.matrizx.com.br: domain

of transitioning [email protected] does not designate 192.168.1.2 as

permitted sender) receiver=mail.matrizx.com.br; client_ip=192.168.1.2;

[email protected];

15.2.4. Instalando e Configurando o Postgrey – Greylist

Postgrey é uma implementação de política greylisting para filtrar spam ou

ataques spammers em servidores de email Postfix. O princípio é simples, o Postgrey

temporariamente rejeitar novos e-mails com o erro 450 "tente novamente mais tarde"

por um determinado período de tempo e registrará o IP, remetente, destinatário em

seu banco de dados. Se o servidor de envio é compatível com RFC, então ele deve

reenviar a mensagem ai o Postgrey irá verificar seu banco de dados se esse cliente já

tentou enviar e mensagem e chega com as regras estabelecidas em sua base de

configuração que é baseada em tempo e tentativa. Veja a figura:


Instalando o PostGrey

# aptitude install postgrey

Edite o arquivo /etc/postfix/mail.cf adicione a linha check_policy_service

unix:postgrey/socket conforme o modelo abaixo:

smtpd_recipient_restrictions =


permit_mynetworks,

.

.

reject_unauth_destination,

check_policy_service inet:127.0.0.1:10023

Obs: o regra da greylist deve vir após o parâmetro

reject_unauth_destination. Caso você não coloque nessa ordem o seu

servidor pode ficar em OpenRelay

Reinicie o Postfix


Agora edite o arquivo /etc/default/postgrey conforme o modelo:

# vi /etc/default/postgrey

POSTGREY_OPTS="--inet=10023 --delay=300 –max-age=30"

POSTGREY_TEXT="Greylist - Favor aguardar"

Onde:

--inet é a porta que o Postgrey ira responder

--delay é o tempo em segundos que um cliente deve esperar

--max-age é o tempo em dias que o cliente será expirado do banco de dados

Reinicie o Postgrey


# /etc/init.d/postgrey restart

Reinicie o Policyd e o Postgrey

# /etc/init.d/postfix-policyd restart

# /etc/init.d/postgrey restart

15.2.5. Testando o Postgrey

Para realizar o teste basta usar o comando telnet:

# telnet 192.168.1.x 25

Em outro terminal verifique os logs do Postfix

# tail -f /var/log/mail.log

E veja o resultado. Exemplo:

# telnet 10.196.16.86 25

Trying 10.196.16.86...

Connected to 10.196.16.86.


220 mail ESMTP Postfix (Debian/GNU)

helo smtp.matrizx.com.br

250 mail

mail from:<[email protected]>

250 2.1.0 Ok

rcpt to:<[email protected]>

450 4.2.0 <[email protected]>: Recipient address rejected: Greylist -

Favor aguardar

Resultado do log

May 9 13:22:37 tine postfix/smtpd[3598]: NOQUEUE: reject: RCPT from

unknown[10.196.16.86]: 450 4.2.0 <[email protected]>: Recipient

address rejected: Greylist - Favor aguardar; from=<[email protected]>

to=<[email protected]> proto=SMTP helo=<smtp.matrizx.com.br >


15.3. Exercícios

1. Qual a função do SPF?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

2. O que é necessário para que o SPF funcione corretamente?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

3. Qual a função da Greylist?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________


4. Porque a greylist não funciona com servidor com relay aberto?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

Capítulo 16 Aumentando a Performance da infraestrutura de Correio - 182

Capítulo 16

Aumentando a Performance da

infraestrutura de Correio


16.1. Introdução

Iremos apresentar dicas e sugestões que ajudam a melhorar o desempenho

Postfix e os demais componentes que compõem a infraestrutura de e-mail. O objetivo

dessa capítulo não é criar uma receita de bolo, mas sim apontar os lugares que

devem ser analisados para corrigir e melhorar o desempenho da infraestrutura de

correio eletrônico.

Iremos analisar filtros externos(Anti-Spam e Antivírus), consultas DNS,

consultas RBLS, consumo de CPU, memória, I/O de disco, etc.

16.1.1. Performance no Recebimento de Mensagens

Recomenda-se usar o serviço de DNS local para agilizar as consultas. Caso

esteja usando uma base LDAP elimine consultas desnecessárias. Caso o Postfix

demonstre lentidão nas conexões SMTP dos clientes, verifique os logs para

identificar a origem, verifique os filtros de cabeçalhos e corpo das mensagens,

considere o desligamento do chroot para verificar se o problema persiste. Verifique

também se o número de processos do “daemon” smtpd atingiu o limite.

Alguns clientes ao se conectar, podem gerar erros de sessão. O Postfix possui

um contador de erros de sessão, essa contagem é zerada quando obtêm êxito na

transferência da mensagem. Entretanto, quando é incrementado, o smtpd começa

aumentar o intervalo nas respostas. A ideia é controlar e limitar o uso desse recuso.

Os parâmetros:

• smtpd_soft_error_limit: Quando a contagem chegar ao valor definido, o

daemon smtpd atrasa todos que não estão em erro e as repostas de erro

passados com o valor definido pelo parâmetro smtpd_error_sleep_time .

• smtpd_hard_error_limit: Quando a contagem chegar ao valor definido,

o daemon smtpd derruba a conexão.


Pode-se também adotar medidas para clientes que realizam muitas conexões. O

Postfix pode limitar o número de conexões simultâneas a partir do mesmo cliente

SMTP, assim como a taxa de conexão e da taxa de certos comandos SMTP a partir do

mesmo cliente.

• smtpd_client_connection_count_limit: O número máximo de conexões que

um cliente SMTP poderá fazer simultaneamente.

• smtpd_client_connection_rate_limit: O número máximo de conexões que um

cliente SMTP pode fazer no intervalo de tempo especificado por

anvil_rate_time_unit.

• smtpd_client_message_rate_limit: O número máximo de entrega de

mensagem SMTP que um cliente pode fazer no intervalo de tempo especificado

por anvil_rate_time_unit

• smtpd_client_recipient_rate_limit: O número máximo de endereços que um

destinatário um cliente SMTP pode especificar, o intervalo de tempo

especificado por anvil_rate_time_unit

• smtpd_client_new_tls_session_rate_limit: O número máximo de novas

sessões TLS (sem utilizar o TLS sessão cache) que um cliente SMTP podem

negociar no intervalo de tempo especificado com anvil_rate_time_unit.

• smtpd_client_event_limit_exceptions: Clientes SMTP que estão excluídos do

contexto e taxa limites especificados acima. ($mynetworks)

16.1.2. Performance na Entrega de Mensagens

Problemas de DNS podem impactar na entrega de e-mail, você pode usar o

comando “dig” para verificar o tempo de a respostas do DNS.

# dig www.matrizX.com.br

; <<>> DiG 9.3.4 <<>> www.matrizX.com.br

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33990


;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:

;www.matrizX.com.br. IN A

;; AUTHORITY SECTION:

matrizX.com.br. 604800 IN SOA mailX.matrizX.com.br.

root.mail.matriz.com.br. 1 604800 86400 2419200 604800

;; Query time: 25 msec

;; SERVER: 192.168.15.103#53(192.168.15.103)

;; WHEN: Wed Apr 15 14:53:42 2009

;; MSG SIZE rcvd: 83

Considere o uso de DNS local . O “qshape” é ótima ferramenta para auxilio na

identificação de gargalos na entrega de mensagens.

Reduza os valores dos parâmetros “smtp_connect_timeout” e

“smtp_helo_timeout” para não desperdiçar tempo ao conectar a servidores

remotos.

Aumente o número de entregas simultâneas para o mesmo destino com os

parâmetros:

• initial_destination_concurrency;

• default_destination_concurrency_limit.

Para entregas locais e remotas use os parâmetros:

• local_destination_concurrency_limit;

• smtp_destination_concurrency_limit.

Outros parâmetros a considerar são default_destination_recipient_limit, que

define o número de destinatários por mensagem e smtpd_recipient_limit, controla

a quantidade de beneficiários por entrega.


Quando o agente de entrega do Postfix não é capaz de entregar uma

mensagem, o problema pode ser da própria mensagem ou a parte receptora(usuário

local ou servidor remoto). A mensagem fica aguardando o próximo "flush" da fila, isso

equivale aproximadamente 15 minutos. Podemos melhorar o desempenho

configurando os seguintes parâmetros:

queue_run_delay: Tempo em que o gerente verifica a fila deffered

minimal_backoff_time: Tempo minimo para uma mensagem ser morta.

maximal_backoff_time: Tempo máximo para uma mensagem ser morta.

maximal_queue_lifetime: Quanto tempo uma mensagem permanece na fila

antes de ser enviada de volta como não entregue.

bounce_queue_lifetime: Quanto tempo uma mensagem Mailer-DAEMON

permanece na fila antes que ela seja considerada

com não entregue.

qmgr_message_recipient_limit: O número máximo de destinatários em

memória realizada pelo gerente fila

Postfix.

16.1.3. número de Processos do Postfix

O parâmetro global default_process_limit fornece controle direto sobre

quantos processos do Postfix será executado. Mas cuidado isso pode onerar a

performance em máquinas com pouca memória.

Você também pode especificar o número de processos no master.cf, na coluna

“maxproc”.

# ============================================================



# ============================================================

. . . . . .

smtp inet n - - - 10 smtpd


16.1.4. Número de Processos do Sistema Operacional

Apesar do Kernel já estar configurado com o números de processos adequado

para diversas aplicações, é interessante avaliar o ajuste caso necessário. Pode-se

utilizar os comandom “sysctl -a” e “ipcs -la” para listar todos os parâmetros e seus

respectivos valores. Utilize o comando “ulimit -a” para verificar, também, qual é o

limite da opção “open file”, que define quantos arquivos podem ser abertos,

simultaneamente, no seu sistema.

16.1.5. Número de File Descriptors por Processo

Quando o Postfix abre muitos arquivos ou soquetes, pode haver erro de

processos abortando com erros fatais, possivelmente o sistema não esta configurado

adequadamente para suportar essa quantidade de aquivos abertos.

No Kernel os parâmetros responsáveis por essa configuração, são: fs.file-max e

kernel.threads-max. Pode-se especificá-los em “/etc/sysctl”. Aumente conforme a

necessidade.

16.1.6. Considerações sobre Hardware - Disco Rígido

Um sistema como Postfix consome muito disco devido ao gerenciamento das

filas de mensagens isso produz altos níveis de I/O em sites com grande quantidade de

e-mail, considere a aquisição de discos com altas taxas de transferências.

Você pode verificar o I/O de disco com o comando “vmstat” observando as

colunas BI(block input) BO(Block Output).

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----

r b swpd free buff cache si so bi bo in cs us sy id wa

0 0 24848 19656 8992 86528 0 1 18 33 266 25 44 2 54 1

0 0 24848 19656 8992 86528 0 0 0 0 253 18 1 3 96 0

0 0 24848 19656 8992 86528 0 0 0 0 253 7 0 2 98 0

0 0 24848 19656 8992 86528 0 0 0 0 254 16 0 0 100 0

0 0 24848 19656 8992 86528 0 0 0 0 254 9 0 1 99 0

Outra ferramenta bastante amigável é o “iostat”:

# iostat -m

Linux 2.6.26-2-686 (mailX) 21-09-2010 _i686_

avg-cpu: %user %nice %system %iowait %steal %idle


1,25 0,00 0,47 1,10 0,00 97,18

Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn

sda 6,13 0,03 0,06 357 802

sda1 6,11 0,03 0,06 354 798

sda2 0,00 0,00 0,00 0 0

sda5 0,02 0,00 0,00 2 3

Outro fator importante é separar serviços como anti-vírus, antí-spam, servidor

Courier e Webmail.

Algumas medidas interessantes podem ser estudadas:

• Separar um HD apenas para as filas do Postfix

• Se você tem muita memória pode criar um partição em memória e e

coloca as filas do Postfix nela.

Esta última medida é extrema e quando o hardware é muito confiável

• Separar os serviços de antivírus e anti-spam

• Discos rígidos de alta performance

16.1.7. Considerações sobre Hardware – Memória

Em uma infraestrutura de correio muitos serviços são utilizados e

consequentemente o consumo de recursos de hardware. Nesse contexto a memória é

fundamental para o desempenho do sistema. Isso se torna critico quando um servidor

possui muitos usuários e todos os serviços estão concentrados no mesmo servidor.

Um exemplo é o serviço de antivírus e anti-spam que consomem muita memória para

realizar a filtragem de mensagens. Caso o seu ambiente esteja esgotando a memória,

considere a segregação de serviços em outras maquinas.

Para identificar se o uso da memória esta no limite utilize as ferramentas

abaixo:

# free -m

total used free shared buffers cached

Mem: 504 452 51 0 37


150

-/+ buffers/cache: 264 239

Swap: 486 1 485

As ferramentas “top” e “htop”, também são bons aliados na identificação de

consumo de memória:

top - 14:45:48 up 4:08, 2 users, load average: 0.00, 0.00, 0.00

Tasks: 77 total, 1 running, 76 sleeping, 0 stopped, 0 zombie

Cpu(s): 0.0%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st

Mem: 516300k total, 463680k used, 52620k free, 38420k buffers

Swap: 497972k total, 1248k used, 496724k free, 154552k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1 root 20 0 2100 692 588 S 0.0 0.1 0:01.42 init

2 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd

3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0

4 root 15 -5 0 0 0 S 0.0 0.0 0:00.26 ksoftirqd/0

5 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0

6 root 15 -5 0 0 0 S 0.0 0.0 0:00.76 events/0

16.1.8. Considerações sobre Hardware – Rede

Outro fator que pode onerar o desempenho da infraestrutura de correio é sem

dúvida a rede. Especialmente se são muitos os clientes utilizando essa infraestrutura

e se o volume de mensagens transitando é alto. Para identificar se sua rede esta

suportando o volume de conexões e de mensagens utilize a ferramente “iftop”:

12.5Kb 25.0Kb 37.5Kb 50.0Kb

62.5Kb

└────────────────────────────────┴─────────────────────────────────┴────────────────────────────────┴─────────────────────────────────┴──────

───────────────────────────

mailX.matriX.com.br => 192.168.15.101

2.45Kb 3.02Kb 3.02Kb

<=

208b 312b 312b

mailX.matriX.com.br => 192.168.15.1

0b 288b 288b

<=

0b 552b 552b



16.2.1. Melhorando a Recepção de Mensagens

Editar o master.cf colocando o daemon smtpd em modo debug

smtp inet n - n - - smtpd -v

Reinicie o Postfix


• Filtrar erros no log do Postfix

egrep '(warning|error|fatal|panic):' /var/log/mail.log | more

• Analisar os filtros do Postfix (smtpd_*_restictions, header_check, body_checks e

consultas a RBLs) desativando-os para verificar se a lentidão persiste.

• Verificar se clientes estão se registrando como desconhecidos, isso ocorre com

servidores com FQND ruins e Spammers.

• Verificar se o número de processos do Postfix atingiu o limite, o padrão do

Postfix é de 100 e pode-se aumentar esse número, conforme a quantidade de

clientes. É importante lembrar que isso impacta diretamente nos recursos

oferecidos pelo seu servidor. Para aumentar o número de processos do Postfix

digite:

postconf -e “default_process_limit=500”

• Aumente o número de conexões que o cliente pode realizar no servidor

postconf -e “smtpd_client_connection_count_limit=100”

• Se o seu servidor trabalha com listas de e-mail considere aumentar o número

de destinatários no Postfix para dar mais vazão nas entradas do Postfix


postconf -e “smtpd_recipient_limit = 1000”

16.2.2. Melhorando as Filas de Mensagens

• Verifique o status da fila com os comandos mailq ou qshape, e identifique os

possíveis problemas, como: aumento demasiado da fila active, deferred e

bouce. Um dos motivos que levam ao aumento da fila, são problemas com DNS.

• Conforme a quantidade de clientes cresce, é necessário melhorar o

processamento dessas mensagens. Os parâmetros qmgr_message_active_limit

e qmgr_message_recipient_limit aumentam a performance da fila dando mais

vazão para o tratamento da fila “active”, outro parâmetro importante e

maximal_queue_lifetime e bounce_queue_lifetime, responsáveis por definir o

tempo de vida de uma mensagem que não pode ser entregue, para isso digite:

# postconf -e “qmgr_message_active_limit = 40000”

# postconf -e “qmgr_message_recipient_limit = 40000”

# postconf -e “maximal_queue_lifetime = 30m”

# postconf -e “bounce_queue_lifetime = 30m”

• Por recomendação do próprio Postfix.org o parâmetro “disable_dns_lookups”

deve estar desabilitado. Ele evita consultas em /etc/hosts para entregas

remotas.

# postconf -e “disable_dns_lookups = yes”

16.2.3. Melhorando a Entrega de Mensagens

• O processo de entrega de mensagem é responsável também pelo

enfileiramento de mensagens, nesse momento podem acontecer diversos

problemas na entrega como: hostnames não resolvidos, servidor indisponível,

servidores com greylist habilitados etc.

• O “daemon” responsável por entregas remotas é o “smtp”. Podemos melhorar a

vazão na entrega de mensagens modificando alguns parâmetros como:


• smtp_destination_concurrency_limit – Aumenta o número de entregas

paralelas para o mesmo destinatário, isso permite uma maior vazão na

entrega.

• maximal_backoff_time – O tempo máximo entre as tentativas de

entregar uma mensagem deferrida. Diminua esse tempo para aumentar

as tentativas de entrega.

• smtp_connect_timeout – Tempo limite de conexão para conexões

remotas, você deve diminuir esse tempo caso o daemon smtp fique muito

tempo conectado ao um servidor remoto.

• smtp_helo_timeout - Tempo limite de conexão para resposta do

comando HELO

• queue_run_delay – Tempo de varredura da fila defered. Deve-se

diminuir o tempo para que as varreduras seja feitas com mais frequência.

• default_destination_concurrency_limit – Similar ao

smtp_destination_concurrency_limit

• default_destination_recipient_limit – número máximo de destinatários

por entrega. Isso afeta os “daemos” smtp, local, virtual e lmtp. Tenha

cuidado em aumentar esse parâmetro pois servidores smtp podem

recusar o recebimento.

Editando os valores:

# postconf -e “default_destination_concurrency_limit=50”

# postconf -e “default_destination_recipient_limit=50”

# postconf -e “smtpd_client_connection_count_limit=100”

# postconf -e “smtp_destination_concurrency_limit=100”

# postconf -e “maximal_backoff_time = 1000s”

# postconf -e “minimal_backoff_time = 300s”


16.2.4. Melhorando a performance Sistema Operacional

A medida que você aumenta processos do Postfix é importante verificar se o SO

esta preparado para esse aumento. Esteja atento à configuração dos “files

descriptors” e processos abertos pelo SO.

Você pode ajustá-los em /etc/sysctl.conf adicionando os seguinte parâmetros:

fs.file-max = 192231

kernel.threads-max = 30681

Não se esqueça de aumentar a quantidade de arquivos abertos no sistema

operacional:

# ulimit -n 30000


16.3. Exercícios

1. Meus clientes estão tendo muita lentidão no envio do e-mail, o que devemos

observar para melhorar essa lentidão?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

2. O enfileiramento na fila defered está muito grando o que pode estar

ocorrendo:

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

3. O os clientes estão reclamando na demora do envio de mensagens, ou seja,

as mensagens estão demorando chegar no destinatário. O que pode estar

causando isso?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

Capítulo 17 Teste de Stress na Infraestrutura de Correio - 195

Capítulo 17

Teste de Stress na Infraestrutura de

Correio


17.1. Introdução

Você pode melhorar a performance da sua infraestrutura de correio realizando

testes de stress para medir a carga que ela suporta. O objetivo desse capitulo é

ensinar como realizar esses testes utilizando ferramentas livres, e aplicar os ajustes

apresentados no capítulo anterior.

17.1.1. smtp-source e smtp-sink

smtp-source se conecta a um host em uma porta TCP (porta 25 por padrão) e

envia uma ou mais mensagens, seja sequencialmente ou em paralelo. O programa

testa tanto SMTP (padrão) ou LMTP e se destina à ajuda para medir o desempenho

do servidor.

smtp-sink simula um servidor de e-mail escutando na porta 25. O seu objetivo é

receber as mensagens a partir da rede e descarta-as. Você pode medir medir

desempenho da rede com ele.

17.1.2. qmqp-source e qmqp-sink

qmqp-source se conecta a um host em uma porta TCP (porta 25 por padrão) e

envia uma ou mais mensagens, seja sequencialmente ou em paralelo. O programa

testa o protocolo QMQP e se destina à ajuda para medir o desempenho do servidor.

qmqp-sink realiza o mesmo trabalho do smtp-sink para protocolo QMQP.

17.1.3. Postal

Escrito por Russell Coker o Postal de destina e realizar testes em servidores

SMTP que trabalharam com alto trafego de e-mail, segundo o autor ele desenvolveu o

postal para testar 1.000.00 de usuários. Dentre as suas características podemos

destacar:

• Testes em múltiplos servidores

• Identificar problemas com DNS

• Suporte par servidores lentos



17.2.1. Entendendo do e usando o smtp-source

# time smtp-source -s 20 -l 5120 -m 100 -c

-f [email protected] -t [email protected] localhost:25

Onde:

• -s 20 – Sessões paralelas

• -l 5120 – Tamanho da mensagem em KB

• -m 100 – total de mensagens

• -c – contator

• -f Remetente

• -t destinatário

• endereço do servidor smtp

• porta

O comando Time é utilizando em conjunto com o smtp-source para contabilizar

o tempo de execução da tarefa.

17.2.2. Entendendo e usando o smtp-sink

Com dito anteriormente o smtp-sink simula um servidor SMTP. Ele deve ser

utilizado em conjunto com o smtp-source ou qualquer outra ferramenta para testar a

vazão da sua rede.

# smtp-sink -u root -c localhost:25 1000


• -u – Define o usuário que será utilizado para abrir o daemon

• -c – Ativa o contador de sessões finalizadas

• 1000 – Limite máximo de conexões no smtp-sink

• localhost:25 – nome e porta que o smtp-sink irá escutar

17.2.3. Usando o smtp-sink em conjuto com smtp-source

Para medir o desempenho da rede execute os seguintes procedimentos:

Abra 2 terminais, em um dos terminais execute:

smtp-sink -u root -c localhost:25 1000

No outro terminal execute:

time smtp-source -s 20 -l 5120 -m 100000 -c

-f [email protected] -t [email protected] localhost:25

Observe que a vazão de entrega dos e-mails. O smtp-sink apenas descarta as

mensagens e diz que para o smtp-source que foi entregue.

Agora faremos um teste com o smtp-source entregando efetivamente para o

Postfix.

Obs.: não é necessário o uso do smtp-sink

Execute o comando:

time smtp-source -s 20 -l 5120 -m 100000 -c

-f [email protected] -t [email protected] 192.168.1.X:25

Observe que a vazão diminuiu. O motivo é que agora o smtp-source não está

trabalhando com o smtp-sink que descarta as mensagens. Neste caso o smtp-source

esta trabalhando em conjunto com o Postfix, que por sua vez irá tratar a mensagem

até a sua entrega na caixa postal do usuário.


17.2.4. Usando o Postal

postal -m 10 -t 10 -c 5 -r 60 localhost lista-usarios.txt

Onde:

• -m 10 – tamanho(em KB) máximo da mensagem

• -t 10 – Numero de threads

• -c 5 – mensagens por conexão

• - r 60 – Mensagens por minuto

• localhost – servidor smtp

• lista-usurios.txt – Lista contendo os usuários

O resultado produzido:

time,messages,data(K),errors,connections

17:13,35,194,0,22

17:14,57,314,0,19

O Postal apresenta informações a cada minuto, apresentando a hora/minuto,

total de mensagens entregue, total mensagens em KB, quantidade de erros e

quantidade de conexões por minuto.

17.2.5. Ferramentas de monitoramento

Monitorar é preciso! O nosso objetivo neste tópico é simular uma carga em

nosso ambiente de e-mail, para isso necessitamos de parâmetros para iniciarmos e

simularmos um cenário de produção. Geralmente quando vamos montar esses testes

é necessário levantar com o cliente a quantidade de usuários que irá utilizar e-mail

bem como o tamanho médio de e-mails que trafegaram nessa estrutura.

Munidos de informações, precisamos montar o nosso teste para simular a

carga. Mas como vamos medir o desempenho do nosso ambiente? Apesar do Postal e

smtp-source fornecer uma estatística de entrega de mensagens ele não aponta onde

esta o gargalo do ambiente.

O boa notícia é que o Linux possui diversas ferramentas nativa para analise do


desempenho do ambiente. Vamos destacar algumas:

top – Mostra em tempo real o uso de memória, processamento, carga no

sistema e processos que mais ocupam o sistema.

free – Mostra em tempo real o status da memoria

vmstat - Mostra um variedade de informações referentes ao uso da CPU,

Memória, Processos, Paginação e I/O.

uptime – Mostra a carga do sistema

sysstat – É um conjunto de comandos (sar, iostat and mpstat) muito útil para

analise do sistema.

ifstat – Apresenta estatística das interfaces de rede

tcpstat – Apresenta estatística do protocolo tcp

Devemos lembrar que o próprio log do Postfix apresenta informações úteis

sobre o ambiente.

17.2.6. Realizando os testes

Para os testes vamos iniciar com 50 usuários simultâneos, com mensagens de

10 e 50 KB . Vamos utilizar a ferramenta Postal para essa tarefa.

Crie uma lista com e-mail dos usuários internos e alguns usuários válidos

externos(gmail, yahoo e etc).

Execute o comando(recomendável que seja em outra máquina):

postal -M 10 -m 50 -t 50 -c 5 -r 60 localhost lista-usarios.txt

Verifique se o postal não reportara erros.

Abra outro terminal e veja os logs do Postfix:

tail -f /var/log/mail.log

Verifique se não tem alguma anomalia no log.

Vamos analisar a carga do sistema com o comando “top”. Abra um terminal,


digite o comando “top” e observe a linha :

top - 15:49:00 up 5:27, 3 users, load average: 0.44, 0.44, 0.38

O parâmetro “load average” apresenta a carga do sistema. O “load average” é a

média da soma dos processos aguardando execução mais processos executando.

Observe que temos 3 resultados, o primeiro é a media do ultimo minuto, o segundo é

a média dos últimos 5 minutos e o terceiro é a média dos últimos 15 minutos.

Números altos representam grande carga no sistema e consequentemente lentidão

refletida para o usuário. Não existe um número mágico e ideal, mas em alguns casos

quando o “load_average” fica superior as 4.30 fica perceptível a lentidão para o

usuário. Mas o que provoca o aumento do “load average”? Alguns processos podem

estar esperando por CPU, rede, disco, pouca memória ou fazendo “swap”, esses são

os motivos mais comuns.

Vamos agora analisar o ambiente com o comando “vmstat”:

# vmstat -S M

procs -------memory------- -swap- --io-- -system-- ----cpu----

r b swpd free buff cache si so bi bo in cs us sy id wa

0 0 301 1425 97 591 0 0 14 23 68 257 1 1 97 1

O vmstat nos fornece uma gama de informações sobre o sistema, a coluna

“proc” representa os processos do sistema, a leta “r” é o número de processo

aguardando execução. As “boas práticas” recomendam que esse numero não supere

o dobro da quantidade de processadores na máquina. A letra “b” numero de

processos na fila, recomenda-se que esse parâmetro não seja maior que 0.

Na coluna “memory” temos 4 parâmetros; “swpd”, “free”, “buff” e “cache”.

Eles mostram o status da memoria Swap, Livre, em buffer e cache. Devemos analisar

a memoria livre e swap que são pontos críticos para o sistema, ou seja, se tenho

pouca memoria livre, o sistema pode começar a usar a memoria swap e isso

impactara na performance.

A Coluna Swap informa que a paginação esta acontecendo em disco. Esses

valores devem sempre permanecer em 0, caso contrário o load average irá amentar.

A coluna I/O, representa a quantidade de blocos enviados e recebidos por

segundo pelo disco ou placa de rede. Para verificar o tamanho do bloco de seu


sistema de arquivos basta digitar:

# stat -f /dev/sda1

File: "/dev/sda1"

ID: 0 Namelen: 255 Type: tmpfs

Block size: 4096 Fundamental block size: 4096

Blocks: Total: 367470 Free: 367387 Available: 367387

Inodes: Total: 367470 Free: 366578

Observe o valor Block size: 4096, essa é a capacidade de seu sistema de

arquivos.

A coluna system representa a troca de informações entre o processador e

outros dispositivos do sistema(disco, rede e etc). O parâmetro “in” representa o

número de interrupções por segundo e o parâmetro “cs” representa a troca de

contexto por segundo.

Finalmente a coluna CPU! Ela representa o status do processador, onde o

parâmetro “us” mostra a porcentagem de uso de processos do usuário incluído os

processos em “nice”. O parâmetro “sy” mostra a porcentagem de uso de processos

do kernel. O parâmetro “id” mostra a porcentagem da ociosidade do processador e o

parâmetro “wa” mostra, em porcentagem, o tempo de espera para I/O.

Outro comando que nos ajudara, é o “iostat”. Ele permite monitorar o

processamento de disco para identificarmos possíveis gargalos. Digite:

# aptitude install sysstat

# iostat -d 1 1

Linux 2.6.32-24-generic (srv) 01-12-2010 _x86_64_ (4 CPU)

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn

sda 5,64 91,70 162,99 2583652 4592552

dm-0 0,01 0,05 0,00 1298 56

sdb 0,00 0,03 0,00 833 0

Algumas informações são similares às do “vmstat”, como os parâmetros,

Blk_read/s e Blk_wrtn/s que são blocos lidos e escritos por segundo, o parâmetro

Blk_read e Blk_wrtn é representado em bytes e o parâmetros “tps” e quantidade de

transações por segundo de um dispositivo. Um numero alto de I/O de disco pode


significar problema e perda de performance. Geralmente o sistema de e-mail realiza

muita operação em disco, no caso do Postfix o I/O esta nas filas de mensagens é isso

requer discos de alta performance dependendo da carga do sistema de e-mail. Para

verificar a capacidade do seu disco consulte o fabricante fornecendo o modelo do

disco.

Outro ponto a analisar é a interface de rede que também pode ser o nosso

ponto de gargalo. Uma ferramenta bastante útil são “ifstat” e “iftop” que fornecem

estatísticas de uso das interfaces.

# aptitude install iftop ifstat

# ifstat

eth0 wlan0 ppp0

KB/s in KB/s out KB/s in KB/s out KB/s in KB/s out

0.00 0.00 0.00 0.00 0.00 0.00

0.00 0.00 0.00 0.00 0.00 0.00

0.00 0.00 0.00 0.00 0.00 0.00

0.00 0.00 0.00 0.00 0.00 0.00

O resultado é simples. Ele apresenta os dados de entrada e saída em Kilobytes

por segundo.


17.3. Laboratório

Pessoal, agora que já sabemos como realizar o nosso teste de stress e como

monitorar o ambiente, vamos aumentar a carga de testes em nosso ambiente.

Vamos aumentar gradativamente a carga dos testes. Iniciamos com 50 usuários

simultâneos, vamos para 100, 250, 400 e finalmente, 500. Dentro desse aumento é

necessário diagnosticar onde estão os problemas e apontar as soluções de melhorias

descritos no capítulo 13 e 14. Não esqueça de considerar:

• Filtros internos e externos

• Filas do Postfix

• Conexões SMTP In e Out (Quantidade)

• Numero de processos (Quantidade)

• I/O de Disco(iostat e vmstat)

• Se o hardware é suficiente ou não

O nosso objetivo é mostrar o que precisa ser feito para atender uma demanda

de 500 usuários, com a média diária de 100.000,00 mensagens, com o tamanho

médio variando de 10KB a 50KB.

Vamos considerar que o horário de trabalho é de 8 horas diárias. Fazendo um

cálculo simples:

100.000,00 / 8 = 8.000,00 por hora

Dividindo 8.000,00 / 60 minutos temos aproximadamente 134 e-mail por

minuto.

Com esses dados você pode utilizar a ferramenta Postal para simular esse

tráfego e os usuários.


Aponte os ajustes que foram feitos durante os testes e se é necessário melhorar

o hardware desse ambiente. Exemplo:

1 - Teste1 - 100 usuários com média de tamanho dos e-mail 10 a 50 Kb

1.1 - Parâmetros alterados:

- Amavis: MaxThreads: 20

2 – Problemas encontrados:

- O Postfix não comportou a quantidade de usuários simultâneos

3 – Conclusão e Solução dos problemas apontados.

3.1 – Aumentar o parâmetro default_proccess_limit para 100 do Postfix

no arquivo main.cf

Apêndice A - CyrusIMAP - 206

Apêndice A - CyrusIMAP


Introdução

O Cyrus IMAP (http://www.cyrusimap.org) é um servidor POP/IMAP de alta

performance altamente escalável, desenvolvido pela Carnegie Mellon University

(CMU), ele possibilita acessos simultâneos (leitura/escrita) a mesma caixa postal,

quota e regras de acesso (ACL) a qualquer caixa da hierarquia.

Nos repositórios estáveis das distribuições (Red Hat, Suse, Debian,etc...) até o

momento a versão disponibilizada do Cyrus Imap é antiga (2.2.13), que não é mais

atualizada. Portanto, recomenda-se a utilização da versão atual, 2.4 , que possibilita o

uso de replicação nativa e diversas melhorias para o ambiente Aggregator (veremos

sobre esse ambiente logo a frente), além diversas melhorias no código para

estabilidade, performance e segurança.

O Cyrus Imap opera somente com seu formato de armazenamento, não sendo

possível utilizar os formatos Maildir, Mailbox ou qualquer outra configuração. Por

padrão, o Cyrus Imap armazena as mensagens e meta-arquivos na mesma estrutura

de diretório, o armazenamento de mensagens é constituído por diversos arquivos

pequenos que não são acessados tão frequentemente, uma mensagem é acionada

somente quando o usuário abre a mesma, os meta-arquivos são separados em

arquivos por caixa postal (pasta): header, index, cache, expunge e squat, sendo os

três primeiros para indexação e recuperação dos cabeçalhos das mensagens, o

expunge para controle de remoção atrasada se essa opção estiver habilitada, o

arquivo squat contém uma indexação específica para pesquisa de mensagens, com

ganho de 20 a 30% em relação a indexação padrão para operações que envolvam

pesquisa, sendo o maior dos meta-arquivos, se a mensagem não estiver referenciada

neste arquivo será recuperada através da indexação normal, porém com desempenho

inferior.


Prática Dirigida

Para esse cenário iremos utilizar o CyrusSASL que é uma interface de

autenticação com bases de usuários(SQL e LDAP) . Nesse contexto o SASL realiza

uma ponte entre o Cyrus e o OpenLDAP.

Instalando o SASL

# aptitude install sasl2-bin libsasl2-modules-ldap

Habilitando a autenticação SASL

# vi /etc/default/saslauthd

START=yes

MECHANISMS="ldap sasldb"

Integrando e Configurando o SASL com OpenLDAP

# vi /etc/saslauthd.conf

ldap_servers: ldap://127.0.0.1


ldap_port: 389

ldap_version: 3

ldap_search_base: dc=empresa

ldap_auth_method: bind

ldap_filter: (&(objectClass=qmailUser)(mail=%u@%d))

Criando o usuário de administração global( coloque a senha 123)

# saslpasswd2 -c admin

Reinicie o saslauth:

# /etc/init.d/saslauth restart

Testando a Autenticação SASL

# testsaslauthd -u joao -r matrizX.com.br -p 123

0: OK "Success."

Instalando o CyrusIMAP

# aptitude install cyrus-admin-2.2 cyrus-imapd-2.2

O CyrusIMAP possui basicamente dois aquivos de configuração o cyrus.conf e

imapd.conf, ambos localizados em /etc/.

Edite o cyrus.conf:

START {

# do not delete this entry!

recover cmd="/usr/sbin/ctl_cyrusdb -r"

# this is only necessary if idlemethod is set to "idled" in

imapd.conf

#idled cmd="idled"

# this is useful on backend nodes of a Murder cluster

# it causes the backend to syncronize its mailbox list with

# the mupdate master upon startup

#mupdatepush cmd="/usr/sbin/ctl_mboxlist -m"


# this is recommended if using duplicate delivery suppression

delprune cmd="/usr/sbin/cyr_expire -E 3"

# this is recommended if caching TLS sessions

tlsprune cmd="/usr/sbin/tls_prune"

}

SERVICES {

# --- Normal cyrus spool, or Murder backends ---

# add or remove based on preferences

imap cmd="imapd -U 30" listen="imap" prefork=0

maxchild=100

#imaps cmd="imapd -s -U 30" listen="imaps" prefork=0

maxchild=100

pop3 cmd="pop3d -U 30" listen="pop3" prefork=0

maxchild=50

#pop3s cmd="pop3d -s -U 30" listen="pop3s" prefork=0

maxchild=50

nntp cmd="nntpd -U 30" listen="nntp" prefork=0

maxchild=100

#nntps cmd="nntpd -s -U 30" listen="nntps" prefork=0

maxchild=100

# At least one form of LMTP is required for delivery

# (you must keep the Unix socket name in sync with imap.conf)

#lmtp cmd="lmtpd" listen="localhost:lmtp" prefork=0

maxchild=20

lmtpunix cmd="lmtpd"

listen="/var/run/cyrus/socket/lmtp" prefork=0 maxchild=20

# ----------------------------------------------

# useful if you need to give users remote access to sieve

# by default, we limit this to localhost in Debian

sieve cmd="timsieved" listen="localhost:sieve"

prefork=0 maxchild=100

# this one is needed for the notification services

notify cmd="notifyd"


listen="/var/run/cyrus/socket/notify" proto="udp" prefork=1

# --- Murder frontends -------------------------

# enable these and disable the matching services above,

# except for sieve (which deals automatically with Murder)

# mupdate database service - must prefork at least 1

# (mupdate slaves)

#mupdate cmd="mupdate" listen=3905 prefork=1

#mupdate cmd="mupdate -m" listen=3905 prefork=1

# proxies that will connect to the backends

#imap cmd="proxyd" listen="imap" prefork=0

maxchild=100

#imaps cmd="proxyd -s" listen="imaps" prefork=0

maxchild=100

#pop3 cmd="pop3proxyd" listen="pop3" prefork=0

maxchild=50

#pop3s cmd="pop3proxyd -s" listen="pop3s" prefork=0

maxchild=50

#lmtp cmd="lmtpproxyd" listen="lmtp" prefork=1

maxchild=20

# ----------------------------------------------

}

EVENTS {

# this is required

checkpoint cmd="/usr/sbin/ctl_cyrusdb -c" period=30

# this is only necessary if using duplicate delivery

suppression

delprune cmd="/usr/sbin/cyr_expire -E 3" at=0401

# this is only necessary if caching TLS sessions

tlsprune cmd="/usr/sbin/tls_prune" at=0401

# indexing of mailboxs for server side fulltext searches


# reindex changed mailboxes (fulltext) approximately every

other hour

#squatter_1 cmd="/usr/bin/nice -n 19 /usr/sbin/squatter

-s" period=120

# reindex all mailboxes (fulltext) daily

#squatter_a cmd="/usr/sbin/squatter" at=0517

}

O arquivo cyrus.conf determina o comportamento do daemon do Cyrus e seus

serviço e é composto por três clausulas:

START, SERVICES e EVENTS

O START é executado quando o Cyrus é iniciado ou reiniciado, geralmente

esses comandos são de verificação das bases e checagem de expurgo de mensagens.

O SERVICE determina o comportamento dos serviços IMAP, POP3, SIEVE e

LMTP definindo quantos processos serão iniciardos e em qual posta eles irão

responder.

O EVENTS e similar ao START, porém ele é checado diariamente

O aquivo imapd.conf como o próprio nome diz, configura o comportamento do

serviço IMAP do Cyrus e ainda define o comportamento de armazenamento, do

serviços SIEVE e POP.

Vejamos os principais parâmetros. Edite conforme o modelo abaixo:

# Local onde será armazenada o banco do Cyrus

configdirectory: /var/lib/cyrus

# Partição padrão de armazenamento de mensagens

defaultpartition: default

# local onde será armazenada as mensagens no disco

partition-default: /var/spool/cyrus/mail

# Se a separação de pasta e subpastas seguira o padrão unix “/”

unixhierarchysep: yes

# Definição de quota padrão

autocreatequota: 131072 # 128MB


# Usuários que tem permissão de admin no Cyrus

admins: admin

# Local de armazenamento dos scripts sieve dos usuários

sievedir: /var/spool/sieve

# Se permite autenticação em PLAIN text

allowplaintext: yes

# mecanismos de autenticação disponíveis

sasl_mech_list: PLAIN LOGIN

# Habilita o uso de domínios e usuários virtuais

virtdomains: yes

# Dominio padrão caso não seja especificado nenhum

defaultdomain: matrizx.com.br

# Método de autenticação auxprop saslauthd separados por espaço

sasl_pwcheck_method: auxprop saslauthd

# Local do socket lmtp

lmtpsocket: /var/run/cyrus/socket/lmtp

# prefixo do log do cyrus

syslog_prefix: cyrus

Reinicie o CyrusIMAP

# /etc/init.d/cyrus2.2 restart

CryAdm – Administração do CyrusIMAP

Para administração do Cyrus Imap, é utilizado o utilitário cyradm, que é uma

linha de comando (shell) desenvolvida em Perl para execução de operações

administrativas. Na configuração atual do arquivo /etc/imapd.conf, o parâmetro

unixhierarchsep está definido como YES, portanto o separador será o caractere “/” .

Se estivesse definido como NO o separador seria o caractere “.” .

Para conectar ao servidor utilizando o cyradm utilize a sintaxe abaixo:

cyradm -u admin localhost


Nesse exemplo, o usuário admin possui privilégio administrativo no servidor

que estamos conectando: localhost.

Uma vez conectado na shell cyradm com privilégio administrativo, é possível

executar as operações relacionadas abaixo:

createmailbox (create,cm):

Permite criar caixas postais, seja a caixa principal de um usuário (INBOX) ou

pastas na hierarquia.

Sintaxe para criação:

cyradm> cm user/joao

No exemplo acima, a caixa principal do usuário joao está sendo criada, para

criação de uma pasta na hierarquia deste usuário a sintaxe é esta:

cyradm> cm user/joao/Drafts

Neste exemplo, estamos criando a pasta Drafts para o usuário joao, destacando

que as pastas Rascunhos, Lixeira e Enviados que são apresentadas nos clientes de E-

mail, no IMAP são criadas como Drafts, Trash e Sent, respectivamente.

Createmailbox é o comando principal e o valores apresentados ente parênteses

são apelidos para o mesmo.

listmailbox (lm):

Lista as caixas postais

Consulta de um usuário específico:

cyradm> lm user/joao

Consulta de toda a hierarquia de um usuário específico:

cyradm> lm user/joao*

Consulta de todas as caixas postais principais (INBOX) do ambiente:

cyradm> lm user/%


Consulta de todas as caixas postais, incluindo a hierarquia do ambiente:

cyradm> lm user/*

deletemailbox (delete,dm):

Permite remover caixas postais, seja a caixa principal de um usuário (INBOX)

ou pastas na hierarquia.

cyradm> dm user/joao

listaclmailbox (listacl, lam):

Apresenta as permissões para uma determinada caixas postal.

Cyradm> lam user/fabio

As permissões no Cyrus Imap, também conhecidas como ACL (Access Control

List) são representadas com os caracteres conforme abaixo, que devem ser

combinados:

• l: Representação da palavra “lookup” do inglês, define que o usuário pode

visualizar a existência da pasta, isso é , a pasta irá aparecer em sua listagem

• r: Representação da palavra “read” do inglês, define que o usuário pode

visualizar o conteúdo da pasta.

• s: Representação da palavra “seen” do inglês, define que o usuário pode

manter a relação de mensagens visualizadas ou não na pasta.

• w: Representação da palavra “write” do inglês, define que o usuário pode

escrever na pasta.

• I: Representação da palavra “insert” do inglês, define que o usuário pode

inserir conteúdo em uma pasta, como copiar, mover e inserir mensagens.

• k: Define que o usuário pode criar pastas em sua hierarquia.

• x: Define que o usuário pode excluir pastas em sua hierarquia.

• a: Representação da palavra “administer” do inglês, define que o usuário pode

executar tarefas administravas na pasta.


• t: Define que o usuário pode apagar mensagens na pasta.

Pode ser utilizada a palavra “all” para definir todas as permissões.

setaclmailbox (setacl, sam):

Efetua a criação de regras de acesso com os critérios apresentados acima.

Sintaxe para definição de ACL:

cyradm> sam user/joao admin all

Neste exemplo estamos concedendo ao usuário admin todas as permissões na

pasta do usuário joao.

deleteaclmailbox (deleteacl, dam):

Efetua a remoção de regras de acesso.

cyradm> dam user/joao admin all

setquota (sq):

Define a quota para a caixa posta, o Cyrus Imap permite a definição de uma

quota padrão que é definida na caixa principal e criação de quotas específicas para

outras caixas da hierarquia.

Sintaxe para definição de quota:

cyradm> sq user/joao 131072

A quota é sempre definida em bytes.

listquota (lq):

Lista a quota da pastsa informada.

Sintaxe para listagem de quota:

cyradm> lq user/joao


Domínios Virtuais no CyrusIMAP

Conceitos

No nosso cenário temos mais de um domínio em uma mesma estrutura, o Cyrus

Imap possui suporte para armazenar caixas postais IMAP/POP para diversos

domínios, sendo assim o usuário [email protected] e [email protected] podem

existir no mesmo servidor.

Para que isso seja possível, é necessário configurar o Cyrus para mapear

corretamente o usuário ao seu domínio quando a caixa postal for acessada, existem

duas formas :

• O usuário efetua o login informando usuário e o domínio ao qual

pertence

• Controlar através do IP ou endereço, o servidor irá resolver o domínio

através da interface ou endereço que a conexão foi estabelecida.

Ambos os métodos são configurados com a diretiva virtdomain no arquivo de

configuração do Cyrus, que deve ser definido como on, yes, 1 ou true. Se a diretiva

for definida como userid somente o primeiro método será possível.

Para utilizar domínios virtuais é preciso entender os principais conceitos

explicados abaixo:

• Todo usuário pertence a um domínio – Todo usuário pertence a algum

domínio,usuários que não estiverem especificados estão cadastrados no

domínio default.

• Cada caixa postal pertence a somente um domínio

• Usuários de domínios diferentes não podem interagir - Nas operações do

servidor IMAP, usuários de domínios diferentes não podem interagir, por

exemplo, não é possível compartilhar a caixa do usuário [email protected]

com [email protected].






• Administradores e administradores globais – É possível definir

administradores restritos a cada domínios e administradores globais, que

podem administrar todos os domínios implementados.

Configurando o domínio virtual

Conforme visto anteriormente, o suporte a domínios virtuais é habilito através

da diretiva virtdomains no arquivo imapd.conf.

virtdomains: yes

Se estiver migrando de uma solução com um único domínios, o nome do

domínio existente deve ser especificado na diretiva defaultdomain também no

arquivo imapd.conf.

Em novas instalações é recomendado que o domínio principal da organização

seja definido na diretiva defaultdomain, visando facilitar a administração.

Arquivo imapd.conf com as configurações para os domínios matriz.com.br e

filial.com.br:

virtdomains: yes

defaultdomain: matriz.com.br

Nesta configuração temos o “admin” é um administrador global.

Criando usuário com domínio virtual

Para criar usuários acesso cyradm

# cryadm -u admin localhost

cm user/[email protected]

Listando usuários do domínio

lm *@matrizx.com.br


Configurando o Postfix para entrega de mensagens no Cyrus

Edite o arquivo /etc/postfix/master.cf desabilitando o CHROOT conforme abaixo

lmtp unix - - n - - lmtp

Edite o arquivo /etc/postfix/main.cf conforme abaixo:

mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp

virtual_transport = lmtp:unix:/var/run/cyrus/socket/lmtp

local_transport = virtual


virtual_alias_maps = ldap:/etc/postfix/ldap/vma.cf


Adicionar o usuário do Postfix no grupo Mail

# adduser postfix mail

Criando os arquivos vmd.cf, vms.cf e vma.cf :




server_port = 389

bind_dn = cn=admin,dc=dominios,dc=empresa

bind_pw = 123

search_base = dc=dominios,dc=empresa



version = 3

bind = yes

timeout = 30

# vi /etc/postfix/ldap/vma.cf


server_port = 389



bind_pw = 123


query_filter = (&(objectClass=qmailUser)(mailAlternateAddress=%s))


version = 3

bind = yes

timeout = 30



server_port = 389


bind_pw = 123




version = 3

bind = yes

timeout = 30

Reinicie o Postfix


Para realizar o teste de envio utilize o comando telnet e verifique se o Postfix

realiza a entrega na caixa postal do usuário


Escalabilidade do Cyrus IMAP: Cyrus Aggregator

Para escalabilidade do serviço IMAP, é possível utilizar o Cyrus Aggregator

(solução também conhecida como Cyrus Murder), neste ambiente é possível dividir

as caixas postais IMAP e POP entre diversos servidores de forma transparente aos

usuários, podendo ser acessado ou não por um ponto único.

A solução possui três classes de servidores: Frontend, Backend e Mupdate

(Murder). Os clientes IMAP conectam aos servidores Fontends que por sua vez

realizam a consulta no servidor Mupdate obtendo a localização da caixa postal do

cliente conectado, o servidor Mupdate informam aos Fontends que estabelecem a

comunicação com o Backend trazendo a caixa postal do usuário. Os servidores

Backend armazenam as caixas postais e informam ao servidor Mupdate a sua

localização, permissões e mudanças, que por sua vez sincroniza com os Frontends a

posição das caixa postais. Segue abaixo a figura explicativa:

Apêndice B - Entregando mensagens com o Maildrop - 223

Apêndice B - Entregando mensagens

com o Maildrop


Introdução

Maildrop é um agente de entrega local também conhecido na estrutura de um

sistema de emails por MDA (Mail Delivery Agent), encarregado de depositar

mensagens localmente, ou seja, gravá-las efetivamente na caixa postal dos

destinatários. Não é uma alternativa ao Sendmail, Exim, Qmail ou Postfix, pois estes

servem para enviar mensagens entre máquinas distintas usando o SMTP (Simple

Mail Transfer Protocol). O Postfix pode ser configurado para utilizar o Maildrop

como o seu MDA. Para verificar essa condição basta procurar pelo parâmetro

mailbox_command no arquivo /etc/postfix/main.cf por meio do seguinte comando:

# grep mailbox_command /etc/postfix/main.cf

mailbox_command = /usr/bin/maildrop -d ${USER}

Caso o comando retorne o parâmetro mailbox_command, verifique se ele está

direcionado para o Maildrop, conforme apresentado no quadro anterior.

O Maildrop é extremamente poderoso para configurar regras, possuindo muitas

facilidades e recursos interessantes para reforçar as funcionalidades de um servidor

de e-mails. Um exemplo é a possibilidade de integração com bases de dados como

Mysql e LDAP. Um bom começo para capacitar-se com o Maildrop é ler o que tem no

seu manual de exemplos que apresenta desde o simples redirecionamento de

mensagens até configurações mais complexas, como, por exemplo, tratar de forma

diferente mensagens maiores que uma quantidade pré-determinada de Kbytes,

responder automaticamente mensagens, evitar receber a mesma mensagem

repetidas vezes, dentre outras coisas.

Estas regras podem ser individuais para cada usuário ou podem ser globais,

sendo aplicada, nesse caso, a todos os usuários. No caso de serem individuais, elas

devem estar em um arquivo de nome .mailfilter no diretório home do usuário que

deve estar montado no servidor de e-mail.

A sintaxe das regras do Maildrop assemelha-se àquela utilizada em linguagem

C.

A seguir, é exibido um exemplo de uma regra que filtra o conteúdo a partir do

título (Subject) de uma mensagem:


if ( /^Subject: rosebud/ )

{

...

some

really

long

set

of

instructions

...

}

Se o administrador do sistema quiser que uma regra se aplique a todos os

usuários, ele deve colocá-las em /etc/maildroprc.

O processo de leitura dos arquivos acontece da seguinte forma:

Se o arquivo /etc/maildroprc existe, então o Maildrop irá ler as instruções de

entrega de e-mail a partir desse arquivo. Caso contrário, o Maildrop irá procurar o

arquivo $HOME/.mailfilter do usuário e ler as instruções de entrega da mensagens a

partir desse outro arquivo. Caso nenhum dos arquivos exista, o Maildrop não

descarta a mensagem mas, sim, a salva na caixa padrão.

Opções do Maildrop :

• -a

◦ Gera um erro temporário caso os mecanismo de autenticação

falharem

• -A “Header Value”

◦ Adiciona valor no cabeçalho da mensagem

• -d user

◦ Permite a entrega com o usuário corrente ou seja o usuário

postfix, vmail ou remetente da mensagem.


• -f address

◦ Define a variável de remetente da mensagem

Regras úteis

Mensagens grandes (que possuam mais de 1000 linhas ou que tenham mais de

60000 bytes) serão direcionadas para a pasta LARGE:

if ($LINES > 1000 || $SIZE > 60000)

{

to "mail/IN.large"

}

Usando comparadores “OR” e “AND”

No primeiro exemplo, mostrado abaixo, verifica-se se a quantidade de linhas da

mensagem é superior que 1000 “E” (AND) se o seu tamanho é maior que 60000

bytes. Caso positivo, a mensagem é movida para a pasta “IN.large”. O operador AND,

nesse caso, é identificado pelos caracteres “&&”.

if ($LINES > 1000 && $SIZE > 60000)

{

to "mail/IN.large"

}

De forma análoga, no exemplo a seguir, é verificado se a mensagem possui

mais que 1000 linhas OU (OR) se ela possui mais que 60000 bytes. O operador OR é

representado pelos caracteres “||”.

if ($LINES > 1000 || $SIZE > 60000)

{

to "mail/IN.large"

}

Direcionando mensagens para a pasta SPAM


Se devidamente configurados, muitos servidores de e-mails podem fazer

críticas com relação a mensagens que são recebidas no sentido de tentar classificá-

las ou não como SPAMs. No próprio Postfix existem diversos mecanismos e

ferramentas que podem ser integradas para essa finalidade como o próprio

SpamAssassin, discutido e apresentado anteriormente.

Uma vez classificada como SPAM, uma mensagem, na maioria dos casos, não é

descartada pelo servidor de e-mails, apenas um cabeçalho chamado “X-DSPAM-

Result” é adicionado ao e-mail de forma que algum componente do sistema possa

interpretá-lo para, se for o caso, tomar alguma medida.

Muitos MUAs (Mail User Agents) costumam levar em consideração o valor

desse campo para já sinalizar ao usuário que a mensagem está classificada como

SPAM. Nesse caso, o usuário pode ainda configurar o próprio MUA para já executar

alguma ação em mensagens com essas características, movendo-as, por exemplo,

para uma pasta separada ou ainda colocando-as na lixeira.

Essa alternativa, entretanto, fica sob responsabilidade do próprio usuário e

pode não ser a solução mais adequada para servidores de e-mails com muitos

usuários com perfis bastante diferenciados. Nesse caso, pode-se utilizar o próprio

Maildrop para já criar um nível de intervenção sobre essas mensagens.

Configurando Maildrop para entrega de mensagens

Nesta configuração, a forma de entrega das mensagens na caixa postal do

usuário será pelo Maildrop e não mais pelo Postfix (daemon Virtual) , ou

seja, o MDA será o Maildrop.

Antes de mais nada vamos instalar o pacote courier-maildrop:

# aptitude install courier-maildrop


Configurando o Maildrop para consultar o OpenLDAP.

# vi /etc/maildrop.config

hostname 127.0.0.1

basedn dc=dominios,dc=empresa

filter (&(objectclass=qMailUser)(accountStatus=active))

binddn cn=admin,dc=empresa

bindpw 123

timeout 5

search_method mail

default_uidnumber 240

default_gidnumber 240

mail_attr mail

uid_attr uid

uidnumber_attr uidnumber

gidnumber_attr gidnumber

maildir_attr mailMessageStore

homedirectory_attr homeDirectory

quota_attr mailQuota

Configurando o maildroprc para colocar as mensagens marcadas com Spam na

pasta Spam.

# vi /etc/courier/maildroprc

# commands and variables for making the mail directories

maildirmake=/usr/bin/maildirmake

mkdir=/bin/mkdir

rmdir=/bin/rmdir

MDIR=Maildir

MAILDIR=$DEFAULT

# Cria o diretorio do usuário caso não exista

`test -d $MAILDIR`

if ($RETURNCODE != 0)

{

`$mkdir -p $MAILDIR`

`$maildirmake $MAILDIR`


}

# Cria o diretorio Spam

JUNK_FOLDER=.Spam

_JUNK_DEST=$MAILDIR/$JUNK_FOLDER/

`test -d $_JUNK_DEST`

if ($RETURNCODE != 0 )

{

`$maildirmake $_JUNK_DEST`

ècho INBOX.Spam >> $MAILDIR/courierimapsubscribed`

}

# Cria o diretorio Enviados

SENT_FOLDER=.Sent

_SENT_DEST=$MAILDIR/$SENT_FOLDER/

`test -d $_SENT_DEST`


{

`$maildirmake $_SENT_DEST`

ècho INBOX.Sent >> $MAILDIR/courierimapsubscribed`

}

# Cria o diretorio Lixeira

TRASH_FOLDER=.Trash

_TRASH_DEST=$MAILDIR/$TRASH_FOLDER/

`test -d $_TRASH_DEST`


{

`$maildirmake $_TRASH_DEST`

ècho INBOX.Trash >> $MAILDIR/courierimapsubscribed`

}

# Cria o diretório Rascunho

DRAFT_FOLDER=.Drafts

_DRAFT_DEST=$MAILDIR/$DRAFT_FOLDER/

`test -d $_DRAFT_DEST`


{

`$maildirmake $_DRAFT_DEST`

ècho INBOX.Drafts >> $MAILDIR/courierimapsubscribed`

}


# Cria o diretorio CUR

CUR_FOLDER=cur

_CUR_DEST=$MAILDIR/$CUR_FOLDER/

`test -d $_CUR_DEST`


{

`$mkdir -p $_CUR_DEST`

}

# Cria o diretorio NEW

NEW_FOLDER=new

_NEW_DEST=$MAILDIR/$NEW_FOLDER/

`test -d $_NEW_DEST`


{

`$mkdir -p $_NEW_DEST`

}

# Cria o diretorio TMP

TMP_FOLDER=tmp

_TMP_DEST=$MAILDIR/$TMP_FOLDER/

`test -d $_TMP_DEST`


{

`$mkdir -p $_TMP_DEST`

}

# Se a mensangem estive marcada como spam envia para a pasta SPAM

if (/^X-Spam-Status:.*Yes/)

{

exception {

to $MAILDIR/.Spam/

}

}

Edite o /etc/postfix/main.cf do Postfix


# vi /etc/postfix/main.cf

mailbox_command = /usr/bin/maildrop

maildrop_destination_recipient_limit=1

virtual_transport = maildrop

mailbox_transport = maildrop

local_trasport = virtual


virtual_alias_maps = ldap:/etc/postfix/ldap/vma.cf


Criando os arquivos vmd.cf, vms.cf e vma.cf :




server_port = 389


bind_pw = 123




version = 3

bind = yes

timeout = 30

# vi /etc/postfix/ldap/vma.cf


server_port = 389


bind_pw = 123


query_filter = (&(objectClass=qmailUser)(mailAlternateAddress=%s))


version = 3

bind = yes

timeout = 30




server_port = 389


bind_pw = 123




version = 3

bind = yes

timeout = 30

Reinicie todos os serviços envolvidos:



# /etc/init.d/spamassassin restart

# /etc/init.d/clamav-daemon restart

Testando o Maildrop

Utilize o Cliente de E-mail (ICE-Dove ou Evolution) anexando o vírus de testes

EICAR e verifique os logs do Postfix.

Faça o mesmo enviando uma mensagem com o arquivo

“/usr/share/doc/spamassassin/examples/sample-spam.txt” como anexo. E fique de

olho nos logs.


Exercícios

1. Qual a função do Maildrop?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

2. Quais as principais vantagens de utilizar um MDA avançado?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

3. Qual o impacto do Maildrop sobre o desempenho de entrega das mensagens?

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

Apêndice C - CourierIMAP POP3/IMAP - 234

Apêndice C - CourierIMAP

POP3/IMAP


Introdução

Servidor Courier

O Courier é um sistema MTA integrado baseado em protocolos abertos , tais

como SMTP/ESMTP, IMAP, POP3, LDAP, SSL, e HTTP. Neste treinamento, serão

utilizados, especificamente, os componentes Courier-IMAP, Courier-IMAPS, Courier-

POP e Courier-POPS.

O Courier-IMAP é uma implementação bastante robusta do protocolo IMAP,

sendo capaz de gerenciar centenas de milhares de contas de e-mails em um mesmo

servidor, o que o torna adequado para ambientes de pequenas, médias e grandes

instituições. Abaixo estão relacionadas algumas de suas principais características:

• Autenticação utilizando certificados SSL;

• Distribuição de caixas de correio entre vários servidores;

• Segurança como por exemplo a capacidade de restrição do número

máximo de logins;

• Compartilhamento de pastas entre grupos de usuários;

• Integração com repositórios de dados tais como o LDAP e bancos de

dados relacionais como, por exemplo, o MySQL e o PostgreSQL.

Instalando Courier-Imap

# aptitude install courier-imap courier-imap-ssl courier-pop courier-

pop-ssl courier-authlib-ldap

Configurando Courier - Autenticação com OpenLDAP

# vi /etc/courier/authdaemonrc

authmodulelist="authldap"

authmodulelistorig="authldap"

daemons=5


authdaemonvar=/var/run/courier/authdaemon

DEBUG_LOGIN=0

DEFAULTOPTIONS=""

LOGGEROPTS=""

É importante perceber que no arquivo de configuração authldaprc o separador

entre a variável e seu valor, corresponde a dois “tabs” ou duas tabulações. Além disso

não pode haver espaços em branco no fim da linha, após o valor de cada variável.

Esses cuidados são determinantes para o funcionamento, ou não do Courier.

# vi /etc/courier/authldaprc

LDAP_URI ldap://localhost

LDAP_PROTOCOL_VERSION 3

LDAP_BASEDN dc=empresa

LDAP_BINDDN cn=admin,dc=empresa

LDAP_BINDPW 123

LDAP_TIMEOUT 5

LDAP_MAIL mail

LDAP_FILTER (objectClass=qmailUser)

LDAP_GLOB_UID vmail

LDAP_GLOB_GID vmail

LDAP_HOMEDIR homeDirectory

LDAP_MAILDIR mailMessageStore

LDAP_MAILDIRQUOTA mailQuotaSize

LDAP_FULLNAME cn

LDAP_CRYPTPW userPassword

LDAP_DEREF never

LDAP_TLS 0


Reiniciando o Serviço Courier-IMAP

# /etc/init.d/courier-authdaemon restart

# /etc/init.d/courier-imap restart

# /etc/init.d/courier-imap-ssl restart

ou

# for cada in `ls /etc/init.d/courier-*` ; do $cada restart ; done

Criando a caixa postal do usuário

Para poder acessar a caixa postal do usuário, ela tem que existir. Pode-se

configurar o MDA para criar a caixa postal automaticamente quando da chegada da

primeira mensagem. Entretanto, aqui, vamos fazê-lo manualmente.

# mkdir -p /home/vmail/domains/matrizX.com.br/joao

# maildirmake /home/vmail/domains/matrizX.com.br/joao/Maildir

# chown vmail: /home/vmail -R

Utilize o Cliente de E-mail de sua preferência para acessar a caixa postal

Esse cenário de configuração considera que você esteja utilizando o Postfix

com Maildrop

Postfix Trafego Intenso 434 v12

Documents

Transcript of Postfix Trafego Intenso 434 v12