Eaten by a Grue's questions

Eu tenho o sender_bcc_maps configurado e trabalhando com o postfix para que os e-mails de saída sejam enviados para o endereço do remetente. Minha configuração é mais ou menos:

main.cf

sender_bcc_maps = regexp:/etc/postfix/regexp_sender_bcc

regexp_sender_bcc

/^([^@]+)@[a-zA-Z0-9_]+\.[a-zA-Z0-9_]+$/ [email protected]

Isso funciona muito bem. Agora tenho um endereço de e-mail [email protected]que gostaria de excluir desta configuração.

Idéia 1: primeiro tentei adicionar uma linha para rotear para uma caixa de correio inexistente

/^nobody.*$/ [email protected]

Previsivelmente, isso resulta em uma tentativa de Bcc desse endereço e um retorno, já que ele não existe.

Idéia 2: Em seguida, tentei simplesmente alterar o destino para uma string vazia:

/^nobody.*$/

Isso gera um aviso e também descarta completamente o e-mail de saída:

warning: sender_bcc_maps lookup of [email protected] returns an empty string result
warning: sender_bcc_maps should return NO RESULT in case of NOT FOUND
warning: sender_bcc_maps map lookup problem -- message not accepted, try again later

Idéia 3: Tentei encaminhar este e-mail para um usuário local:

/^nobody.*$/ nobody@localhost

Isso de certa forma faz o trabalho, mas todas essas mensagens ainda são entregues ao sistema de correio local.

Eu gostaria de fazer qualquer um destes - preferindo o primeiro:

• configure sender_bcc_maps para ignorar completamente o endereço de um remetente específico
• configurar o postfix para descartar completamente o correio para um usuário específico

Estou um pouco confuso sobre a atividade nos logs do meu servidor de e-mail (endereços e destino editados para privacidade):

Nov  1 21:00:03 mail postfix/smtp[745742]: Trusted TLS connection established to mx.example.com[192.0.2.1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Nov  1 21:00:10 mail postfix/smtp[745742]: 0C1551DC073: to=<[email protected]>, relay=mx.example.com[192.0.2.1]:25, delay=7.3, delays=0.01/0.01/0.42/6.9, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 7E42A921A9A25)
Nov  1 21:00:11 mail postfix/smtp[745829]: Trusted TLS connection established to mx.example.com[192.0.2.1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Nov  1 21:00:18 mail postfix/smtp[745829]: 903371DC08B: host mx.example.com[192.0.2.1] said: 451 4.7.1 Greylisting in action, please come back later (in reply to end of DATA command)
Nov  1 21:00:18 mail postfix/smtp[745829]: Trusted TLS connection established to mx.example.net[192.0.2.2]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Nov  1 21:00:25 mail postfix/smtp[745829]: 903371DC08B: to=<[email protected]>, relay=mx.example.net[192.0.2.2]:25, delay=16, delays=0.01/1.4/7.7/7.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as BB99F922EC625)

Parece que o postfix recebeu uma resposta da lista cinza no segundo email para o domínio em questão, mas imediatamente tentou novamente a entrega para um ip de registro MX diferente (@21:00:18)? Estou entendendo mal o que está acontecendo aqui?

Todas as configurações são mais ou menos padrão com estas exceções:

minimal_backoff_time = 180s
maximal_backoff_time = 3h

Quero ter certeza de que estamos respeitando a resposta do provedor do destinatário, mas não parece que o postfix esperou 180 segundos antes de tentar novamente a entrega como eu esperava.

No arquivo de configuração SSL dovecot padrão, os caminhos do arquivo de certificado são especificados como:

ssl_cert = </etc/dovecot/private/dovecot.pem

Qual é o propósito daquele <símbolo que precede o caminho?

ATUALIZAÇÃO: Um comentário abaixo continha um link morto para documentos detalhando essa sintaxe. Aqui está o link de trabalho atual que pode ser útil para futuros leitores: https://doc.dovecot.org/configuration_manual/config_file/#reading-value-from-file

Pergunta: Ao especificar 2 ou mais endereços para a inet_interfacesdiretiva, o postfix ainda vinculará as mensagens de saída a um deles?

Os documentos do postfix declaram:

Quando inet_interfaces especifica apenas um endereço IPv4 e/ou IPv6 que não seja um endereço de loopback, o cliente Postfix SMTP usará esse endereço como o endereço IP de origem para e-mail de saída.

Devido à necessidade de um endereço de loopback, preciso ser capaz de vincular a 127.0.0.1 ou ao meu endereço WAN, dependendo do destino do e-mail. Minha configuração atual é:

inet_interfaces = 23.45.67.89, [2600:1234::1234:5678:abcd:abcd], 127.0.0.1

Anteriormente, eu havia usado smtp_bind_addresse smtp_bind_address6estava causando problemas, pois o postfix precisa acessar o loopback para entrega de correio local.

Além disso, tenho de fato 5 endereços IPv4 estáticos para este servidor, daí o desejo de usar apenas um deles. Como o estado dos documentos, just one IPv4 and/or IPv6não tenho certeza se especificar todos os três garantirá que o e-mail de saída seja vinculado a alguma coisa.

Eu tenho um mailserver encaminhando emails e usando postsrsd para SRS. Como o postsrsd usa a mydomainconfiguração do postfix para alterar o Return-Path, existe uma maneira de definir o SRS_DOMAIN para email encaminhado com base no endereço do destinatário, em vez de defini-lo estaticamente? Como o servidor de correio lida com mensagens de vários domínios diferentes, gostaria que o caminho de retorno correspondesse ao domínio do destinatário, não ao nome do host do servidor de correio.

Eu configurei Postfix, Dovecot e MySQL de acordo com este tutorial do linode . Na tabela de aliases virtuais tenho uma conta que encaminha para o meu gmail.

Como essas mensagens estão sendo entregues por meio do meu servidor de e-mail, que obviamente não é designado como remetente permitido pelo registro spf do domínio de origem, as mensagens são marcadas como "spf: fail" e têm o cabeçalho adicionado como "alguém@exemplo. com via myservername.com".

Isso faz todo o sentido, mas gostaria de saber se existe alguma maneira de entregar/encaminhar essas mensagens sem a penalidade do SPF? Por enquanto está tudo bem, pois adicionei filtros no gmail para que os e-mails encaminhados não sejam marcados como spam. Mas, historicamente, os provedores de e-mail tendem a mudar e muitas vezes endurecem as políticas em relação à entrega de e-mail, então, por esse motivo, gostaria de saber se existe uma maneira melhor de configurar isso.