Postfix: aviso: conectar-se a 127.0.0.1:10023: Conexão recusada, não receber correio de domínios externos

3

Eu tive um servidor Postfix em execução por um curto período e funcionou, mas tive que reiniciar o servidor hoje e não estou mais recebendo e-mails de fontes externas:

Jan 23 01:34:44 myservername postfix/smtpd[1055]: connect from db3ehsobe006.messaging.microsoft.com[213.199.154.144]
Jan 23 01:34:45 myservername postfix/smtpd[1055]: warning: connect to 127.0.0.1:10023: Connection refused
Jan 23 01:34:45 myservername postfix/smtpd[1055]: warning: problem talking to server 127.0.0.1:10023: Connection refused
Jan 23 01:34:46 myservername postfix/smtpd[1055]: warning: connect to 127.0.0.1:10023: Connection refused
Jan 23 01:34:46 myservername postfix/smtpd[1055]: warning: problem talking to server 127.0.0.1:10023: Connection refused
Jan 23 01:34:46 myservername postfix/smtpd[1055]: NOQUEUE: reject: RCPT from db3ehsobe006.messaging.microsoft.com[213.199.154.144]: 451 4.3.5 Server configuration problem; from=<MyKnownWorking@EmailAccountOutside> to=<[email protected]> proto=ESMTP helo=<db3outboundpool.messaging.microsoft.com>

O servidor está escutando port 10023 , mas notei que ele está escutando somente via IPv6:

> sudo netstat -a | grep 10023
tcp6       0      0 ip6-localhost:10023     [::]:*                  LISTEN

Eu não tenho nenhuma regra de firewall que negaria que seria uma porta específica, inferno, eu segui em frente e limpei o conjunto de regras apenas para confirmá-lo. Aqui está a saída do meu postconf -n (eu editei meu nome de domínio no lugar de "mydomain.com":

> sudo postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
    append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
content_filter = amavis:[127.0.0.1]:10024
disable_vrfy_command = yes
inet_interfaces = all
inet_protocols = ipv4
mailbox_size_limit = 0
message_size_limit = 0
mydestination = localhost.$mydomain, localhost, mail.mydomain.com, servername.mydomain.com
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mynetworks_style = host
myorigin = /etc/mailname
readme_directory = no
receive_override_options = no_address_mappings
recipient_delimiter = +
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_banner = mail.mydomain.com ESMTP $mail_name
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_recipient_restrictions = reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks, warn_if_reject reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unauth_pipelining, permit
smtpd_tls_cert_file = /etc/ssl/private/mail.mydomain.com.crt
smtpd_tls_key_file = /etc/ssl/private/mail.mydomain.com.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
virtual_alias_maps = mysql:/etc/postfix/maps/alias.cf
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/spool/mail/virtual
virtual_mailbox_domains = mysql:/etc/postfix/maps/domain.cf
virtual_mailbox_limit = 0
virtual_mailbox_maps = mysql:/etc/postfix/maps/user.cf
virtual_uid_maps = static:5000

Como você pode ver, estou até tentando especificar via inet_protocols que ele escuta em conexões ipv4. Eu tentei com e sem esse comando.

Qualquer ajuda na solução de problemas seria muito apreciada! E, claro, se você vê alguma coisa na minha configuração é muito estúpida, eu não estou acima de conselhos ou críticas.

    
por DavisTasar 23.01.2013 / 02:46

6 respostas

5

Sua última verificação em smtpd_recipient_restrictions usa um serviço de política para verificar o destinatário. Normalmente, esse é um serviço postgrey e parece ter alguns problemas com o Postfix se conectando a ele.

smtpd_recipient_restrictions = ...,check_policy_service inet:127.0.0.1:10023, permit

Se você remover check_policy_service inet: 127.0.0.1: 10023 do smtpd_recipient_restrictions, deverá eliminar o erro, mas ainda deverá determinar o que acontecerá com o seu postgrey ou outro serviço que estaria sendo executado aqui.

Verificando Postgrey em um sistema Unbuntu

Normalmente, uma configuração padrão do postgrey escutará na porta 10023 as conexões e determinará se elas devem ser permitidas ou rejeitadas. Algumas partes em um servidor Unbutu que você pode verificar para ver se isso está instalado são ...

  • Você tem um arquivo /etc/default/postgrey ? Este é o arquivo de configuração básico.
  • Você tem uma pasta /etc/postgrey ? É aqui que você pode colocar elementos na lista de permissões.
  • Quando você executa > which postgrey , ele encontra um binário? O meu é encontrado em /usr/sbin/postgrey .
  • Você tem um script /etc/init.d/postgrey para iniciá-lo na inicialização? Este é o local típico para os daemons do Ubuntu.

Isso só lhe dará algumas dicas se esse servidor pode ter o postgrey configurado de uma só vez. Você precisará procurar mais informações sobre solução de problemas se o processo não estiver sendo executado corretamente em seu servidor.

    
por 23.01.2013 / 03:00
4

Enfrentado o mesmo problema, tentei muitas maneiras, como proposto por bshea , googling e tentando.
Base: Ubuntu 14.04.2 LTS, postgrey service inicia, mas não aparece na lista de processos, ou seja, o serviço é iniciado, mas cai silenciosamente.

Solução encontrada para alterar a linha em /etc/default/postgrey :

Altere esta linha:

POSTGREY_OPTS="--inet=10023"

Para isso

POSTGREY_OPTS="--inet=127.0.0.1:10023"

Não é necessário jogar com portas, protocolos nem downgrade de versão de algo. Não é possível explicar por que, mas o serviço está em ps -aux e todas as obras.

    
por 03.08.2015 / 19:07
1

Na verdade, você não é obrigado a usar o ipv6, você pode configurar o Postgrey e o Postfix para o ipv4. O problema é que o Postgrey (provavelmente versão 1.33 e mais recente) se recusa a iniciar o iphost local4 ip 127.0.0.1, então você pode usar o seu endereço IP ethX.

Em /etc/postfix/main.cf altere isto:

check_policy_service inet:127.0.0.1:10023

para:

check_policy_service inet:<your_ipv4_address>:10023

Em seguida, reinicie o Postfix:

sudo service postfix restart

Em / etc / default / postgrey altere isso:

POSTGREY_OPTS="--inet=10023 --delay=60"

para:

POSTGREY_OPTS="--inet=<your_ipv4_address>:10023 --delay=60"

Em seguida, reinicie o Postgrey:

sudo service postgrey restart

Muito userful foi esta mensagem da lista de mensagens do Debian:

link

    
por 03.01.2015 / 09:22
0

Davis - você está certo, o postgrey foi alterado no 12.04LTS para funcionar no IPv6. A atualização não muda para o postfix e não o alerta para fazer uma alteração.

Então você tem que fazer isso sozinho. Mude isso:

check_policy_service inet:127.0.0.1:10023

para:

check_policy_service inet:::1:10023

no seu arquivo /etc/postfix/master.cf , depois reinicie o postfix:

sudo service postfix restart

Permitirá que o postfix converta o IPv6 em postgrey.

    
por 11.08.2013 / 20:44
0

A questão do IP: PORT não é / não foi um problema para mim (Ubuntu 14.04.2 LTS). Pode ser enganador assumir que o postgrey está quebrando / saindo em falha de conexão / execução de porta local.

Primeiro, verifique se o daemon é reconhecido como em execução:

sudo service postgrey status

Se não estiver sendo executado / reconhecido, você ainda verá :

warning: problem talking to server [::1]:10023: Connection refused

no seu registro de e-mail. Postgrey simplesmente não está anexado / em execução. Se você encontrá-lo em execução (pode ser mais de uma vez) e não pode parar o serviço ou status dele, você provavelmente tem um problema de pid / truncate. Se sim, faça:

ps a | grep postgrey

Matar (cada) processo manualmente. Remova todos os arquivos postgrey.pid de / var / run (/ run).

Assumindo que todos os seus arquivos postgrey são padrão e está tentando iniciar, mas falhando em reboots / reinicia / pára (depois de verificar 'sudo service postgrey status'), você provavelmente tem problemas com lockfile e named process for stop-start- daemon.

O POSTGREY tem um script init.d muito básico que não faz muita verificação antes / depois de executar as coisas. Os mantenedores realmente precisam trabalhar nisso.

O principal problema é o start-stop-daemon que procura o arquivo com nome truncado :

( link )

O script como instalado verifica $ NAME="postgrey".
("--name $ NAME")
Infelizmente, o que ele precisa usar (Ubuntu / Debian) é: '/ usr / sbin / postg'
 (apenas 15 caracteres e faz parte do caminho - que não existe obviamente).

A correção (adicione a variável PROCNAME com a versão truncada incluindo o caminho):

PROCNAME='echo $DAEMON | cut -c -15'

(Em seguida, verificará '/ usr / sbin / postg')

e irá abaixo de "--name":

  stop)
        log_daemon_msg "Stopping $DESC" "$NAME"
        if start-stop-daemon --stop --oknodo --quiet \
                --pidfile $PIDFILE --name $PROCNAME

..

  reload|force-reload)
        log_action_begin_msg "Reloading $DESC configuration..."
        if start-stop-daemon --stop --signal 1 --quiet \
                --pidfile $PIDFILE --name $PROCNAME

(opcional)
Enquanto eu estava nisso, coloquei o arquivo de bloqueio dentro do seu próprio diretório: '/run/postgrey/postgrey.pid'.

Se você preferir em seu próprio diretório, precisará adicionar esse bit para recriar a pasta a cada vez:

PIDFOLDER=/var/run/$NAME
PIDFILE=$PIDFOLDER/$NAME.pid

Verifique a pasta / pasta existente:

check_pid_dir() {
  if [ ! -d $PIDFOLDER ]; then
    mkdir $PIDFOLDER
    chmod 0755 $PIDFOLDER
  fi
}

e adicione a função para "Iniciar":

case "$1" in
  start)
        check_pid_dir
        log_daemon_msg "Starting $DESC" "$NAME"

Meu script init.d completo está aqui: link
Eu não testei tanto assim - mas certamente está funcionando melhor que o padrão até agora. :)

    
por 19.05.2015 / 17:53
0

Isso também será quebrado se você tiver configurado o Postfix para falar somente com IPv4 (Como eu devo, porque o meu ISP ainda não está fazendo IPv6, e meu túnel IPv6 HE sendo marcado por serviços como o Netflix e, assim, quebrando o Netflix ...)

adicionando o host local ao sinalizador de comando INET para o postgrey faz consertá-lo e não se vincula ao IPv4.

Eu não entendo porque ele não pode apenas ligar a ambos IPv4 e IPv6 embora ...

    
por 05.02.2018 / 09:53