Paulino Kenji Sato <[EMAIL PROTECTED]> writes:
> Ap�s outras lidas na documenta��o, coloquei o
> smtpd_client_restrictions eo bloqueio come�ou a funcionar. Era so ter
> tentado mais antes de mandar o email, mas ai n�o ia aprender os
> "truques" ali em baixo. :)
Dica 2: coloque *todas* as restri��es em
smtpd_client_restrictions. N�o � necess�rio usar as outras.
Por qu�? Por qu� ao chegar nesta, o servidor j� possui todos os
cabe�alhos e informa��es para aplicar qualquer uma das restri��es
(exceto, obviamente, body_checks e header_checks que s�o baseados no
conte�do da mensagem). Isso lhe permitir� ordenar melhor o que deve
acontecer e quando.
Melhor do que ter que lembrar em qual passo do SMTP est� a mensagem e
que informa��es voc� pode usar para barrar a mensagem. A performance
n�o � comprometida.
> Posso ter o access tambem em uma tabela sql?
AFAIK sim.
> o /etc/postfix/access para regras fixas ea tabela sql para usar em um
> esquema de pop-before-smtp.
Voc� teria dois mapas. N�o � necess�rio que eles sejam como o
"access", mesmo que seu uso seja para isso.
>> [root@wintermute postfix]# postmap -q 'webservers.com.br' hash:access
>> REJECT
> "Humm... assim que se testa..."
:o))
Podes testar assim tamb�m:
[root@wintermute postfix]# postmap -q - hash:access
joao
maria
teste
teste2
teste REJECT
[root@wintermute postfix]# postmap -q - hash:access
joao
teste
maria
teste
teste2
teste REJECT
teste REJECT
[root@wintermute postfix]#
Ou seja, v�rias linhas e encerrando-as com CTRL-D (EOF).
> Agora essa parte da configura��o esta assim
> smtpd_client_restrictions = check_client_access hash:/etc/postfix/access,
> permit_mynetworks,
> reject_unknown_client
> smtpd_sender_restrictions = check_sender_access /etc/postfix/access,
> reject_unknown_sender_domain
>
> e pelo que vejo no log, os emails com grande potencial de serem spam est�o
> sendo rejeitados.
Coloque na mesma regra e coloque tudo em smtpd_client_restrictions.
> smtpd_client_restrictions
> (Quem pode conectar ao smtp)
> smtpd_sender_restrictions
> (Verifica pelo remetente do email, ou seja quando esta recebendo)
N�o � o remetente no "From:" � o remetente no "From ". O remetente do
envelope :-)
> smtpd_recipient_restrictions
> (Pelo destinat�rio, ou seja quando se trata do envio)
:-)
Para evitar esta confus�o, coloque tudo numa restri��o s�, na ordem em
que deve ser checada.
> E quando se consulta um mapa e nele n�o existe uma a��o para o objeto
> consultado, na documenta��o diz que ser� tratado por outro UCE, mas se n�o
> tiver mais a quem consultar, qual a a��o padr�o?
Voc� define.
Por exemplo:
smtpd_client_restrictions = checagem_a,
checagem_b,
checagem_c,
permit
A a��o padr�o ser� deixar a mensagem passar, ou seja, se nada a
impediu at� ali, ela passa.
smtpd_client_restrictions = checagem_a,
checagem_b,
checagem_c,
reject
A a��o padr�o ser� barrar a mensagem, ou seja, se nenhuma regra a
deixou passar, ela morre ali.
> Melhor eu parar de ler a documenta��o, e fechar esse email. Sen�o mais
> d�vidas v�o surgir. :)
D�vidas indicam que voc� est� estudando e aprendendo. Melhor tir�-las
aqui do que deixar um relay aberto e correr depois com o servidor em
listas negras.
--
Godoy. <[EMAIL PROTECTED]>
Assinantes em 23/11/2002: 2241
Mensagens recebidas desde 07/01/1999: 191265
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
