nao consigo enviar para algins dominios

[Postfix]

Colegas,

Tenho um servidor postfix interno em minha rede , somenete para entrega , o objetivo é entragar as mensagens mais rapidamente e manter um certo controle de envio por destinatáriso e quantidade de mbs enviados.
Bom, para nao ter prb quanto a seguranca o acesso externo a este servidor está bloqueado, somente para 192.168.XXX.XXX (rede interna) , ou seja DROP na 25 na interface do link. Para amenizar a situacao de entrega solicitei uma entrada dns para o dominio = teste.com.br em um provedor ou seja, se executo ping smtp.teste.com.br consigo a resposta apontando para meu ip, nao há apontamento MX ok? fiz isto apenas para evitar certos tipos de bloqueios.
Agora o problema:

Envio para alguns emaills e tudo bem , mas quando envio para hotmail, yahoo etc.. nao chega.. oque estou fazendo de errado?

Segue as linhas do posftix:

readme_directory = no
mydomain=teste.com.br
myorigin=$mydomain
myhostname=testeserver
mynetworks=127.0.0.0/8 192.1680.0/24
smtpd_recipient_restrictions=permit_mynetworks,reject_unauth_destination
smtp_connect_timeout=30
smtp_helo_timeout=300
smtp_mail_timeout=300
smtp_rcpt_timeout=300
smtp_data_init_timeout=120
smtp_data_xfer_timeout=180
smtp_data_done_timeout=600
smtp_quit_timeout=300
daemon_timeout=18000
ipc_idle=100
ipc_timeout=3600
max_idle=100
trigger_timeout=10
delay_warning_time=0
smtpd_timeout=300
smtpd_error_sleep_time=1
command_time_limit=1000
deliver_lock_delay=1
fork_delay=1
stale_lock_time=500

[irado]

faltou o mais importante: as mensagens de êrro (DEVEM existir, se houver bounce) e as mensagens do /var/log/mail ou o log que vc estiver usando

[reposta]

Colega,

Verifiquei em minhas contas testes nos webmails hotdroga(hotmail) e yaboo(yahoo) , elas chegaram mas.. com 1 dia de atraso...

Que porcaria e esta?, os caras so liberam dominios com alto uso na net . claro tb criei o maldito contato para tentar passar direto.. nada...

Como posso resolver isto?

Sobre a sua observacao , se for o que eu estou pensando.. as mensagens com prbs voltam imediatamente para o usuario , com a famosa msg de undelivery..

[ ]'s, se vc pode me ajudar agradeco

[vechiato]

certo

As mensagens chegaram atrasadas, mas no seu mail log elas foram entregues imediatamente ?

Por acaso pode ter sido um problema nos servidores.
Alguns provedores não aceitam email de ips de banda larga por causa de spam.

Algumas empresas maiores nem estão aceitando emails de webmails gratuitos como htomail e yahoo, também por spam e principalmente virus

[barata_branca]

koé velho, de bouaz?
pois é, fica relax q isso é coisa dos filhos da M$... o hotmail tem essa grande demora msm... eu passo pelo msm... isso é, quando chega o email... e sem contar quando eles barram ...
F L W!!!

[whinstonrodrigues]

Blz amigo, eu trabalho com sendmail, mas achei "algo meio estranho" no seu post.. Os servidores se comunicam pela porta 25, de sendmail pra sendmail.
Ou seja, eu na minha estação mando algo pra [email protected] para [email protected]. O meu outlook entra pro sendmail do servidor whinston.com.br, que vai até o under-linux.org (tudo isto pela port 25) e pergunta se existe o usuário admin, se existir ele entrega a msg, senão, retorna erro pro meu whinston.com.br "user unknown". Quando o admin for buscar a mensagem no under-linux.org, fará isto na porta 110 (pop).
Pelo que você nos falou, a sua porta 25 é fechado para o "mundo exterior". Com isto, não tem como (teoricamente) o mundo exterior (outros servidores) falarem com o seu servidor. Não seria isto ?

[vechiato]

Blz amigo, eu trabalho com sendmail, mas achei "algo meio estranho" no seu post.. Os servidores se comunicam pela porta 25, de sendmail pra sendmail.
Ou seja, eu na minha estação mando algo pra [email protected] para [email protected]. O meu outlook entra pro sendmail do servidor whinston.com.br, que vai até o under-linux.org (tudo isto pela port 25) e pergunta se existe o usuário admin, se existir ele entrega a msg, senão, retorna erro pro meu whinston.com.br "user unknown". Quando o admin for buscar a mensagem no under-linux.org, fará isto na porta 110 (pop).
Pelo que você nos falou, a sua porta 25 é fechado para o "mundo exterior". Com isto, não tem como (teoricamente) o mundo exterior (outros servidores) falarem com o seu servidor. Não seria isto ?

se seu servidor apenas envia emails ele nao precisa estar aberto para a internet.

[irado]

Verifiquei em minhas contas testes nos webmails hotdroga(hotmail) e yaboo(yahoo) , elas chegaram mas.. com 1 dia de atraso...
Como posso resolver isto?
[ ]'s, se vc pode me ajudar agradeco

sem log´s.. sem idéias

[karfax]

Veja: "Se seu servidor só envia e-mail, ele não prcisa ter aberta a porta 25". Isso entra para os anais da maior bobagem que eu ouvi este ano sobre smtp. Tente não ter uma conta no servidor smtp "para onde" vc está tentando transferir/enviar e-mail...

Claro que ele não irá aceitar. O envio de mensagens por servidores smtp é uma conversa entre dois pares ip/porta (25, neste caso).

Se vc tiver um server sem DNS, e aceitar, como acima, é um OpenRelay. Um lixo de servidor que aceita spam de qualquer um. Tem que ser banido já. Vai usar smtp? Configure um, um DNS e boa sorte. Sem isso, melhor usar uma conta em provedor de terceiros. Se não, procure ajuda profissional. Graças a Deus, smtp não é assunto para leigos.

Sds,

[gmlinux]

Quando um servidor transfere uma mensagem para outro, o primeiro usa uma porta >1023 e conecta-se na 25 do segundo, se este servidor for funcionar como gateway, realmente não é necessário que sua porta 25 esteja aberta ao mundo, apenas para a rede interna.
Evidentemente, que se esta máquina será um gateway de email, deve-se usar algo como o fetchmail para buscar as mensagens e armazena-las neste servidor, e os clientes então usariam o pop/imap deste gateway.

Se este servidor for um MX válido na internet, a porta 25 deve estar aberta para o mundo (motivo óbvio).

Lembre-se de configurar corretamente o relay.

[Arkanoid]

Claro que ele não irá aceitar. O envio de mensagens por servidores smtp é uma conversa entre dois pares ip/porta (25, neste caso).

Negativo. Cada servidor smtp estará escutando na mesma porta 25, mas ao fazer conexão de um para outro o que faz a conexão irá usar um outro número de porta qualquer.
Experimente conectar na porta 25 de qq servidor smtp com o telnet e enviar um e-mail "na mão". A porta usada pelo teu telnet não será a 25 (confira com o netstat), no entanto o servidor na outra ponta irá aceitar o e-mail. Ou use um cliente de e-mail qq e confira com o netstat,

[karfax]

Veja, acho que expressei mal. O motivo pelo qual o servidor de lá -o que irá receber - não deverá aceitar mensagens do servidor de cá são:
Se servidor de cá não tive um servidor DNS válido e funcionando,
Sem uma entrada MX válida,
Estiver Fora das listas mais usadas de anti-spam,
O sender não possuir uma conta válida- virtual ou não lá para onde estou enviando,
Ou daquí, do domínio de onde estou enviando.

O motivo pelo qual a restrição de possuir um smtp server ativo e funcionando aqui - de onde estou enviando e-mail - caso minha conta seja local, é uma restrição anti-spam. E isso é verificado no momento do envio através de uma solicitação diretamente para o smtp do sender. Caso o sender não possua uma conta no dominio de onde se origina a mensagem, o servidor não deverá aceitar a mensagem para entrega.
Isso é uma restrição contra spam, e essa verificação só poderá ser feita caso haja um smtp ativo na outra ponta.

É por isso que eu disse que era necessário que minha porta 25/smtp tinha que ter um smtp ouvindo, por que se não estiver ouvindo, todo o processo de remessa vai abortar - pois a verificação não pode ser realizada.

É isso que eu quis dizer com uma conversa direta na porta 25 entre os dois smtp. Na verdade é um processo que ocorre em background: durante a remessa da mensagem, antes do timeout, o sender deve responder pela porta 25 afirmando que o usuário que está enviando tem uma conta válida, caso contrário a mensagem não é enviada.

Sds,

[gmlinux]

Cuidado para não misturar funcionamento de protocolo com adendos sem explicitar, usuários leigos no assunto em questão podem não diferenciar e serem induzidos ao erro. (controle de spam, por exemplo).

Aqui por exemplo o cara poderia usar um relay host apontando no SMTP server do próprio provedor, os controles de spam baseado no que o cara tenha um SMTP server não poderiam ser aplicados.

o que esta em vermelho acima foi acrecentado para esclarecer melhor o que quero dizer pois não estava no meu original e pode ter criado alguma confusão

#########################
Aqui por exemplo o cara poderia usar um relay host no SMTP server do próprio provedor, os controles de spam baseado no que o cara tenha um SMTP server não poderiam ser aplicados.
#########################
Ainda assim - e sobretudo neste caso - a mensagem é direcionada para o servidor local e o nexthop será o servidor apontado no "relay_host". Isso não irá funcionar, se não ouvir algo "ouvindo" aqui na porta 25? Isso não é exatamente o caso de o usuário ter uma conta válida no domínio remoto, ou o smtp server remoto ter que ter uma entrada específica afim de permitir relay do domínio à partir do qual a MENSAGEM É ENVIADA? Ou então aborta tudo e usa diretamente o smtp server configurado no MUA do cliente como sendo aquele do servidor remoto - de novo - contanto que eu tenha uma conta lá ou ele dê relay pro meu dominio.

[gmlinux]

#########################
Aqui por exemplo o cara poderia usar um relay host no SMTP server do próprio provedor, os controles de spam baseado no que o cara tenha um SMTP server não poderiam ser aplicados.
#########################
Ainda assim - e sobretudo neste caso - a mensagem é direcionada para o servidor local e o nexthop será o servidor apontado no "relay_host". Isso não irá funcionar, se não ouvir algo "ouvindo" aqui na porta 25? Isso não é exatamente o caso de o usuário ter uma conta válida no domínio remoto, ou o smtp server remoto ter que ter uma entrada específica afim de permitir relay do domínio à partir do qual a MENSAGEM É ENVIADA? Ou então aborta tudo e usa diretamente o smtp server configurado no MUA do cliente como sendo aquele do servidor remoto - de novo - contanto que eu tenha uma conta lá ou ele dê relay pro meu dominio.

Não entendi direito mais vou tentar responder:
O que eu quis dizer é o seguinte, para clients cuja a origem esteja na rede do provedor (assume-se que ele possui conta no provedor, correto? ), o provedor não usa como controle de spam o fato de o cliente possuir algo na porta 25 (poderia ser simplesmente um MUA enviando email), assim, se eu colocar um servidor smtp e configura-lo para fazer relay host usando o smtp server do provedor, este não pode verificar se minha porta 25 esta ou não aberta, não faria sentido.( o controle de spam neste caso seria, por exemplo, sobre o número de emails enviados simultaneamente )

Assim, se um server usar este expediente de verificar a porta 25, ele só o fará em relacão a máquinas externas a sua rede (ou região de abrangência de seu relay).

No entanto, neste caso, ele poderá verificar se a origem da requisição é um MX também, dai não funcionaria simplesmente abrir a porta.

Por isto, quando configuro um gateway de email, costumo usar um relay-host apontado para o smtp do meu provedor, assim posso fechar a 25 e faço o download dos emails do MX via fetchmail, permitindo manter também o tráfego do pop interno a rede. Que me pareceu a idéia do amigo stfix, que deixou claro que o server dele não é MX.

O esquema de verificar a porta 25 para conexões oriundas de fora da minha rede (e ainda confirmando com o MX) só existe em esquemas de controle de spam, experimenta acessar um smtp server (de fora da rede dele e com relay fechado adequadamente), sem este controle de spam um cliente qualquer poderia enviar emails para usuários do domínio para o qual este server é MX, num contexto de controle de spam baseado na porta e MX, ele só aceitaria se o "cliente" fosse um servidor MX do domínio de origem.

Lógicamente, isto diminui, mais não evita por completo os problemas, alguns provedores permitem abusos de seus clientes, black list para eles