Well there are a lot of discussion on this topic,
but looks like that google enforce its security policy and now, if is it still possible, is hard to find a way to send and mail by the smtp protocol using google
my java application works properly, it is not a fact of code, i use it to send mail by outlook365 or hotmail
the point here is how to configure the properties to pass to the session
Session session = Session.getInstance(prop,auth)
and how to configure the google account to accept an smpt call
to be precise I'm using a google workspace account and not a standard#gmail account
regarding the properties should not be a big doubt, this are listed in several pages of google:
regarding the google account, look like there are 3 strategies:
https://support.google.com/a/answer/176600?hl=en
Option 1: Send email with SMTP relay:
after configured the routing form my domain this is the log received
mail.smtp.starttls.enable=true
mail.smtp.port=587
mail.smtp.auth=true
mail.smtp.host=smtp-relay.gmail.com
mail.smtp.ssl.protocols=TLSv1.2
mail.smtp.ssl.trust=smtp-relay.gmail.com --> in this way a consider valid their certificate
but go head...
DEBUG SMTP: protocolConnect login, host=smtp-relay.gmail.com, user=myuser#my.domain, password=<non-null>
DEBUG SMTP: Attempt to authenticate using mechanisms: LOGIN PLAIN DIGEST-MD5 NTLM XOAUTH2
DEBUG SMTP: Using mechanism LOGIN
DEBUG SMTP: AUTH LOGIN command trace suppressed
DEBUG SMTP: AUTH LOGIN failed
Caused by: javax.mail.AuthenticationFailedException: 535-5.7.8 Username and Password not accepted. Learn more at
535 5.7.8 https://support.google.com/mail/?p=BadCredentials
Option 2: Send email with the Gmail SMTP server
tested but this is no more possible, google removed in the 2022 the creation of app password
Option 3: Send email with the restricted Gmail SMTP server
not valid approach, you can send only mail in your organization
if sameone succed could be nice to hear
Apps passwords can be used to login to googles smtp server you need to have 2fa enabled on your google account in order to create an apps password.
Simply create an apps password and use it in place of your standard gmail password in your code.
Quick fix for SMTP username and password not accepted error
How to create a Apps Password for connecting to Google's SMTP server.
Another option would be to use XOauth2 and authorize a user to access their gmail account. This can be used if you cant enable 2fa on the account.
Related
java.lang.RuntimeException: javax.mail.AuthenticationFailedException: 535-5.7.8 Username and Password not accepted. Learn more at 535 5.7.8 https://support.google.com/mail/?p=BadCredentials v7-20020a4a8607000000b0041bdf977c6dsm58061ooh.31 - gsmtp
I am receiving this error when attempting to use javax.mail API to send emails over my GMail account. I attempted to check my settings to verify it allows less secure apps to use my GMail account but the Google website says
To help keep your account secure, from May 30, 2022, Google no longer supports the use of third-party apps or devices which ask you to sign in to your Google Account using only your username and password.
Does anyone know where I can find a current guide on how to build hooks to send/receive mail messages with my GMail account that gets around these new requirements?
Access the page with your Gmail/Google Account -> https://myaccount.google.com/security
In the Signing in to Google section, enable the 2-Step Verification
After enabling 2-Step Verification, return to Signing in to Google section
Click on App passwords
Select app as Mail and select device as Other - choose a name
Done! Copy the password and use it with the username account
When I run my application locally, everything works correct, mails are sent, but I deployed my application to aws EC2 and I get this:
org.springframework.mail.MailAuthenticationException: Authentication failed;
I have less secure apps turned off on my gmail account I send emails from, the two steps verification is also turned off. As I said, everything was working before I deployed the app to aws.
Properties:
mail:
host: smtp.gmail.com
username: <my.mail>#gmail.com
password: <my.password>
port: 587
protocol: smtp
properties:
mail.smtps.auth: true
mail.smtp.starttls.enable: true
mail.smtp.ssl.trust: smtp.gmail.com
Am I missing any property or something like this?
This looks like duplicate from:
javax.mail.AuthenticationFailedException: 534-5.7.14 <https://accounts.google.com/signin/continue?sarp=1
Ok, I finally solved this. The problem is that google blocks EC2 ports so what I needed to do was to turn on 2 steps verification in my google account -> then create new password (option under setting 2 steps verification) -> set this password in my .yml file as the new one -> everything works
I also set the SMTP rules in my EC2 security groups but I am not sure if it had any impact or the steps I have descripted above are enough
I developing a web application with kerberos (v1.0.1) authentication.
My aim is to provide a login through the windows authentication Active Directory (Windows Server 2008 R2).
The problem is that the browser send to the Back End NTLM ticket instead of Kerberos ticket.
I used wireshak to check the communication work flow:
I make a rest call on the back end
application server response to me 401
browser call the kerberos service on the active directory and received the TGS_REP
now I expected that browser calls my rest service with the Kerberos token, but I received the NTLM token instead
My back end service, developed in JAVA, throw the following exception:
GSSException: Defective token detected
EDIT 1:
The first problem is that we used the IP to generate the SPN and the KEYTAB. So, we created the keytab in this way:
ktpass /out c:\keytab\myuser.keytab /mapuser myuser#company.com /princ HTTP/myuser.company.com#WELLD.CH /pass mypassword /ptype KRB5_NT_PRINCIPAL /crypto All
Then we added our BE server on the DNS
<ip_server> myuser.company.com
At the moment we can login with kerberos, and the BE (spring boot) successfully validate the kerberos' token, but we can't download the user information with KerberosLdapContextSource, so we adopt a workaround and used the DefaultSpringSecurityContextSource Bean.
Someone have any idea or references to rely on?
Thanks
I am facing problem related to authentication with exchange server 2010. Same was working with 2007. Below is debugging logs.
Properties props = System.getProperties(); <br/>
props.setProperty("mail.debug.auth", "false"); <br/>
Session session = Session.getInstance(props, null); <br/>
session.setDebug(debug); <br/>
store = session.getStore("pop3"); <br/>
store.connect(host, user, password); <br/>
The Debug logs are:
+OK The Microsoft Exchange POP3 service is ready. CAPA
+OK TOP UIDL SASL NTLM GSSAPI PLAIN USER STLS DEBUG POP3: authentication command trace suppressed
DEBUG POP3: authentication command failed QUIT
+OK Microsoft Exchange Server 2010 POP3 server signing off. javax.mail.AuthenticationFailedException: Logon failure: unknown user
name or bad password. at
com.sun.mail.pop3.POP3Store.protocolConnect(POP3Store.java:209)
at javax.mail.Service.connect(Service.java:345)
This JavaMail FAQ entry might help:
I'm having trouble logging into my Microsoft Exchange server, even though I'm sure I'm using the correct username and password, what could I be doing wrong?
If not, you'll probably need to contact your server administrator to find out what you're doing wrong.
I was also facing the same issue:
I tried with the below setting in Gmail Account:
Click in 9 Dots menu option, on the right top corner of Gmail.
Open "Account"
On the Account page, there you will get the Option "Security", click on it.
Scroll down and find "Less secure app access".
For me, it was OFF. ON it and my access is working fine.
Relating to my other question: UnboundID LDAP DIGEST-MD5 binding cause NPE
I'm using ApacheDS as the server and UnboundID as the API.
I followed the suggested answer and the NPE is gone. However, now I'm getting this error.
LDAPException(resultCode=49 (invalid credentials), errorMessage='INVALID_CREDENTIALS: DIGEST-MD5: cannot acquire password for 'dn:uid=blah,ou=dev,dc=blah,dc=com in realm : mizar.com', diagnosticMessage='INVALID_CREDENTIALS: DIGEST-MD5: cannot acquire password for dn:uid=blah,ou=dev,dc=blah,dc=com in realm : blah.com')
at com.unboundid.ldap.sdk.LDAPConnection.bind(LDAPConnection.java:1881)
at UnboundDemo.main(UnboundDemo.java:40)
Code as follows:
conn = new LDAPConnection("1.1.1.1",389);
mdBind = new DIGESTMD5BindRequest("dn:uid=blah,ou=dev,dc=blah,dc=com", null, "test", "blah.com",null);
bindResult = conn.bind(mdBind);
System.out.println("MD5 bind success!");
Here's the ApacheDS SASL configuration from the Directory Studio config page:
SASL Host: 1.1.1.1
SASL Principal: ldap/ldap.example.com#EXAMPLE.COM
Search Base Dn: ou=dev,dc=blah,dc=com
The ApacheDS doc didn't explain what the SASL Principal is so I'm starting to think that it may be a mis-config on my part. The main idea here is to test UnboundID against a number of SASL mechanism.
It is likely the case that the ApacheDS server isn't configured to store passwords in a format that allows it to determine the clear-text value for the password.
The primary attractive property of the DIGEST-MD5 and CRAM-MD5 SASL mechanisms is that the password is combined with other information and encoded with a one-way digest before being sent to the server. This ensures that the password is not transmitted in the clear, so that it is protected against anyone who can observe the communication without the need to secure the rest of the communication. However, the ability to authenticate with one of these mechanisms requires that the server be able to determine the clear-text version of the password so that it can perform the same cryptographic processing as the client.
If you're just looking to test the UnboundID LDAP SDK's ability to perform SASL authentication, then I'd recommend using the PLAIN mechanism, since it shouldn't impose any special requirements on the user entry. If you really want to use DIGEST-MD5, then you'll need to ensure that the server has access to the clear-text representations of the passwords for the users that need to authenticate with that mechanism.
Neil