Erro ao enviar Email - Gmail

[valterpatrick]

Pessoal, estou utilizando a unit alterada que foi publicada em outro post (link abaixo).

Eu criei as credenciais oauth no google e estou tentando fazer o envio de email com a unit alterada que está em anexo, contudo está dando erro ao enviar.

Eu estou configurando conforme está no exemplo que foi apresentado no post anterior, onde estou enviando o escopo, client id, cliente secret, redirect uri, entre outros dados.

Quando tento enviar, sou redirecionado para uma página onde eu clico para autorizar e gero o access token, refresh token e o tempo de expiração de 1 hora, mas dá o erro abaixo:

Erro: SMTP Error: Unable to send MailFrom.
535 5.7.8  https://support.google.com/mail/?p=BadCredentials d9443c01a7336-20c13934817sm1435145ad.158 - gsmtp
530 5.7.0  https://support.google.com/mail/?p=WantAuthError d9443c01a7336-20c13934817sm1435145ad.158 - gsmtp

Configurações:

Host: smtp.gmail.com
Email: [email protected]
Porta: 587 e 465 (testei ambas)
Client id: xxxxxxxxxxxxxxxxxxxxxx
Cliente Secrect: yyyyyyyyyyyyyyyyyyyy
Redirect URI: http://127.0.0.1:1500
Escopo: https://www.googleapis.com/auth/gmail.send
URL AccessToken: https://accounts.google.com/o/oauth2/token
URL: Autorization Token: https://accounts.google.com/o/oauth2/auth
TLS: True e False (testei ambas)
SSL: True e False (testei ambas)
SSLType: LT_TLSv1_2

 

Link Post Anterior:

 

Configuração OAUTH Gmail.pdf ACBrMail.pas OAuth2.Gmail.pas OAuth2.Outlook.pas OAuth2.pas

[Diego Foliene]

3 minutes ago, valterpatrick said:

Pessoal, estou utilizando a unit alterada que foi publicada em outro post (link abaixo).

Eu criei as credenciais oauth no google e estou tentando fazer o envio de email com a unit alterada que está em anexo, contudo está dando erro ao enviar.

Eu estou configurando conforme está no exemplo que foi apresentado no post anterior, onde estou enviando o escopo, client id, cliente secret, redirect uri, entre outros dados.

Quando tento enviar, sou redirecionado para uma página onde eu clico para autorizar e gero o access token, refresh token e o tempo de expiração de 1 hora, mas dá o erro abaixo:

Erro: SMTP Error: Unable to send MailFrom.
535 5.7.8  https://support.google.com/mail/?p=BadCredentials d9443c01a7336-20c13934817sm1435145ad.158 - gsmtp
530 5.7.0  https://support.google.com/mail/?p=WantAuthError d9443c01a7336-20c13934817sm1435145ad.158 - gsmtp

Configurações:

Host: smtp.gmail.com
Email: [email protected]
Porta: 587 e 465 (testei ambas)
Client id: xxxxxxxxxxxxxxxxxxxxxx
Cliente Secrect: yyyyyyyyyyyyyyyyyyyy
Redirect URI: http://127.0.0.1:1500
Escopo: https://www.googleapis.com/auth/gmail.send
URL AccessToken: https://accounts.google.com/o/oauth2/token
URL: Autorization Token: https://accounts.google.com/o/oauth2/auth
TLS: True e False (testei ambas)
SSL: True e False (testei ambas)
SSLType: LT_TLSv1_2

 

Link Post Anterior:

 

Configuração OAUTH Gmail.pdf 279.61 kB · 0 downloads ACBrMail.pas 44.27 kB · 0 downloads OAuth2.Gmail.pas 556 B · 0 downloads OAuth2.Outlook.pas 688 B · 0 downloads OAuth2.pas 5.74 kB · 0 downloads

Boa tarde.

Vinculei o seu tópico a TK que criamos para avaliar implementação do OAuth 2.0 no componente ACBrMail.

[Daniel Simoes]

Vejam essa implementação, de 2019

 

[Daniel InfoCotidiano]

Em testes aqui em meu ambinte o envio p gmail está normal.
Lembrando que a senha é de aplicativo criado nas opcoes de seguranca do google, ou seja, nao é a mesma senha de webmail.

[valterpatrick]

38 minutos atrás, Daniel InfoCotidiano disse:

Em testes aqui em meu ambinte o envio p gmail está normal.
Lembrando que a senha é de aplicativo criado nas opcoes de seguranca do google, ou seja, nao é a mesma senha de webmail.

Quem ainda tem, está funcionando, mas não aparece mais a opção para configurar senha de app.

Em 04/10/2024 at 18:41, Daniel Simoes disse:

Vejam essa implementação, de 2019

 

Eu segui conforme está descrito ai, mas o problema que tenho é que eu preciso fazer alguns procedimentos para que o Google libere o envio de email quando eu uso o escopo "https://mail.google.com/".
Tenho de criar um video no youtube e etc.

Eu não sei se este é o caminho que todos estão fazendo agora, se for isto mesmo vou gravar um video, mas se não for eu gostaria de saber.
Estou nesta dúvida agora.

Pelo o que vi eu teria de seguir isto:

https://support.google.com/cloud/answer/13463073?visit_id=638638963772284873-1041678242&hl=pt-br&rd=1#restricted-scopes

 

Se tivesse alguém que fez recente e pudesse explicar se este é o caminho mesmo.

[Daniel Simoes]

Eu sinceramente acho que é mais simples adotar outro serviço de email...

Existem vários provedores de envio de email transacional, como SendGrid, SparkPost, MailGun, Amazon SES

A Sw.Houses pode criar um Token para cada cliente, e ganha total controle do envio, acesso a logs, e administração dos emails

 

[valterpatrick]

Eu concordo com você, mas o problema é mais o cliente querer aderir a isto e ele não reclamar dos custos.
Os valores da AWS não são altos e creio que na maioria dos meus clientes ficaria em menos de R$0,50 por mês.

Se tudo não der certo, vou aconselhar a usar o AWS SES do qual já uso.

AWS:
https://aws.amazon.com/pt/ses/pricing/

[Juliomar Marchetti]

Ele pode ter um dominio só dele e um servidor de e-mail. mas terá custos também. no caso investimento para ficar enviando os dados corretamente

[marcio.santos]

Boa tarde pessoal !

Tudo bem ?

Eu ia abrir um tópico novo, mas achei esse que ainda não foi encerrado !

"A partir de janeiro de 2025, os apps menos seguros e de terceiros e dispositivos em que você fez login apenas com seu nome de usuário e senha não poderão mais ser usados com as contas do Google Workspace. Confira as datas exatas no blog Google Workspace Updates (link em inglês). Se quiser continuar usando um app específico com sua Conta do Google, você vai precisar de um tipo de acesso mais seguro que não compartilhe dados de senha. Aprenda a usar o recurso Fazer login com o Google."

Hoje ainda funciona habilitando a opção nas configurações de contas, mas essa opção está desaparecendo ! 

Se não for habilitada, acontece o erro relatado pelo Valter na abertura do tópico !

Há alguma previsão de desenvolvimento de algo no ACBRMail ?

Pergunto isso porque vai ser difícil convencer os clientes a trocarem provedor de email, principalmente os que enviam 2000, 3000 emails por dia !

Aguardo !

Muito obrigado !

[Juliomar Marchetti]

Boa tarde.
creio que sim.
logo teremos mais noticias sobre a questão do Auth2 no ACBrMail

[Daniel Simoes]

1 hora atrás, marcio.santos disse:

Há alguma previsão de desenvolvimento de algo no ACBRMail ?

Ainda não está nosso RoadMap

@Juliomar Marchetti, por favor evite responder com prazos, em nome do ACBr, ok ?

Nunca foi correto, usar a conta do cliente, para enviar emails do Seu sistema... isso fere até a LGPD, hoje em dia...

Veja esse vídeo:

 

[valterpatrick]

Citar

Nunca foi correto, usar a conta do cliente, para enviar emails do Seu sistema... isso fere até a LGPD, hoje em dia...

Eu não sabia disto.
No caso o ideal seria ter um email da minha empresa para enviar email dos meus clientes para os clientes deles?

Exemplo: [email protected]

Ai quando o meu cliente quiser enviar email seria enviado deste destinatário né, mas se caso ele quiser enviar do email dele, dando autorização, não teria problema né?

[Alexandre de Paula]

Bom dia @valterpatrick.

O caso é que quando você tem o usuário e senha do email do seu cliente cadastrado no seu sistema você está assumindo uma responsabilidade muito grande sobre tudo que é enviado (e talvez recebido?) no email dele, já que você tem acesso a conta. Por isso que olhando sobre o critério da responsabilidade não é uma boa prática.

Em relação a LGPD, no meu ponto de vista em um resumo muito simplório, mas didático, pode ser encarada como "o combinado não sai caro..." .

A LGPD preza para que todo o tratamento de informações esteja claro e especificado quem pode fazer o que com quais dados. Se no seu contrato de serviço você especificar que precisa da conta de email para fazer determinados procedimentos você deixa claro o que pretende fazer, porém não consegue garantir que essa informação de sua posse (as credenciais) não seria usada para outros fins... esse é um risco que você assume no caso, por exemplo, do seu cliente ter algum problema com o email, pois já que você tem as credenciais dele fica mais dificil você garantir que não tem resposabilidade sobre a operação.

O uso de provedores de email de transmissão dá um maior controle e segurança sobre a operação, por isso a sugestão de uso deles.

Em alguns casos o cliente pode ter uma conta de email separada/especifica para uso no sistema. Isso dá uma garantia maior pra operação do seu cliente, mas se a conta é dele a sua responsabilidade continua a mesma.

No caso de você enviar com uma conta de email da sua empresa você muda o foco da responsabilidade... aí é você que está assumindo a responsabilidade da transmissão de dados que deveriam ser de responsabilidade do seu cliente. Se a NFe é dele, porque está enviando com um email seu?

Enfim, são vários pontos a serem avaliados e não é simplesmente um problema técnico de autenticação.

Espero ter ajudado a complicar mais !!

[valterpatrick]

3 minutos atrás, Alexandre de Paula disse:

Bom dia @valterpatrick.

O caso é que quando você tem o usuário e senha do email do seu cliente cadastrado no seu sistema você está assumindo uma responsabilidade muito grande sobre tudo que é enviado (e talvez recebido?) no email dele, já que você tem acesso a conta. Por isso que olhando sobre o critério da responsabilidade não é uma boa prática.

Em relação a LGPD, no meu ponto de vista em um resumo muito simplório, mas didático, pode ser encarada como "o combinado não sai caro..." .

A LGPD preza para que todo o tratamento de informações esteja claro e especificado quem pode fazer o que com quais dados. Se no seu contrato de serviço você especificar que precisa da conta de email para fazer determinados procedimentos você deixa claro o que pretende fazer, porém não consegue garantir que essa informação de sua posse (as credenciais) não seria usada para outros fins... esse é um risco que você assume no caso, por exemplo, do seu cliente ter algum problema com o email, pois já que você tem as credenciais dele fica mais dificil você garantir que não tem resposabilidade sobre a operação.

O uso de provedores de email de transmissão dá um maior controle e segurança sobre a operação, por isso a sugestão de uso deles.

Em alguns casos o cliente pode ter uma conta de email separada/especifica para uso no sistema. Isso dá uma garantia maior pra operação do seu cliente, mas se a conta é dele a sua responsabilidade continua a mesma.

No caso de você enviar com uma conta de email da sua empresa você muda o foco da responsabilidade... aí é você que está assumindo a responsabilidade da transmissão de dados que deveriam ser de responsabilidade do seu cliente. Se a NFe é dele, porque está enviando com um email seu?

Enfim, são vários pontos a serem avaliados e não é simplesmente um problema técnico de autenticação.

Espero ter ajudado a complicar mais !!

Ficou mais claro agora.

Obrigado pela explicação.