cancel
Showing results for 
Search instead for 
Did you mean: 

Falha no Envio B2B

Former Member
0 Kudos

Boa tarde Pessoal,

Estou com um problema no cenário de envio de e-mail. O erro na sxi_monitor é:

com.sap.aii.af.ra.ms.api.RecoverableException: java.io.IOException: server not responding OK to RCPT TO; 553 5.7.1 sorry, that domain isn't in my list of allowed rcpthosts (chkuser).

Aparentemente o adaptador Mail Recevier não está conseguindo se autenticar no servidor SMTP, pois quando tento enviar para destinatários do mesmo domínio, o e-mail é enviado sem problemas. Habilitei os Tracing Locations com.sap. aii.adapter.mail, com.sap. aii.messaging.net, com.sap. aii.messaging.srt e com.sap. aii.messaging.xmb conforme nota Note 856599 - FAQ: XI 3.0 / PI 7.0 / PI 7.1 Mail Adapter mas não encontrei nada que indique uma falha de autenticação. O Adaptador está configurado com autenticação e já limpei o cache e restartei o servidor.

Fiz um teste da minha estação usando API Java para envio e consegui me autenticar no servidor e enviar e-mails para destinatários de outros domínios. Ao testar via API Java, habilitei o debug smtp usando a propriedade mail.debug = true, existe a possibilidade de setar esta propriedade? Seria no parametro da JVM no configtool?

Existe a possibilidade de existir algum bug ou parametrização errada no adaptador?

Obrigado desde já pela ajuda,

Raphael

Edited by: Raphael Xavier on Jan 25, 2011 3:05 PM

Edited by: Raphael Xavier on Jan 25, 2011 3:06 PM

Accepted Solutions (0)

Answers (1)

Answers (1)

former_member182114
Active Contributor
0 Kudos

Bom dia Raphael,

O erro aponta para Relay proibido, porém seu teste funcionou?!?!? realmente aponta para algo "estranho"...

Para entender melhor...

Você está se comunicando com um SMTP interno para entregas internas e externas, certo?

As internas funcionam e todas as externas não? Já tentou mais de um domínio externo?

O usuário você está usando na autenticação está completo, digo com user arroba dominio.com.br?

E o smtp é sempre o interno?

A configuração do teste Java, é identica? Mesmo SMTP, mesmo origem, mesmo destinatário, mesmo usuário com nome completo, senha...?

Atenciosamente, Fernando Da Ró

Former Member
0 Kudos

Olá Fernando,

Realmente está estranho. Estou fazendo outros testes aqui, e desenvolvi um WS baseado em um EJB e o mesmo código que funciona na minha máquina, não funciona no servidor de aplicação, com o mesmo erro.

Respondendo suas perguntas:

Você está se comunicando com um SMTP interno para entregas internas e externas, certo?

Certo.

As internas funcionam e todas as externas não? Já tentou mais de um domínio externo?

Sim. Não, somente com 1 outro domínio além do interno.

O usuário você está usando na autenticação está completo, digo com user arroba dominio.com.br?

Sim.

E o smtp é sempre o interno?

Sim.

A configuração do teste Java, é identica? Mesmo SMTP, mesmo origem, mesmo destinatário, mesmo usuário com nome completo, senha...?

Sim. Mesma configuração.

Obrigado pela ajuda.

Abraços,

Raphael

former_member182114
Active Contributor
0 Kudos

Bom dia Raphael,

Pode ser configuração no servidor de email que não esteja permitindo relay da máquina PI (hostname, domain, IP).

Você tem como fazer o teste local que fez dentro do servidor?

Esta máquina do PI está no mesmo domínio, mesma rede, ou tem um domínio próprio?

Se tiver acesso ao administrador de emails ele pode dar ajudar nesta investigação.

Atenciosamente, Fernando Da Ró

Former Member
0 Kudos

Olá Fernando,

Refiz o teste local da minha estação, mas usando a mesma versão da JVM que está no servidor e retornou o mesmo erro. Mas quando altero o servidor de e-mail para usar o exchange, por exemplo, o erro não ocorre. (Nosso servidor é Lotus)

Vou procurar a equipe de infra para discutir o problema.

Obrigado,

Raphael

Edited by: Raphael Xavier on Jan 25, 2011 6:22 PM

former_member182114
Active Contributor
0 Kudos

Bom dia Raphael,

Não passei por isso.

Seus testes estão indicando JVM, mas não estou certo do motivo da JVM ter funcionamento diferente.

Vendo o código deste java que você mandou ele faz o teste email a email pedindo o RCP TO ao servidor.

http://www.javadocexamples.com/java_source/com/sun/mail/smtp/SMTPTransport.java.html

Ao meu ver o 553 é externo e o comportamento ao 553 talvez seja diferente nas JVM, talvez algum parm default mudou.

Pra contextualizar, quais as versões de JVM você está testando e qual resultado?

Você já fez um teste direto via telnet no host mandando ver esse RCP TO: na mão para ver o resultado?

Atenciosamente, Fernando Da Ró

former_member182114
Active Contributor
0 Kudos

O lance do servidor de mail tudo bem, faz o maior sentido.

Mas esta da JVM você me deixou encucado.

Former Member
0 Kudos

Fernando,

Detectei que o problema está na versão da biblioteca do JavaMail utilizada pela JVM. Eu fiz um teste alterando a versão do JavaMail e o envio funcionou corretamente.

O problema é que o cliente não quer criar o relay para o servidor que irá fazer o envio das NF-es, alegando que isso seria uma brecha de segurança.

Acredito que terei que abrir um chamado para isso. Poderia me informar em qual componente posso abrir o chamado?

Abraços e obrigado,

Raphael

Former Member
0 Kudos

Fernando, novas informações.

Substituí o jar mail.jar da pasta /usr/sap/<SID>/DVEBMGSXX/j2ee/cluster/server0/bin/ext/mail pela versão 1.4.1 do JavaMail e o envio pelo EJB que criei funcionou, mas não funcionou pelo adaptador. Acredito que o adaptador use outra biblioteca.

Vou tentar encontrar a biblioteca JavaMail que o adaptador utiliza, mas acho que o caminha será abrir um chamado mesmo. O que você acha?

Abraços,

Raphael

former_member182114
Active Contributor
0 Kudos

Bom dia Raphael,

Gostei das suas descobertas.. rsss A propósito qual é a outra versão envolvida?

O chamado para o Receiver Mail Adapter seria em BC-XI-CON-MAI, quanto a uma pergunta direta sobre troca de componente não sei se seria fácil uma resposta. Você poderia mostrar todo o problema, demonstrar tudo que fez e solicitar o como resolver isto.

De qualquer forma a questão para decisão do cliente entendi o receio, mas não os motivos.

Este servidor é facilmente acessível / invadível / mexível?

Ele não poderia abrir apenas para o IP deste servidor?

E quanto à modificação .jar do comportamento do produto standard? A cada upgrade as coisas irão parar de funcionar, precisando refazer o que foi feito, e se for compatível com a nova versão/upgrade.

Atenciosamente, Fernando Da Ró

Former Member
0 Kudos

Fernando,

Na verdade eu também não entendi muito bem qual é ou quais são os motivos de não se criar o relay. E como eles bateram o pé, dizendo que nenhuma aplicação deles utiliza relay, sempre se autentica no servidor, resolvi não me aprofundar na discussão, até porque não tenho muito domínio nesta área.

Com relação a modificação do .jar relamente tem que ser bem documentado para que as coisas não parem de funcionar numa aplicação de patch.

Eu abri um chamado neste componente, vamos ver o resultado. Ainda estou achando estranho este problema acontecer, pois nunca vi esse tipo de problema antes. Pesquisei exaustivamente na internet e nos sdn a respeito de algum bug na versão do JavaMail, sem sucesso. Vou tentar buscar no changelog.

Segue o cabeçalho do MANIFEST do mail.jar no servidor de aplicação:

Manifest-Version: 1.0

SCCS-ID: @(#)javamail.mf 1.4 00/09/26

Extension-Name: javax.mail

Specification-Title: JavaMail(TM) API Design Specification

Specification-Version: 1.2

Specification-Vendor: Sun Microsystems, Inc.

Implementation-Version: 1.2

Implementation-Vendor: Sun Microsystems, Inc.

Implementation-Vendor-Id: com.sun

e esta é a do jar que substituí:

Manifest-Version: 1.0

Implementation-Version: 1.4.1

Specification-Title: JavaMail(TM) API Design Specification

Specification-Version: 1.4

Implementation-Title: javax.mail

Extension-Name: javax.mail

Created-By: 1.4.0 (Sun Microsystems Inc.)

Implementation-Vendor-Id: com.sun

Implementation-Vendor: Sun Microsystems, Inc.

Specification-Vendor: Sun Microsystems, Inc.

SCCS-ID: @(#)javamail.mf 1.7 06/09/22

A título de curiosade, o antigo tem 275 KB e o novo tem 363 KB.

Obrigado pela ajuda. Qualquer novidade sobre o chamado posto aqui.

Abraços,

Raphael

henrique_pinto
Active Contributor
0 Kudos

Raphael,

fazendo uma busca rapida aqui no servidor (PI 7.0x), vejo 5 locais com o mail.jar:

\usr\sap\<SID>\DVEBMGS00\j2ee\j2eeclient

\usr\sap\<SID>\SYS\global\j2eeclient

\usr\sap\<SID>\DVEBMGS00\j2ee\deploying\lib

\usr\sap\<SID>\DVEBMGS00\j2ee\admin\logviewer-standalone\lib

\usr\sap\<SID>\DVEBMGS00\j2ee\cluster\server0\bin\ext\mail

Acredito que valha um teste.

Abs,

Henrique.

Former Member
0 Kudos

Bom dia Henrique,

Então, eu fiz exatamente isso. Fiz uma busca dentro de /usr/sap e alterei todos esses jar's para a versão 1.4.1 do JavaMail.

Tenho mais novidades que já inclui no chamado que abri. No changelog do JavaMail em http://www.oracle.com/technetwork/java/changes-1-150220.txt e no tópico "CHANGES IN THE 1.4.1 RELEASE" encontrei a informação:

"do SMTP authentication if connect is called with username and password even if mail.smtp.auth is not set"

Então, pra fazer um teste, voltei o jar anterior, restartei a instância e fiz um teste no meu EJB usando um código sem setar esta propriedade e aconteceu o erro. Dai atualizei o código setando essa propriedade e consegui enviar o e-mail sem problemas. Agora resta saber como o adaptador faz essa chamada.

Estou aguardando a resposta do chamado e em paralelo estou buscando o fonte da classe com.sap.aii.messaging.net.SMTPClientConnection que faz a chamada no servidor para entender o que ela está fazendo.

Qualquer novidade posto aqui.

Obrigado e abraços,

Raphael

Edited by: Raphael Xavier on Jan 26, 2011 2:38 PM

henrique_pinto
Active Contributor
0 Kudos

Nao sei se dá certo, mas vc tentou setar esse parametro "mail.smtp.auth" para true na seção Advanced Mode?

Abs,

Henrique.

Former Member
0 Kudos

Senhores,

Encontrei a classe e ela não usa a API do JavaMail. A classe se comunica com o servidor de e-mail via socket. Pelo que apurei o problema ocorre porque a classe envia a mensagem de autenticação se a resposta do EHLO começa com 250-AUTH, mas o o servidor esta respondendo na primeira linha 250-HELP e só na terceira linha atenderia a condição, pois nela ele responde 250-AUTH LOGIN.

Vou verificar com a equipe de infra se é possível alterar a ordem destas respostas.

Qualquer novidade posto aqui.

Abraços,

Raphael

Former Member
0 Kudos

Pessoal, problema resolvido.

O pessoal de infra havia me informado dois servidores e no que eu configurei no PI não estava enviando a mensagem 250-AUTH LOGIN na resposta do comando helo e por isso o adaptador não estava se autenticando. A classe que se conecta no servidor SMTP só efetua a autenticação se na resposta do comando helo vier esta mensagem.

A minha falha foi que na ansia de resolver o problema comecei a fazer o teste com os dois servidores, sendo que 1 deles já estava retornando a resposta de autenticação e o outro, que estava configurado no adaptador, não estava.

Obrigado pela ajuda.

Abraços,

Raphael

henrique_pinto
Active Contributor
0 Kudos

Oi Raphael,

que bom que vc achou a solucao.

Por favor marque a thread como respondida.

Abs,

Henrique.

former_member182114
Active Contributor
0 Kudos

Quase que reescrevemos o java mail.. rss

Foi legal

Abraços, Fernando Da Ró

Former Member
0 Kudos

Verdade.. O pior é que ele nem tinha culpa... rs..

Abraços,

Raphael