Replicação Multi-Master no OpenLDAP 2.4
Posted by admin in Software Livre on November 15th, 2009
As versões mais antigas, era possível efetuar a replicação somente via slurpd e na configuração Master para N Slaves. Com o lançamento da versão 2.4, o OpenLDAP passou a proporcionar diversas formas de replicação, como Mirror Mode, N-Way Multimaster e ainda Master-Slave.
Este pequeno tutorial, explica de forma rápida a configuração para Alta-disponibilidade (N-Way Multimaster) para OpenLDAP 2.4, que sempre foi uma das principais solicitações da comunidade.
Configurando do Slapd
Fazer o setup manual do slapd.conf, ex:
# schemas include "/usr/loca/etc/openldap/schema/core.schema" include "/usr/loca/etc/openldap/schema/corba.schema" include "/usr/loca/etc/openldap/schema/cosine.schema" include "/usr/loca/etc/openldap/schema/inetorgperson.schema" include "/usr/loca/etc/openldap/schema/misc.schema" include "/usr/loca/etc/openldap/schema/nis.schema" include "/usr/loca/etc/openldap/schema/openldap.schema" moduleload back_bdb database bdb suffix "ou=Mail, o=Teste" rootdn "cn=root, ou=Mail, o=Teste" rootpw directory /var/db/openldap-data # Indexes index objectClass eq index cn,uid,associatedDomain eq
Feita a configuração básica, é necessário converter o arquivo de configuração para o novo “estilo” de configuração para o OpenLDAP 2.4. Isto pode ser feito com o commando slaptest.
root# mkdir /usr/local/etc/openldap/slapd.d/ root# slaptest -f /usr/local/etc/openldap/slapd.conf -F /usr/local/etc/openldap/slapd.d/
Serão gerados os arquivos de configuração da versão 2.4 do OpenLDAP.
É necessário também alterar os seguintes arquivos adicionando os seguintes atributos (em todos os nós):
Em /usr/local/etc/openldap/slapd.d/cn=config.ldif:
# alterar o número para cada nó olcServerID: 1
e
Em /usr/local/etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif:
olcRootPW: <senha>
A partir daí, o serviço deve ser iniciado.
Configurando a replicação
Com o novo tipo de configuração, tudo deve ser feito via arquivos LDIF e alterados na database cn=config do OpenLDAP, via ldapmodify.
Crie o um arquivo setup.ldif com o seguinte conteúdo:
dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 ldap://<server1> olcServerID: 2 ldap://<server2> dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://<server1> binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=ldap://<server2> binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE
Adicionar ao diretório
root# ldapmodify -x -D"cn=config" -w -f setup.ldifIsto fará a replicação da database “cn=config”. Fazer o mesmo processo no LDAP SLAVE.
Replicando a base de dados “ou=Mail,o=Teste”.
A base de dados cn=config, é importante pois desta forma, todos os nós serão configurados automaticamente, quando for feito o setup para a replicação da base “ou=Mail,o=Teste”, que possui os dados importantes.
Criar um arquivos data.ldif:
dn: olcDatabase={1}bdb,cn=config changetype: modify add: olcMirrorMode: olcMirrorMode: TURE add: olcLimits olcLimits: dn.exact="cn=root,ou=Mail,o=Teste" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited #replica 1 add: olcSyncRepl olcSyncRepl: rid=003 provider=ldap://<server1> binddn="cn=root,ou=Mail,o=Teste" bindmethod=sinple credentials=secret searchbase="ou=Mail,o=Teste" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 #replica 2 add: olcSyncRepl olcSyncRepl: rid=004 provider=ldap://<server2> binddn="cn=root,ou=Mail,o=Teste" bindmethod=sinple credentials=secret searchbase="ou=Mail,o=Teste" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 # Habilita o syncprov dn: olcOverlay=syncprov, olcDatabase={1}bdb,cn=config changetype: add objectClass: olcOverLayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov
Feito isso, adicionar os dados no Diretório:
root# ldapmodify -x -D"cn=config" -w -f data.ldifPronto! Está funcionando!
IMAP Proxy
Posted by admin in Software Livre on June 30th, 2009
IMAP Proxy
Parece óbvio, mas poucos se lembram da possibilidade, de “cachear” as conexões IMAP em uma única, a fim de diminuir as requisições IMAP vindas por HTTP (webmails, em específico), pois como o HTTP é um protocolo “stateless”, ou seja, não mantém uma conexão persistente e automaticamente cada REQUEST é uma nova conexão IMAP em seu servidor.
Para resolver isto, existe a solução de Proxy IMAP. Existem alguns software para isto, mas no momento estou usando o “imapproxy” que pode ser baixado no site do projeto, www.imapproxy.org.
O software é extremamente simples e intuitivo, não precisando de mais de 10 minutos pra entender e colocar no ar.
A característica principal do software é manter uma conexão única por usuário. Ele mantém as credenciais enviadas pelo client cacheadas e uma conexão persistente com o servidor IMAP.
Instalação
Baixe o software no site do projeto:
1 | user ~/ $ wget http://www.imapproxy.org/downloads/up-imapproxy-1.2.6.tar.gz |
O imapproxy depende de ncurses para compilar, então, baixe-o e instale-o!
Compile-o e instale-o, ou então busque o pacote da sua distro.
Para os Slackers de plantão:
1 2 3 4 5 | user :~$ tar xvzf up-imapproxy-1.2.6.tar.gz user :~$ cd up-imapproxy-1.2.6/ user :~/up-imapproxy-1.2.6$ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var user :~/up-imapproxy-1.2.6$ make user :~/up-imapproxy-1.2.6$ sudo make install |
Instalado, a configuração é extremamente simples, mas vou explicar algumas delas.
O arquivo de configuração de acordo com nossa instalação estará em /etc/imapproxy.conf.
1 2 3 4 5 6 7 | server_hostname 200.x.x.x # Este será o servidor de destino cache_size 100 # Número de conexões máximas que poderão ser "proxyadas" listen_port 143 # Onde o imapproxy escutará as conexões # listen_address 127.0.0.1 # Neste caso se indefinido (comentado), irá escutar todas os endereços. server_port 1143 # Porta do servidor de destino, neste caso, estou usando o IMAP em uma porta diferente. cache_expiration_time 300 # Tempo do cache em segundos proc_username mail # Usuário que irá rodar o processo do imapproxy |
Para configuração básica (provavelmente a maioria dos casos), estes parâmetros serão os utilizados, mas existem alguns poucos a mais que poderão ser alterados de acordo com a necessidade.
Para iniciar o serviço é somente executar o daemon:
1 | user ~$ sudo imapproxy |
Pronto, seu IMAP Proxy está no ar!
Os atuais MDAs e as linguagens de filtragem de e-mail (parte 3)
Posted by admin in Programação, Software Livre on April 20th, 2009
Continuando minha série de Posts sobre linguagens de filtragem de e-mail, escrevo enfim, sobre o Sieve, que é de longe, a mais importante das linguagens de filtragem, devido sua simplicidade, facilidade de aprendizado, e por ser um padrão de linguagem para filtragem de correio.
Assim como nos outros Posts sobre linguagens de filtragem de correio, este último também não tem intenção nenhuma de ensinar como configurá-los em seus servidores, mas sim, falar sobre a linguagem e mostrar alguns exemplos de scripts.
Sieve: Uma linguagem para filtragem de correio
Sieve é uma linguagem de scripts para filtragem de correio eletrônico que, dentre todas conhecidas, é a única que segue um padrão de implementação. Este padrão foi inicialmente definido na RFC3028 e atualizado pelas RFCs 5228, 5229 e 5429, ou seja, qualquer software de correio, pode criar sua própria implementação, e o mesmo script DEVE funcionar em qualquer um destes servidores.
Existem diversas implementações do padrão, mas as mais conhecidas pela comunidade Open-Source são sem dúvida, as implementações feitas pelo Cyrus IMAP Server e pelo Dovecot. Este segundo, usa o mesmo interpretador Sieve do Cyrus IMAP. A partir da versão 1.2 (ainda em Release Candidate) do Dovecot, o interpretador Sieve foi totalmente re-escrito.
A linguagem Sieve suporta a maioria das features que as outras linguagens já mostradas aqui, com uma exceção, que é a execução de comandos de sistema (vide Courier maildropfilter). O fato de não existir esta feature não deixa a linguagem mais fraca, mas sim mais segura, pois uma das razões que contribuiram para criação do padrão, é definir uma forma segura da manipulação de scripts pelo próprio usuário.
Sieve Scripts
Agora que já sabemos um pouco sobre a linguagem Sieve, vamos conhecer o que é possível fazer, e como podemos usar a linguagem Sieve para nos auxiliar.
A maioria das features do Sieve, podem ser incluídas em seu script através do comando “require”, assim, é possível que você carregue somente as funções que vai utilizar, agilizando o parsing do script.
Outro ponto importante é que a linguagem suporta internacionalização, ou seja, você pode escrever seus scripts em UTF-8. Nota que também existem extensões para o Sieve que também possuem RFCs relacionadas. Aqui, falaremos sobre algumas extensões, como “fileinto”, “vacation” e “regex”.
Exemplos de scripts:
Consideremos nossa mensagem de correio:
From: "Spammer"<spammer@viagra.com> Date: Sun, Apr 19 2009 18:36:49 -0300 X-Spam-Flag: Yes Subject: [ SPAM ] Testando um script Sieve Que tal testarmos alguns Sieve Scripts?
Vamos testar as seguintes simples condições, que são plausíveis no dia-a-dia:
- Verificar se a mensagem tem a tag [ SPAM ] e escolher uma ação a tomar;
- Auto-resposta;
- Verificar tamanho da mensagem e escolher uma ação a tomar;
- Verificar o remetente da mensagem e escolher uma ação a tomar;
1. Verificar se a mensagem tem a tag [ SPAM ] e escolher uma ação a tomar (descartar ou movê-la para uma outra pasta);
O primeiro passo é carregar os plugins a serem usados:
require [“fileinto”, “regex”];
Logo após, verificamos se a mensagem pussui tag SPAM ou o header “X-Spam-Flag: Yes”. Exemplificarei os dois casos:
Pelo header:
if header :contains “X-Spam-Flag” “Yes” { # move para a pasta SPAM fileinto “SPAM”; discard; }
Pelo Assunto via regex:
if header :regex “subject” “\[(.)?SPAM(.)?\]” { # neste exemplo, quero descartar a mensagem. discard; }
2. Auto-resposta de Férias
Novamente, o primeiro passo é carregar os plugins:
require [“fileinto”, “vacation”, “regex”];
Caso a mensagem for da lista “Postfix-BR”, não enviaremos a auto-resposta, mas armazenaremos em uma pasta específica.
if header :regex “list-id” “Grupo.*Postfix.*Brasil” { fileinto "Listas"; stop; } else { # não enviará novamente para o mesmo remetente mais de uma vez # até que se cumpra o período de 30 dias de férias. # Seu script tem que estar em UTF-8, por causa da acentuação vacation :days 30 “Estou de férias. Envie novamente para fulano@ciclano.com”; }
Auto-resposta sempre que receber um e-mail:
vacation :subject “Recebido” “Sua mensagem foi recebida com sucesso”;3. Verificar tamanho da mensagem e escolher uma ação a tomar
require “fileinto”; if size :over 5M { # salva na pasta BigMessages fileinto “BigMessages”; }
4. Verificar o remetente da mensagem e escolher uma ação a tomar
Neste exemplo, todas as mensagens vindas de “spammer@viagra.com” ou “Spammer” recebam a flag “Junk” e também a flag \\Deleted:
require "imapflags"; if addres :matches “from” “spammer@viagra.com” { setflag "\\Deleted"; addflag “Junk”; }
ou
require "imapflags"; if header :matches “from” “Spammer” { setflag "\\Deleted"; addflag “Junk”; }
Enfim, estes foram alguns simplíssimos exemplos de uso do Sieve. Espero que este pequeno Post te abra o “apetite” por esta pequena, mas eficiente linguagem de filtragem, que cresce a cada dia mais, e em breve, prevalecerá na maioria dos MTAs conhecidos do mercado.
Em breve, farei outro Post falando sobre o Dovecot ManageSieve, que é uma ótima ferramenta para gerenciar scripts Sieve e também detalharei como implementá-lo.
Até lá!
Referências
http://wiki.dovecot.org/LDA/Sieve: http://wiki.dovecot.org/LDA/Sieve
RFCs 3028, 5228, 5229 e 5429: http://ietfreport.isoc.org/rfc/rfc3028.txt, http://ietfreport.isoc.org/rfc/rfc5228.txt, http://ietfreport.isoc.org/rfc/rfc5229.txt, http://ietfreport.isoc.org/rfc/rfc5429.txt
Postfix + SASL2 + Courier-IMAP + QUOTA + PostgreSQL HOW-TO (deprecated)
Posted by admin in Software Livre on March 10th, 2009

Calma lá! Eu concordo que colocar que algo é depreciado já no título é um tanto quanto bizarro, mas acreditem, este artigo é.
Escrevi este artigo em 2004 e após um crash no servidor onde estava hospedado, este artigo ficou perdido por um bom tempo. Poisé, e hoje, buscando por este artigo, o encontrei na íntegra no site Extmail.org. Fiquei bastante feliz, mas ao reler, vi que uma série de coisas não se compatibilizam com o que penso hoje.
Apesar disso, acho importante que esteja no ar pois muitas coisas deste artigo ainda se aplicam na prática, lógico que com algumas atualizações de software.
Acho importante também que eu esclareça as coisas que não acredito mais em relação a implementação que descrevi no artigo, e caberá a você pensar se vale a pena utilizá-lo.
1. Não acredito no uso de banco de dados relacionais como consulta para o Postfix. Bancos de dados relacionais são mais lentos, criam uma dependência perigosa e desnecessária externa e de forma mais clara, foram concebidos com outro propósito, não este. Use LDAP no lugar. É simples, rápido e existe para justamente este fim.
2. Apesar de ainda considerar o Courier-IMAP uma boa solução, hoje prefiro utilizar o Dovecot como servidor de POP3 e IMAP. É extremamente mais rápido, muito mais flexível e trabalha tanto com MBOX quanto com MAILDIR, fora a questão dos plugins disponíveis (LDA e Sieve, por exemplo) e sua implementação de autenticação SASL que é facilmente integrada com o Postfix, sem necessidades de Patches.
3. SASL. Expliquei em poucas palavras no tópico 2. Creio que a explicação seja suficiente.
4. Sobre a questão da Quota, não sou a favor de adicionar Patches de terceiros no Postfix. Hoje já existem diversas opções para implementar este comportamento. Novamente, o dovecot LDA te fornece esta funcionalidade.
Por ora, acredito que estes ítens já são claro o suficiente e mostram exatamente minha opinião hoje, mas muitos por algum motivo precisam utilizar o conjunto que entitula este Post. Sendo assim, boa leitura!
— Artigo publicado em 26/04/2004, linkado em http://www.postfix.org/non-english.html (quebrado) —
Postfix + SASL2 + Courier-IMAP + QUOTA + PostgreSQL HOW-TO
Este HOW-TO Foi escrito para auxiliar os Administradores que necessitam instalar um mailserver com suporte a domínios virtuais. Decidi usar o PostgreSQL como Banco de dados, pois este agrega uma série de funções mais complexas, e pensando que a instalação do servidor não é a única parte do processo. Talvez o administrador não queira usar somente um gerenciador de Domínios virtuais, e sim, fazer o controle do seu provedor inteiro dentro do PostgreSQL, via seu próprio “ISP Manager”. Lógicamente, é necessário uma máquina bem parruda para faze-lo, mas acredito que seja uma boa solução no que diz respeito à domínios virtuais.
Infelizmente, ainda não pude adicionar ao HOW-TO, nada relacionado à filtragem de mensagens, pois o maildrop não dá suporte ao PostgreSQL.
Consta também neste HOW-TO a implementação de soft quota para controle das caixas postais. O controle é feito pelo próprio postfix, mas necessita a aplicação de um patch.
Para Administração simples dos domínios, iniciei o desenvolvimento do Post-MailAdmin, que é baseado no ótimo PostfixAdmin, que gerencia os domínios virtuais no MySQL.
Iniciando o Processo
Instale o PostgreSQL (Faça download da ultima versão, ou baixe para sua distribuição)
Mais informações sobre o PostgreSQL aqui:
Baixe o cyrus-sasl e o patch para Crypt passwords.
O programa:
ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/
O patch
http://frost.ath.cx/software/cyrus-sasl-patches/
Descompacte o software, aplique o Patch, compile e instale o programa:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | [ root@server/~] # tar xvzf cyrus-sasl-2.*.*.tar.gz [ root@server/~] # cd cyrus-sasl-2.*.*/ [ root@server/~] # patch -p0 <../cyrus-sasl-2.1.17-checkpw.c.patch [ root@server/~] # ./configure --enable-login --enable-plain --enable-sql --with-pgsql=PATH-PARA-O-PGSQL [ root@server/~] # make [ root@server/~] # make install [ root@server/~] # ln -s /usr/local/lib/sasl2 /usr/lib/sasl2 # *** Não deixe de fazer isto, pois o cyrus-sasl não dá suporte à passwords crypt . Se está usando o sasl da sua distribuição, remova-o e instale a partir dos fontes*** # Crie o arquivo /usr/lib/sasl2/smtpd.conf com o seguinte conteúdo: pwcheck_method: auxprop auxprop_plugin: sql allowanonymouslogin: no allowplaintext: yes mech_list: PLAIN LOGIN srp_mda: md5 srvtab: /dev/null opiekeys: /dev/null password_format: crypt sql_engine: pgsql sql_user: postfix sql_passwd: postfix sql_hostnames: localhost sql_database: postfix sql_select: SELECT password FROM mailbox WHERE username = '%u@%r' AND domain = '%r'; # Baixe a ultima versão estável do Postfix: [ root@server/~ ]# wget ftp://ftp.matrix.com.br/pub/postfix/official/postfix-*.tar.gz [ root@server/~ ]# tar xvjf postfix-*.tar.gz |
Baixe o patch para controle de quotas referente a versão que você baixou do postfix:
http://web.onda.com.br/nadal/
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 | [ root@server/~ ]# gunzip postfix-*-trash.patch.gz [ root@server/~ ]# patch -p0 <postfix-*-trash.patch [ root@server/~ ]# cd postfix-*/ [ root@server/~ ]# make tidy [ root@server/~ ]# make -f Makefile.init makefiles 'CCARGS=-DHAS_PGSQL -I/usr/local/pgsql/include -DUSE_SASL_AUTH -I/usr/local/include' 'AUXLIBS=-L/usr/local/pgsql/lib -lpq -L/usr/local/lib/sasl2 -lsasl2' # (Altere o caminho dos headers e das libs conforme a sua instalação do postgre e sasl2) [ root@server/~ ]# make [ root@server/~ ]# make install #Se houver algum erro relacionado à sasl2, coloque o path "/usr/lib" em /etc/ld.so.conf # Inicie o PostgreSQL: # Se for baseado no Red Hat: [ root@server/~ ]# service postgresql start [ root@server/~ ]# su - postgres # Caso contrário: [ root@server/~ ]# su - postgres [ postgres@server/~ ]$ /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data [ postgres@server/~ ]$ postmaster -D /usr/local/pgsql/data >postgresql.log 2>&1 & # Crie o usuário a database e o user postfix: [ postgres@server/~ ]$ createdb postfix [ postgres@server/~ ]$ createuser postfix #Tabelas no PostgreSQL [ postgres@server/~ ] $ psql postfix -U postfix # Caso não logar, descomente no /usr/local/pgsql/data/pg_hba.conf a linha abaixo (use isto, somente se o BD postfix, for para uso exclusivo do usuário postfix, e só para localhost), pois assim localmente, o usuário postfix do PostgreSQL não precisa de senha: # TYPE DATABASE IP_ADDRESS MASK AUTH_TYPE AUTH_ARGUMENT # local postfix seu_ip sua_mascara trust # Outro detalhe, é habilitar o PostgreSQL a escutar os pedidos de conexão. # Edite o postgresql.conf e habilite as linhas: tcpip_socket = true port = 5432 # Logue no Postgre, crie as tabelas e dê permissão. [ postgres@server/~ ] $ psql postfix -U postfix CREATE TABLE "admin" ( "username" character varying(255) NOT NULL, "password" character varying(255) NOT NULL, "created" timestamp(13) with time zone DEFAULT '1999-04-23 01:05:06', "modified" timestamp(13) with time zone DEFAULT '1999-04-23 01:05:06', "active" boolean default true, Constraint "admin_key" Primary Key ("username") ); GRANT ALL ON admin TO postfix; CREATE TABLE "alias" ( "address" character varying(255) NOT NULL, "goto" text NOT NULL, "domain" character varying(255) NOT NULL, "created" timestamp(13) with time zone DEFAULT '1999-04-23 01:05:06', "modified" timestamp(13) with time zone DEFAULT '1999-04-23 01:05:06', "active" boolean default true, Constraint "alias_key" Primary Key ("address") ); GRANT ALL ON alias TO postfix; CREATE TABLE "domain" ( "domain" character varying(255) NOT NULL, "description" character varying(255) NOT NULL, "aliases" numeric(10,0) DEFAULT '0' NOT NULL, "mailboxes" numeric(10,0) DEFAULT '0' NOT NULL, "maxquota" numeric(10,0) DEFAULT '0' NOT NULL, "created" timestamp(13) with time zone DEFAULT '1999-04-23 01:05:06', "modified" timestamp(13) with time zone DEFAULT '1999-04-23 01:05:06', "active" boolean default true, Constraint "domain_key" Primary Key ("domain") ); GRANT ALL ON domain TO postfix; CREATE TABLE "domain_admins" ( "username" character varying(255) NOT NULL, "domains" character varying(255) NOT NULL, "created" timestamp(13) with time zone DEFAULT '1999-04-23 01:05:06', "active" boolean default true, Constraint "domain_admins_key" Primary Key ("username") ); GRANT ALL ON domain_admins TO postfix; CREATE TABLE "mailbox" ( "username" character varying(255) NOT NULL, "password" character varying(255) NOT NULL, "name" character varying(255) NOT NULL, "maildir" character varying(255) NOT NULL, "quota" numeric(10,0) DEFAULT '0' NOT NULL, "domain" character varying(255) NOT NULL, "created" timestamp(13) with time zone DEFAULT '1999-04-23 01:05:06', "modified" timestamp(13) with time zone DEFAULT '1999-04-23 01:05:06', "active" boolean DEFAULT 't'::bool, "home" character varying(255) DEFAULT '/var/spool/virtual/', "uid" numeric(3,0) DEFAULT 200, "gid" numeric(3,0) DEFAULT 200, Constraint "mailbox_key" Primary Key ("username") ); GRANT ALL ON mailbox TO postfix; CREATE TABLE "vacation" ( "email" character varying(255) NOT NULL, "subject" character varying(255) NOT NULL, "body" text, "cache" text NOT NULL, "domain" character varying(255) NOT NULL, "created" timestamp(13) with time zone DEFAULT '1999-04-23 01:05:06', "active" boolean default true, Constraint "vacation_key" Primary Key ("email") ); GRANT ALL ON vacation TO postfix; # De "q" para sair do psql # Configuração do Postfix para utilizar usuários Virtuais. # Lembre-se que esta configuração é para os usuários virtuais, seu postfix já tem que possuir as configurações default! # Adicione ao /etc/passwd: vuser:x:200:200::/var/spool/virtual:/bin/false # Adicione ao /etc/group: vgroup:x:200: # Crie o diretório e dê permissão: [ root@server/~ ]# mkdir /var/spool/virtual [ root@server/~ ]# chown 200:200 /var/spool/virtual # Crie os seguintes arquivos com os seguintes conteúdos: # /etc/postfix/pgsql_virtual_domains_maps.cf user = postfix password = postfix dbname = postfix table = domain select_field = domain where_field = domain additional_conditions = and active = true # ========================== # /etc/postfix/pgsql_virtual_mailbox_maps.cf user = postfix password = postfix dbname = postfix table = mailbox select_field = maildir where_field = username additional_conditions = and active = true # ========================== # /etc/postfix/pgsql_virtual_mailbox_size.cf user = postfix password = postfix dbname = postfix table = mailbox select_field = quota where_field = username additional_conditions = and active = true # ========================== # /etc/postfix/pgsql_virtual_alias_maps.cf user = postfix password = postfix dbname = postfix table = alias select_field = goto where_field = address additional_conditions = and active = true # Edite o arquivo /etc/postfix/main.cf e adicione as seguintes configurações: # Lembrando novamente que estou supondo que você já fez a configuração básica do mesmo. # PGSQL virtual_uid_maps = static:200 virtual_gid_maps = static:200 virtual_mailbox_base = /var/spool/virtual virtual_mailbox_domains = pgsql:/etc/postfix/pgsql_virtual_domains_maps.cf virtual_mailbox_maps = pgsql:/etc/postfix/pgsql_virtual_mailbox_maps.cf virtual_alias_maps = pgsql:/etc/postfix/pgsql_virtual_alias_maps.cf virtual_mailbox_limit = 51200000 virtual_transport = virtual # SASL2 smtpd_sasl_auth_enable = yes smtpd_recipient_restrictions = permit_sasl_authenticated reject_unauth_destination, permit_mynetworks smtpd_sasl_application_name = smtpd broken_sasl_auth_clients = yes # QUOTA virtual_mailbox_limit_inbox = no virtual_mailbox_limit_maps = pgsql:/etc/postfix/pgsql_virtual_mailbox_size.cf virtual_mailbox_limit_override = yes virtual_maildir_extended = yes virtual_create_maildirsize = yes virtual_mailbox_limit = 100000000 |
Simples teste:
Primeiro insira alguma coisa nas tabelas
1 | INSERT INTO mailbox (username,password,name,maildir,quota,domain) values ('teste@dominio.com.br','$1$Fi8IP53B$3yeGqD1Cnax.f.yAkLiAd1','name','teste@dominio.com.br/',1048576,'dominio.com.br'); |
Insira a senha criptografada!
A SENHA NESTE CASO É a palavra teste e quota é de 1MB
1 | INSERT INTO domain (domain,description,aliases,mailboxes,maxquota) values ('dominio.com.br','Domínio Virtual',1,1,1); |
Reinicie o Postfix:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | [ root@server/~ ]# postfix stop; postfix start # Dê um telnet no host: [root@server~/]# telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 server.domain.com.br ESMTP Postfix (2.1.0) MAIL FROM: teste@dominio.com.br 250 Ok RCPT TO: teste@dominio.com.br 250 Ok DATA 354 End data with <CR><LF>.<CR><LF> teste . 250 Ok: queued as 7B41F4665A quit 221 Bye Connection closed by foreign host. [root@server~/]# cd /var/spool/virtual;ls -la drwxr-xr-x 3 vuser vgroup 4096 Abr 26 11:18 . drwxr-xr-x 11 root root 4096 Abr 26 10:44 .. drwx------ 5 vuser vgroup 4096 Abr 26 11:18 teste@dominio.com.br [root@server~/]# |
Quando a mensagem chegar, será criado um arquivo chamado maildirsize dentro do diretório do usuário, que controlará a cota deste usuário virtual.
Courier-IMAP
Baixe o Courier-IMAP em http://www.courier-mta.org/download.php
Descompacte-o como usuário normal
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 | [ tanga_frouxa@server/~ ]$ tar xfjv courier-imap-3.0.3.20040424.tar.bz2 # Antes de iniciar o processo, certifique-se que existem os diretórios ou links /usr/include/pgsql e /usr/lib/pgsql, pois, se não existirem, pode acontecer de o courier-imap não ser compilado com suporte à PostgreSQL. [ tanga_frouxa@server/~ ]$ ./configure --with-redhat --enable-workarounds-for-imap-client-bugs # O --with-redhat somente se vc está usando Red Hat linux. [ tanga_frouxa@server/~ ]$ make # E como root: [ root@server/~ ]# make install [ root@server/~ ]# make install-configure #Configuração: # /usr/lib/courier-imap/etc/authdaemonrc authmodulelist="authpgsql authpam" authmodulelistorig="authpgsql authpam" daemons=5 # Aumente este valor caso tiver muitos "clientes IMAP" version="" authdaemonvar=/usr/lib/courier-imap/var/authdaemon # /usr/lib/courier-imap/etc/authpgsqlrc # É provável que ele exista com o nome de authpgsqlrc.dist. PGSQL_HOST localhost PGSQL_PORT 5432 PGSQL_USERNAME postfix PGSQL_PASSWORD postfix PGSQL_DATABASE postfix PGSQL_USER_TABLE mailbox PGSQL_CRYPT_PWFIELD password PGSQL_UID_FIELD uid PGSQL_GID_FIELD gid PGSQL_LOGIN_FIELD username PGSQL_HOME_FIELD home PGSQL_NAME_FIELD name PGSQL_MAILDIR_FIELD maildir # Inicie o Courier-IMAP: /usr/lib/courier-imap/libexec/imapd.rc start # Dê um telnet no host: [root@server~/]# telnet localhost 110 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. +OK Hello there. user teste@dominio.com.br +OK Password required. pass teste +OK logged in. list +OK POP3 clients that break here, they violate STD53. 1 1051 2 442 3 505 4 13516 5 27389 . quit +OK Bye-bye. Connection closed by foreign host. [root@server~/]# |
Pronto agora é só Instalar o Post-MailAdmin para adicionar e remover os usuários. Assim que possível, coloco a parte de anti-vírus no Postfix.
——————————————————————————–
Bibliografia
Postfix Website: http://www.postfix.org
Pelas quotas, agradeço à Marco Máximo pelo seu HOW-TO no Link http://www.linuxit.com.br/section-viewarticle-78.html
SASL2: http://www.gfxcafe.com/Mail%20Howto.htm / http://frost.ath.cx/software/cyrus-sasl-patches/
Autor Leandro Mendes - 26/04/2004
Atualizado em: 12/07/2004
Dica rápida - Submission port no Postfix
Posted by admin in Software Livre on February 2nd, 2009
<dica>
Como abrir a porta 587 para envio?
Bom, se a dúvida for só essa é simples. Edite o master.cf e adicione ao final do arquivo:
master.cf
1 2 | # habilitando submission port respeitando RFC5068 submission inet n - n - - smtpd |
Se for só para habilitar a porta, está prontinho. É necessário reiniciar o Postfix.
Desta forma, as mesmas restrições existentes para a porta 25 serão “herdadas” por este novo serviço, mas isso não significa que não seja possível alterá-las.
Para fazer isto basta utilizar o parâmetro -o na configuração do serviço:
1 2 3 4 5 | submission inet n - n - - smtpd -o smtp_client_restrictions=permit_sasl_authenticated,check_policy_service=unix:privacy/policy,reject -o smtp_helo_restrictions=permit_sasl_authenticated,reject -o smtp_sender_restrictions=permit_sasl_authenticated,reject -o smtpd_data_restrictions=reject_unauth_pipelining |
(Este exemplo é hipotético, pode não funcionar no seu caso. Leia o README e o man necessário para configurar corretamente).
</dica>
Valeu!
ifconfig, você ainda usa?
Posted by admin in Software Livre on December 20th, 2008
Ultimamente venho percebendo que algumas coisas que deveriam ser extintas, não são. Não tenho nada contra se manter coisas depreciadas por compatibilidade, mas definitivamente, as distribuições modernas deveriam abolir ferramentas como o ifconfig. Ok, pode me bater se quizer, mas o por que utilizar uma ferramenta depreciada e limitada, se você pode utilizar algo extremamente mais moderno?
Normalmente as pessoas insistem em se manter na tal da “zona de conforto”. Eu confesso que certamente sou um dos que por comodidade muitas vezes prefiro manter as coisas como estão, só que definitivamente, já há algum tempo aboli duas ferramentas do meu repertório… ifconfig e route. Obviamente, me refiro ao ifconfig do Linux, pois em sistemas BSD, o ifconfig não te obriga a criar uma interface alias, ao invés de somente adicionar um IP alias em sua placa de rede…
Desde 1999 (ainda no kernel 2.2) foi liberado publicamente o iproute2, que nada mais é que uma série de utilitários escritos a fim de modernizar e compatibilizar os sistemas GNU/Linux com os outros sistemas operacionais de rede, como o IOS e outros que habitam diversos ativos de rede por aí. Além disso, o iproute2 traz uma ferramenta específica para controle de tráfego, coisa que (pasmem) muita gente ainda acredita que não exista no Linux.
Talvez você ache inútil trocar de ferramenta, mas fica extremamente claro que você precisa usar algo mais moderno quando vc tiver mais de 2 ips alias na mesma interface de rede. Eu realmente acho idiota, e totalmente ridículo existir os aliases eth0:1, eth0:2, eth0:3 e assim sucessivamente se na realidade, você só está colocando um ip alias na eth0. Não concorda que o comportamento dos BSDs são mais inteligentes, que simplesmente listam os aliases na mesma interface com o nome de alias? Então, já está aí uma boa justificativa para começar a usar o iproute2 pois agrega os endereços em uma mesma interface.
Se você achou que esta justificativa é insuficiente para largar o seu velho e conhecido ifconfig, tudo bem, mas e se eu te disse que a mesma ferramenta que você configura seu IP também configura o roteamento do seu sistema? Ohhhh! incrível! Poisé, o mesmo comando configura sua interface e ainda configura a tabela de roteamento do seu sistema!
Ainda não acha que é uma boa justificativa? Tudo bem, eu compreendo. Mas essa ferramenta apesar de tão simples e intuitiva ainda é capaz de gerenciar o tráfego de sua rede! Complicado de entender? Não acho. Imagine, seu sistema é responsável por gerenciar diversos links diferentes e você precisa priorizar o tráfego de determinado serviço. Sim, você pode criar uma rota e mandar tudo que vem da origem X sair pelo link Y, mas normalmente, depois de alguns dias, ao verificar a tabela de roteamento você não vai entender o que significa aquele amontoado de rotas que parecem não dizer nada. O iproute2 te auxilia bastante nesse sentido. Se você tem conjuntos de servidores por determinados serviços, você pode agrupá-los em rules e definir o tráfego através dessas rules. Depois, quando precisar listá-las, o que você poderá ver é uma lista nomeada de “o quê é o quê” e “pra onde vai o quê”.
Apesar de tudo isso, o maior mérito do iproute2 ainda é a ferramenta tc, que gerencia o controle de banda do Linux. Incrível é o fato de muitos SysAdmins não sabem sobre esta ferramenta. Ouvem muito falar sobre HTB e CBQ, e acreditam que HTB e CBQ sejam comandos ou programas, quando na verdade são qdiscs (Queue Disciplines) gerenciadas através do tc.
Tudo isso é realmente trivial, reconheço, só que acredito que seja importante nos renovarmos e nos compatibilizarmos com as outras ferramentas, que afinal, seguem o mesmo padrão. Talvez muitos SysAdmins não acreditem tanto na necessidade de mudança, pois normalmente a preocupação de um SysAdmin é acima da camada de rede, mas para um profissional de rede, essa mudança é de extrema importância. Apesar de eu ser um SysAdmin, tenho formação específica na área de rede, e talvez por isso seja tendêncioso e acredito na necessidade desta mudança, não só de ferramenta, mas de pensamento.
Se você se concorda com isso, o primeiro passo é ler bastante sobre o que o iproute2 pode fazer. Como esse artigo não tem a finalidade de ensinar nada, eu aconselho a leitura de dois documentos; Linux Advanced Routing & Traffic Control HOWTO e o HTB Manual - Ambos são ótimas fontes de informação sobre em que o iproute2 pode te ajudar.
Os atuais MDAs e as linguagens de filtragem de e-mail (parte 2)
Posted by admin in Programação, Software Livre on December 5th, 2008
Nesta segunda parte, venho mostrar aquele que é na minha opinião, o mais completo MDA para uso geral, O Courier-Maildrop.
À primeira vista, sei que este comentário parece tendencioso, mas independente de minha opinião pessoal, acho importante que se saiba as capacidades deste MDA antes de fazer sua escolha.
Novamente contarei um pouco de história, falando sobre o seu crescimento e amadurecimento. Trago também novos exemplos para mostrar aquilo que é o mínimo que a maildropfilter pode fazer.
Courier-Maildrop, o canivete suiço
Este MDA Surgiu em 1998, inicialmente como parte do Courier Mail Server, mas logo teve seu release standalone. Com o passar dos anos, foi se tornando um dos MDAs mais flexíveis e logo tornou-se também um dos mais usados, tendo como concorrente direto o vdeliver (parte do software vmailmgr, o qual não vou abordar) em servidores com Qmail. Com o advento do Postfix, teve um significante aumento em sua difusão, pois trata-se de uma alternativa eficaz para usuários virtuais. Durante uns bons anos foi considerada o melhor para este fim, devido sua flexibilidade. Em relação à sua linguagem para filtros, a maildropfilter é uma linguagem extremamente flexível e poderosa. Possui uma sintaxe muito parecida com Perl ou PHP e também características do POSIX Shell Script, e por isso podemos considerá-la extremamente intuitiva e com uma suave curva de aprendizado.
A maildropfilter não é somente uma linguagem que possibilita criar regras para filtragem de mensagens, mas sim, além dessa que é sua funcionalidade básica, é um processador de regras de negócio. Diferentemente do procmail e o Dovecot LDA (que veremos no próximo artigo), o maildrop é o único que por possuir realmente uma linguagem de programação embutida, pode proporcionar algo assim.
Da mesma forma que os outros MDAs, o maildrop inicia seu trabalho a partir de expressões regulares (PCRE) e finaliza seu trabalho quando encontra a declaração “to”. Inicia com diversas variáveis pré-definidas, e entre elas algumas importantes são: DEFAULT (Mailbox padrão para entrega. Para utilizar maildir, “Maildir/”), FROM, LOGNAME e SENDMAIL. Muitas outras estão disponíveis vide “man maildropfilter”.
Uma feature extremamente útil na minha opinião, é a capacidade de executar comandos de sistema. A maildropfilter o faz de duas formas: Através do comando xfilter ou da forma Unix like de receber saída de comandos, com as aspas invertidas. Ex. DIR=`ls`.
Podemos considerar a maildropfilter é uma linguagem completa, pois ela conta com os condicionais if e else, os laços while, for e foreach, operadores lógicos e bitwise e operadores de comparação, semelhantes ao POSIX Shell e Perl. Além disso, conta com comandos específicos para ajudar na filtragem. Veremos estes comandos nos exemplos à seguir.
Exemplos:
1. Filtrar todas as mensagens com Assunto ***SPAM*** para a pasta Mala Direta:
1 2 3 4 5 6 | if ( /^Subject:.*SPAM.*/ ) { # Ao processar com sucesso o to o maildrop sai com EX_OK. # Em caso de erro EX_TEMPFAIL. to “$MAILDIR/.Mala Direta/” } |
2. Se a mensagem vier de “Grupo Email” verificar o assunto e se caso for “Teste do Maildrop” mover para a pasta “Grupo Email”:
1 2 3 4 5 6 7 | if(/^From:.*GruposEmail.*/) { if(/^Subject:.*Teste.do.Maildrop.*/) { to “$MAILDIR/Grupo Email/” } } |
3. Verificar no arquivo .config se o usuário possui o serviço de filtro de mensagens, e caso positivo, executar os filtros deste usuário e logar que será executado o filtro:
1 2 3 4 5 6 7 8 9 10 11 | # seta local do logfile. Usuário rodando maildrop # precisa de permissão de escrita no arquivo. logfile “/var/log/maildrop.log” # o comando lookup procura por patterns dentro de arquivos. if(lookup(/^filterpref/, $HOME/.config)) { # grava no logfile. log “Este login possui filtros, executando” include $HOME/.myfilters } |
4. Verifica se o remetente está na blacklist
1 2 3 4 5 6 7 8 9 | # a maildropfilter possui pattern matching, sendo assim você # pode usar o resultado da expressão regular no seu script. if(/^From:s*(.*)/ && lookup( $MATCH1, “blacklist.txt”) ) { # extrai o endereço RFC2822 do resultado da expressão. ADDR=getaddr($MATCH1) log “maildrop: $ADDR is on blacklist (dropped)” exit } |
Muitos outros exemplos e a documentação completa do maildrop e da maildropfilter podem ser conseguidas via o comando “man maildrop” e “man maildropex”, ou na página do Courier-Maildrop.
Como visto nos exemplos, o maildrop é um filtro avançado e o mais indicado quando é necessário colocar regras de negócio no procedimento de entrega dos e-mails. Lógicamente, se a sua única intenção é efetuar filtragens simples, você pode optar por outro MDA menos robusto. Isto também não significa que nestes casos você não deva o usar, pois a escolha também depende da combinação usada na instalação de seu servidor. Normalmente, se você utiliza Courier-IMAP, a melhor escolha é sempre o maildrop.
Espero que este artigo também tenha sido esclarecedor e como é de praxe, se você quiser conhecer mais sobre este MDA, acesse o site do Courier-Maildrop e também leia suas páginas de manual. Te garanto que é a melhor leitura pra quem quer aprender sobre este cara.
No próximo artigo, falarei sobre o Dovecot LDA, esse que é a coqueluxe do momento, e também sobre a história do Sieve. Até lá!
Bibliografia
maildrop documentation: http://www.courier-mta.org/maildrop/documentation.html
Páginas do manual: man maildropfilter, man maildropex
Os atuais MDAs e as linguagens de filtragem de e-mail.
Posted by admin in Programação, Software Livre on November 29th, 2008
Existem vários assuntos interessantes dentro do universo dos servidores de e-mail, um deles é a concorrência entre diversos tipos de MDA (mail delivery agent). Frequentemente este assunto é motivo de boas discussões, e nessas discussões a pergunta que se sobressai é: Qual a melhor escolha entre por exemplo o Courier-Maildrop, Dovecot LDA ou Procmail?
O intuito deste texto não é concluir qual o melhor MDA do momento, mas sim mostrar suas diferenças, explicar um pouco sobre a linguagem que cada MDA implementa e, quem sabe, poder ajudar o leitor a decidir qual é o mais adequado para uso em seu ambiente. Farei uma abordagem cronológica, ou seja, dos três escolhidos, do primeiro a surgir até o mais atual, e neste primeiro post vou falar um pouco sobre o já bastante conhecido Procmail.
Um overview sobre o Procmail.
Dos agentes de entrega escolhidos, o Procmail é o mais antigo deles. Teve seu release 1.0 em 1990, e inicialmente seu uso mais comum foi como MDA para o Sendmail. Em relação à linguagem embutida no Procmail para processamento das mensagens, podemos dizer que foi de certa forma influenciada por este atrelamento com o Sendmail, pois quando olharmos um arquivo “procmailrc”, é provável que tomaremos um pequeno susto do tipo daquele que tomávamos ao ler um “sendmail.cf”. Apesar de não ser difícil de trabalhar com o procmail, a sintaxe de sua linguagem não pode ser considerada intuitiva ao primeiro olhar.
O procmail trabalha principalmente com processamento de mensagens através de expressões regulares, no caso do procmail, seguindo o padrão POSIX. O procmail trabalha com um conceito chamado “recipe”, e cada recipe por padrão deve ser iniciado pelo caracter “:” (dois pontos) e o digito 0 (zero). A sintaxe exata do procmail deve seguir o seguinte padrão:
:0[ flags] [: [local lockfile name] ]<uma ou mais condições (por linha) > <ação>
FLAGS
As flags principais do procmail são:
H - processa o header;
B - processa o body;
D - inicia o recipe em case sensitive mode;
c - faz uma cópia carbono;
ACTIONS
São simples ações executadas pelo procmail:
! - encaminha a mensagem para um endereço específico;
| - Envia a saída (stdout) para determinado programa;
{ - inicia um próximo bloco de “recipes” (necessita ao mínimo um espaço após o caracter);
O procmail também permite que sejam extraídas diversas variáveis de ambiente que podem ser usadas como facilitadores dentro de seu filtro, principalmente as varíaveis LOGNAME, SHELL, HOME, HOST (todas são auto-explicativas).
Abaixo, mostrarei alguns exemplos de uso do procmail. Exemplos mais complexos estão disponíveis através do simples comando “man procmailex”.
Exemplos:
1. Separa todas as mensagens com assunto: ***SPAM*** na pasta Mala Direta:
1 2 | # neste caso, a pasta é formato mbox. Maildir necessita do “/” :0H ^Subject:.*SPAM.* Mala Direta |
2. Efetuda cópia carbono das mensagens com assunto “Todos” para o destinatário foo@bar:
1 2 3 4 | :0H ^Subject:.*Todos { :0 c ! foo@bar } |
3. Auto-resposta:
1 2 3 4 5 | :0 c | (formail -A”Subject: Mensagem recebida”; echo “Sua mensagem foi recebida, logo entrarei em contato!”; echo “--”; cat $HOME/.signature ) | $SENDMAIL -oi -t |
Como vimos nestes exemplos, o procmail é uma ótima solução para filtragem simples. Sua linguagem apesar de incomum, é provavelmente a de mais rápido processamento por não necessitar de análise léxica complexa. E uma informação interessante sobre procmail: Sim! É possível usá-lo com usuários virtuais! Só que infelizmente, ele não te dá uma flexibilidade tão grande, visto que não suporta nenhum tipo de base de usuários, funcionando basicamente com dados disponíveis através de variáveis de ambiente.
Por ora conhecemos um pouco do Procmail. Se esse pequeno artigo te fez se interessar por este MDA, o primeiro passo é descobrir mais sobre ele. Informações sobre ele podem ser conseguidas nas páginas do manual, ou então no site do procmail.
No próximo post vou abordar o MDA Courier-Maildrop. Novamente um pouco de história e exemplos de uso deste que é o mais completo MDA e pode ser considerado o canivete suiço no mundo da filtragem de e-mail.
Referências bibliográficas
procmail.org - http://www.procmail.org/ - Acesso em 28/11/2008.
Paginas do manual - (man procmail, man procmailex) – 29/11/2008.