SMTPSEND - autenticando

[Mário Isa]

Amigos,
Utilizo SMTPSEND e faço autenticações com as cláusulas
-luusuario e -lppassword
Dá tudo certo quando transmito daqui de minha empresa ou de qualquer outra onde o Uol (que é o provedor tanto meu como delas) está ativo.

Mas se for numa empresa ou pessoa que esteja conectado à net através de outro provedor que não o Uol aí não autentica.

É que meu software está enviando mensagens para mim como se fosse eu mesmo, com a minha própria conta e senha.

[jluizsc]

Bah, tenho notado q em alguns provedores nao esta funcionando,
geralmente indico utilizar outro como o bol, pop, ibest...
[]´s

[casesistemas]

Qual Versao do SMTPsend você está usando
procure atualiza-la no link abaixo:

http://www.dataenter.co.at/download.htm

Eu tive um problema parecido, com a SuperIG, e funcionou...

Joao Carlos

[Maligno]

Uma lembrança: alguns servidores estão começando a exigir autenticação SSL. É o caso do iBest e GMail, por exemplo. Se não me falha a memória, há um esquema especial, um pouco mais chato e complicado, para usar SSL no SMTPSEND. Quanto ao Blat, que é uma boa alternativa também, não sei dizer.

[wfr123]

bom dia, a todos.

Estou tentando utilizar o smtpsend ele para envair emails automaticos de dentro do meu sistema, em clipper.

ja realizei varios testes e todos funcionaram, mais ainda tenho um problema.

Como ter certeza que o email foi enviado, já tentei configurar o sendmail para solicitar a confirmação de leitura mais não funcionou não sei se foi porque utilzo o webmail do uol,ig,yahoo, mas nenhum solicitou a confirmação, e também nao recebi nenhuma confirmação dos emails enviados.

Gostaria de saber se pode me ajudar com alguma solução.

Também ja tentei com o blast mas nao houve nenhuma resposta de confirmação.

Para utilizar este sistema sem ter como confirmar que o destino recebeu fica dificil.

no aguardo.

[alxsts]

Olá!

Tive este problema no ano passado. Entrei em contato com o fabricante do software. Segue abaixo a transcrição dos e-mails. Não sei se mudou algum parâmetro de lá até hoje. Teste o que me foi passado. Caso não funcione, entre em contato com o Michael Kocum.

RE: Information about SmtpSend‏
De: Michael Kocum (michael@dataenter.co.at)
Enviada: quinta-feira, 23 de outubro de 2008 17:18:06
Para: Alexandre Santos (alxsts@hotmail.com)

Delivery: -dFSD Read: -mrr

--Michael Kocum [DataEnter]
michael@dataenter.co.at

-----Original Message-----
From: Alexandre Santos [mailto:alxsts@hotmail.com]
Sent: Thursday, October 23, 2008 9:11 PM
To: Michael Kocum
Subject: Information about SmtpSend [html-removed]

Dear Michael,

i've got some help from you, two years ago and I need some support again. I hope you can help.

Please, here's the question:need to send mails using SMTPSEND, under Win XP Pro and get a delivery or read confirmation from the receiver. Is that possible?

Alexandre Santos

[Maligno]

Importante lembrar que, conforme a pergunta do OP ("Como ter certeza que o email foi enviado"), não há de fato um meio simples de saber se o destinatário leu ou mesmo recebeu o eMail. O switch indicado para o SMTPSEND apenas insere o comando "Disposition-Notification-To:" no cabeçalho do eMail. O cliente de correio do destinatário identificará esse comando e, conforme a configuração, avisará o usuário do pedido de envio de um aviso de recebimento. Mas há quem configure o cliente de correio para nunca enviar esse tipo de aviso. Nesses casos não adianta nada.



PS: Como esse tópico foi "ressucitado" depois de muito tempo por alguém que não é o autor original, em breve vou movê-lo para a seção "Ferramentas de Apoio", que é o lugar dele. Só vou esperar que as partes atentem para meu aviso.

[wfr123]

Otimo, alxsts, obrigado pela sua atenção.

Realmente funcionou, o problema é que nao estava utilizando os 2 switchs apenas o -mrr e não o -dfsd com os dois estou recebendo o retorno das mensagens enviadas.

Agora vendo o retorno das mensagens me surgiu outro detalhe como tratar estas mensagens, pois a unica coisa que vejo que tem algum vinculo com a mensagem enviada é o email do destino.

Existe alguma outra maneira de identificar a mensagem enviada com a confirmação do envio. Tipo no final da mensagem recebo vem estes numeros:

<nomedoemaildestino@terra.com.br>: delivery via 127.0.0.1[127.0.0.1] 250 2.6.0
Ok, id=17454-10-3, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as
542B9E0001F0

Este ID=????: por exemplo tem algum vinculo com a mensagem enviada.

Obs: maligno me desculpe pelo local onte postei, mas é que procurei no item de ferramentas e não encontrei algo especifico e para nao abrir um novo escolhe este aqui.

[Maligno]

Não sei como é o SMTPSEND (nunca usei), mas se estiver no padrão, no cabeçalho da mensagem enviada há um rótulo "Message-ID:" seguido pela identificação (única e original) da mensagem. Na mensagem de confirmação de resposta (se emitida) segue um anexo (texto) onde deve constar esse mesmo número de identificação.

Mas lembre-se: se a mensagem não tiver essa confirmação não significa que não foi recebida ou lida. Pode até significar isso, mas também pode significar que o destinatário não quis enviar a confirmação.

[alxsts]

Olá!

Bom saber que funcionou!

Não sei qual é o objetivo da tua aplicação mas, pelo expôsto nos tópicos anteriores do Maligno, se você estiver condicionando a execução de algum processo ao recebimento/leitura da mensagem, penso que seja arriscado, visto que o destinatário pode configurar o cliente de correio para não enviar confirmações.

[wfr123]

Maligno, entendo o que disse, na questão do retorno da mensagem, mais quanto a isto nao me preocupo, pois a confirmação vai interesar mais ao remetente do que a mim.

Agora quanto ao cabeçalho nao imagino como ter acesso a ele, pois quando executo o comando e ele envia a mensagem, só tenho retorno dos dados abaixo:

SMTPSend v3.37 (WinVista)
(c) copyright DataEnter GmbH 1993-2009


From: remetente@uol.com.br
To: destinatario@uol.com.br

Adding osimpre.pdf (1717 Bytes) as attachment... >> arquivo atachado
Adding TEXTO.TXT (14 Bytes) to message body... >> arquivo texto com o corpo da mensagem
Sending Message ... >> retorno da mensagem
Message sent! >> retorno da mensagem

Este arquivo acima é gravado com a opção >>txt.txt no final do comando ou seja as mensagens são direcionadas para o arquivo txt.txt.

Obs: se não usa o stmpsend.exe então qual que usa, é algum melhor, vi um comentario seu para a api wapi do windows, mas pesquisando seu manual la só tem como identificar a internet e baixar um arquivo, se tiver outra solução para clipper, gostaria de conhecer.

[Maligno]

Agora quanto ao cabeçalho nao imagino como ter acesso a ele

Imaginei que haveria alguma dificuldade nessa parte. O programa não teria alguma opção para gerar um arquivo de saída, espelho do que foi enviado? Se tiver, resolve o problema.

se não usa o stmpsend.exe então qual que usa

Não uso nada ainda. Mas vou precisar usar no futuro. Mas daí, como já estou no Windows, tenho componente pronto pra isso, que me permite controle total e dentro do próprio programa.
Na biblioteca WAPI não há nada relacionado a eMail. É apenas aquilo que você mesmo viu.

[Maligno]

Em tempo: esqueci de dizer que há sim outra solução para Clipper, em linha de comando: BLAT. Ele é bem parecido com o SMTPSEND, mas ao que me consta é (ou pelo menos era) bem menor, apesar de ter as mesmas funcionalidades. Acho difícil dizer qual é melhor. O BLAT sempre recebeu bons comentários. Visite a página oficial e avalie você mesmo.

[wfr123]

Ok, realmente creio não ter como vincular uma mensagem com a outra, até porque são mensagens diferentes, o unico modo foi colocar o smtpsend para retornar uma mensagens apenas quando falhar a entrega da mesma e ai tratar manualmente verificando o email do destinatario da mensagem que retornou com falha.

Sendo assim, de minha parte encerro estas dúvidas.

Ps: quanto ao blat também é muito bom tem as mesmas funções do smtpsend com a vantagem ser bem menor.

Obrigado a todos.

[alxsts]

Olá!

Com um pouco de atraso, seja bem-vindo ao fórum wfr123!

É frustrante querer fazer algo e não conseguir... Você não postou detalhes do teu aplicativo. Talvez um EDI fosse mais apropriado mas, não sabemos.