postfix permit_sasl_authenticated em smtpd_client_restrictions para envio em 587

Question

Primeiro, deixe-me explicar minha configuração. Estou usando o postfix 2.9.6 no Debian Wheezy. Eu não permito o AUTH na porta 25, e forço os MUAs a usarem um serviço de submissão na porta 587. Debian vem com a seguinte configuração em master.cf (comentada por padrão):

submission inet n       -       -       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

Eu não entendo porque o allow_sasl_authenticated está em smtpd_client_restrictions. Para permitir acesso de retransmissão, ele também deve ser adicionado a smtpd_recipient_restrictions (ou smtpd_relay_restrictions, para postfix > = 2.10), seja em main.cf ou preferencialmente em uma substituição adicional para o serviço de envio em master.cf:

  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

De qualquer forma, o resultado é a verificação da autenticação duas vezes e, com a avaliação atrasada das listas de restrição, ambas as verificações são feitas no estágio RCPT TO. Sem acesso de retransmissão, os clientes AUTH poderiam enviar para $ mydestination, mas o MTA na porta 25 já permite isso de qualquer maneira. Sem uma avaliação atrasada, o smtpd nem sequer teria informações sobre o AUTH quando o cliente verifica.

Existe algum benefício em ter permissão para ser permitido, em smtpd_client_restrictions, o allow_sasl_authenticated? Qual é o caso de uso para isso?

    

Answer 1

É simplesmente uma maneira limpa de sobrescrever o main.cf, já que geralmente o smtpd_client_restrictions no main.cf não é usado, o que é o mesmo que dizer que por padrão ele está configurado para smtpd_client_restrictions = allow.

Você pode obter o mesmo resultado sobrescrevendo smtpd_recipient_restrictions, como você diz na sua pergunta. Nesse caso, você não precisaria da instrução smtpd_client_restrictions, talvez isso pudesse ter um benefício de desempenho imperceptível, mas se houvesse outras restrições presentes em smtpd_recipient_restrictions no principal .cf relevante para os clientes autenticados, você também deve adicioná-los ao master.cf e lembrar de mantê-los sincronizados com futuras edições.

Também do ponto de vista dos empacotadores debian, sobrescrever smtpd_client_restrictions é uma aposta mais segura, já que é muito menos provável que esteja fazendo algo em main.cf comparado com smtpd_recipient_restrictions.

    

Answer 2

O postfix começou a suportar listas de restrições mistas. Linhas retalhadas de: Documentos Postfix

Around the time that smtpd_delay_reject was introduced, Postfix was also changed 
to support mixed restriction lists that combine information about the client, 
helo, sender and recipient or etrn command. 

Mixing is needed for complex whitelisting policies. For example, in order to 
reject local sender addresses in mail from non-local clients, you need to be 
able to mix restrictions on client information with restrictions on sender 
information in the same restriction list. Without this ability, many per-user
access restrictions would be impossible to express. 

Os parágrafos acima explicam claramente porque as restrições mistas são suportadas e exigidas.

No seu caso, você não quer que nenhuma restrição seja imposta no client (IP / host de conexão), uma vez que elas sejam autenticadas. Suponha que você tenha um requisito como "Mesmo que os usuários se autentiquem, eles não poderão enviar e-mails para [email protected] ", então seu smtpd_recipient_restrictions deve ser

#/etc/postfix/main.cf
smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/blocked_rcptto
             permit_sasl_authenticated
#/etc/postfix/blocked_rcptto
[email protected] REJECT No mails can reach this user from us

Espero que ajude.

    

Answer 3

Respondendo a minha própria pergunta, mas suponho que um possível caso de uso seria o seguinte:

Se mais tarde eu adicionei smtpd_client_restrictions a main.cf (ela está vazia por padrão), para bloquear spam ou qualquer outra coisa, então ter a substituição já presente para envio em master.cf permitiria que os clientes AUTH ignorassem essas restrições. Não sobrescrever smtpd_client_restrictions pode surpreender alguém submetendo os clientes AUTH a verificações de spam. Claro que isso pode não ser necessariamente uma coisa ruim ..