Página 3 de 3 PrimeiroPrimeiro 123
+ Responder ao Tópico



  1. #11
    Arkanoid
    Citação Postado originalmente por karfax
    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,

  2. #12
    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,



  3. #13
    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

  4. #14
    #########################
    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.



  5. #15
    gmlinux
    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






Tópicos Similares

  1. Não consigo enviar email para dominio google
    Por spartac0s no fórum Servidores de Rede
    Respostas: 5
    Último Post: 10-11-2011, 11:47
  2. Não consigo enviar arquivo para esse site!
    Por adepad no fórum Redes
    Respostas: 7
    Último Post: 12-03-2009, 08:32
  3. Não consigo enviar email para o ig!!!
    Por thelast no fórum Servidores de Rede
    Respostas: 19
    Último Post: 15-03-2006, 13:54
  4. Respostas: 6
    Último Post: 09-09-2003, 07:23
  5. Não consigo enviar nem receber email
    Por no fórum Servidores de Rede
    Respostas: 3
    Último Post: 28-04-2003, 14:08

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L