nao consigo enviar para algins dominios
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,
nao consigo enviar para algins dominios
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
nao consigo enviar para algins dominios
#########################
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.
nao consigo enviar para algins dominios
Citação:
Postado originalmente por Anonymous
#########################
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 :)