I am trying to send email using PutEmail processor in Nifi. Below is the configuration of the processor.
However, emails are not sent and getting this error. It would be great help if addressed.
#techno_mad - I would trust the error message. Test with a known working smtp combo with 100% confirmed smtp access. I also suggest, paste the nifi error as text, not an image. Your peers need to visit the link and are likely not typing it out.
https://support.google.com/mail/thread/5621336?hl=en
Test enabling “Access for less secure apps” (which just means the
client/app doesn’t use OAuth 2.0 - https://oauth.net/2/) for the
account you are trying to access. It's found in the account settings
on the Security tab, Account permissions (not available to accounts
with 2-step verification enabled):
https://support.google.com/accounts/answer/6010255?hl=en
Related
I have a gmail account that I want to use for one of our internal services. We have a server running and we want this gmail account to be used to send out an automated email to people who register.
Now, here's the problem. I have correctly configured my gmail id in the server and know that I am able to correctly ping the gmail smtp server. However,I always get stuck because gmail by default expects you to verify any new device you log in from using an OTP. In my case, this is the first time login from this server machine and hence this happens. I can see it in the logs as well - it brings up this device verification page.
Some questions:
Is there a way I can turn off this feature in gmail? I don't think this is the same as 2 step verification. I have turned it off. I have also enabled my gmail account to be accessible from non secure apps.
If not, is there a way to do the verification step via command line on my Linux server?
Any other smtp based email service I could use that does not have so many security features?
Lastly, I am doing this for a quick prototype. Therefore I am ok bypassing some of these aspects. However, I would definitely want to ensure that the access to my account is secure once this is productized. Any links on how we can do this from non google apps or services?
Thanks in advance!!
It sounds to me you have an application that needs to work on your behalf and do some gmail-related tasks.
If that's the case, why not use the Gmail API with Service Account impersonation?
In short, a service account can impersonate a real user. This is a process that does not require manual input after it's setup, so it's ideal for server-side usage, where you might not even have a UI to interact with.
Also, the Gmail API is much easier to set up than Gmail SMTP, and there are examples out there on how to do this with this setup. You can look at this answer for some references on what it would take.
I'm attempting to connect to Office 365's Exchange Web Services, but it keeps coming up with a 404 error. I'm pretty sure the issue is with the credentials, but I seem to lack the knowledge to resolve it.
I performed a test via testconnectivity.microsoft.com (Service Account Access test under the Office 365 tab) and it is also getting a 404 error. I know from searching online that the format of the credentials is a common problem, however it is in the 'user#company.com' format.
I think the problem may have something to do with the domain or that the authentication goes through my company's server. For example, if I log into outlook.office365.com with the 'user#company.com' format, it forwards me to my company's log on portal (I believe this is a typical setup). In order to log in, I first have to change the user name from the 'user#company.com' format to 'user#domain' or 'domain\user' (the domain is different from the company name).
My question is, since the authentication goes through my company's server, do I need to authenticate to Exchange Web Services in a different manner? (Currently I'm using a WebCredential)
Alternatively, if my company's portal were to accept user#company.com as a valid user name, would that allow me to connect to EWS using a WebCredential?
This is the code I'm using for the connection, however I don't think it is the problem given that Microsoft's test site was also getting a 404 error.
service = new ExchangeService();
service.Credentials = new WebCredentials("user#company.com", "password");
service.Url = "https://outlook.office365.com/ews/exchange.asmx";
Google offers two systems for accessing Gmail. IMAP and SMTP and a the Gmail rest api Gmail - Scope for SMTP is https://mail.google.com/. However with Gmail rest API, just the required scope (like send, modify) can be used.
What are the main differences between the implementation of these two for sending an email? I've been using SMTP to send the mails without any issues but since that involves having a bigger scope for OAuth2, I want to know if there are any possible risks involved in moving to the API approach.
Users.messages: send says there's a restriction on attachment size.
This method supports an /upload URI and accepts uploaded media with
the following characteristics:
Maximum file size: 35MB Accepted Media MIME types: message/rfc822
Are there any other differences that I should know about if I start using Gmail APIs instead of using SMTP connection for OAuth2.
Also, what is the reasoning behind providing full access as the only possible scope for SMTP/IMAP?
Note: I only requirement is the ability to send emails.
Using SMTP you are directly accessing the mail server located at mail.google.com. SMTP servers have been around since the 60's they don't have the ability to limit what access you have. When you log in you have full access to do what ever the mail server in question is capable of. To login to the SMTP server you need the login (most often email address) and password of the account you wish to access. Drawback to using the SMTP to connect to Gmail is that if the user changed the password you would then loose access. This day in age it is also considered by most to be bad practice for third party developers to be storing a users login and password in your system. For example: I would never give any application access to my login and password to Google. How could you ever prove to me that your system is secure? If your hacked so am I.
Now on to Oauth2. Oauth came about sometime around 2005 when people wanted to be able to access APIs without having to do something stupid like
http://awsom.api.com?login=xxx&password=XXX
If memory services it was originally created for the twitter API developers wanted to be able to access their users twitter account without having to store their login in and password. Again the main problem with this was the developer in question would then have full access to a users twitter account and if the user or the developer changed the password things would break.
So they created OAuth. The main features with OAuth are:
You can limit access you give an application: (readonly, read write)
Password change does not affect access
No sharing account credentials with developers of third party apps
So the main point for me as a developer using Oauth with any Google API would be not having to store the login and password of my users and not being affected by a password change. My users would probably say not having to share their login with me and being able to give my application limited access to their account.
Now back to Gmail. Google made a change about two months ago any refresh token(oauth2) that was created using a Gmail scope will automatically expire when the user changes their password. To my knowledge this is only Gmail. so that removes point number two from the features of oauth.
Which should you use is really up to you, assuming you need to be able to send emails. Then limiting access to read only in your application isn't something you need (point one). However in my opinion from a security standpoint I would never ask my users to give me their login and password and would always choose oauth2. Yes SMTP works, will Google shut it down, probably not users have always been given access to the direct SMTP server of their email provider its how applications like outlook work.
as for OAuth support with SMTP unfortunately I haven't done much research into that guess I need to read RFC 4422 . If you can use OAuth with SMTP servers then again I guess the question would have to come down to speed is it faster to access the SMTP server or the REST API server? I can really think of no differences. Attachments with the Rest API can be tricky. I may do a bit more digging on the subject.
I am trying to make a simple integration to BOX where I only access my own account. Since this is a server-side access, (the server-process calls the Box-api), having the Oauth 2.0 redirecting is a problem.
Is there a way I could acquire a token (even manually) and use it in my code, by-passing the hassle of Oauth 2.0 and the redirection ? Or may be some other way for this kind of scenario ?
Right now you can do this with a Developer Token, but that only lasts for 1 hour.
You can also do the auth on your laptop, then put the Refresh tokens into your server in a config file, much like you might do for a database-password file (hopefully only readable by the service-account on the machine that has access to run your script).
Then build your script to take the refresh-token, go get a token pair with it, and write the new refresh token into the config file.
Perhaps a special command or message header in order to be able to tell Google to not store a message sent using their SMTP server in the respective user's Sent mailbox.
There is no way to prevent the message from being saved to Sent. However, you can connect via IMAP after the send and delete the message from the Sent folder. Assuming you are using OAuth authentication, the same scope you use for SMTP allows you to connect via IMAP.
I was also stucked in this kind of scenario some time back, for me I could not find any standard API to solve this. But as a workaround I have created a rule which deletes all the mails which appears in Sent Folder. But beware of IMAP protocol, it allows users to store their there sent messages in custom folders also.