I have a .NET console application that add a list of users in a selected Yammer group through [/group_memberships.json] endpoint and it works fine.
Anyway the customer wants to avoid the sending of a confirmation email to user that has been added. In fact, after my program runs, all users receive an email like "XXX has added you to the YYY group on Yammer. Go to group".
The only way that I found to avoid this email is disable email notification in user settings.
Is there another simple way? Through Rest API is possible tell to Yammer to do not send email or, otherwise, change the user settings? I'm asking it because there're some hidden Rest API not documented in the official Yammer site.
Thanks
Yammer doesn't have any API endpoint to achieve your objective. Your customer may consider adding a rule in exchange to block emails based on the "from" address and certain keywords in the "subject".
Related
I'm writing a program that should send emails to multiple users with content extracted from an excel spreadsheet. I know how to do this using the net/smtp package in Go, but I would like to know if it's possible to send an email with the sender being a google group (i.e googlegroup#gmail.com) instead of my email without resorting to using the gmail API? Currently I have a working program that can log in through an email and password, which is then used for auth credentials, but seeing as that google groups don't have the same kind of interface I'm not quite sure how to change it so emails are sent from a group instead of an individual user.
Each google group should have an email address associated with it. golang-nuts is golang-nuts#googlegroups.com for example. Any mail sent to that should be posted to the group, assuming it is from a member of the group.
In order to send from your own gmail account, you can use gmail's outgoing smtp feature with the net/smtp package. Configuration is explained better on this digital ocean post
I have a domain which uses Google Apps for Business to handle email. I already have it mostly set up--MX records point to the correct location and my domain is verified.
I'm now writing a python app (with Django) that will need to serve mail from my domain. What's the correct way to do this with Google? Should I create a Google Apps "user" for the organization as a whole, and then authenticate via SMTP as that user and send mail from there?
The Gmail API says that it
is the best choice for authorized access to a user's Gmail data.
and that
Automated or programmatic message sending
is a typical use case. However, I'm not trying to access a user's data or send mail on behalf of a user, but on behalf of my domain. What's the correct way to proceed?
Any help much appreciated!
You could use SMTP or the Gmail API based on your description. In both cases, you'll need some sort of service account to send mail from. With SMTP, as you mentioned, you'll be authorizing via the instructions you linked.
If you choose to use the Gmail API route, you'll be authorizing the API usage with the account. The Gmail API has many other use cases (e.g. to access user's data) but you're only using it to send emails on behalf of a service account you control.
I have a web application that allows registration and authentication through Facebook, Google and Windows Live. Each OAuth request has the required scope to retrieve associated e-mail addresses from the authentication provider.
The current situation is that an account is created based on the provider and the provided identifier. This means that if a user has logged in with multiple providers the user will have multiple accounts on the web application.
I want to have the ideal situation of having a single acccount even when using multiple providers. I was thinking about using the e-mail addresses to see if an account exists for the user. If it exists, use the account based on the e-mail address.
How safe/reliable is this? Do all OAuth providers mentioned validate e-mail addresses? Better ways?
EDIT: Ran a tests and came up with this. Still looking for further advice :)
FaceBook: Cannot authenticate with unvalidated e-mail. Additional e-mail will not appear until validated.
Google: Provides `verified_email`. Additional e-mail will not appear until validated.
Windows Live: Cannot authenticate with unvalidated e-mail. Additional e-mail will not appear until validated.
Interesting question. You could try to use e-mail to check if user exists, but the problem is, user could be using different e-mail addresses for different providers.
My suggestion would be asking user (once he/she logs into your application using one of the methods) to attach other providers to to this account, so he/she can use them as well to log into your application.
It doesn't completely solve your problem (I'm not sure if solution exists), but user will have more control that way and you'll reduce the amount of accounts per user.
What is the best way of tracking responses for email campaigns? I was thinking on adding something to the reply-to field of the email (for example luqita+campaigns#stackoverflow.com), but I'm not sure if there is something more neat that could avoid this?
I thought about headers too, but it's important to note that the address luqita#stackoverflow.com would send many different campaigns, and the 'in-reply-to' header info would not be useful then to differentiate (while using luqita+campaign1 or luqita+campaign2 could)
What can I do?
So you want to be able to execute some logic when someone replies to an email you have sent through SendGrid? If you have access to change the MX record of the domain of the email address at which you want to receive the replies, you could use SG's Parse API to get a POST request to a script whenever email is receive at the address.
I think you would indeed have to set a magic reply-to address for each campaign. This seems like a perfectly fine solution; it's also how SG itself tracks bounces - it sets the return-path to something like bounces+{attempted-recipient-email}#sendgrid.com. Then examine the 'to' parameter of the POST notification you receive to know which campaign the reply is associated with.
When you say "tracking responses", do you mean that you expect users will reply to the Email, or do you mean that they'll click on a link in the Email and interact with a web site?
SendGrid obviously offers click tracking and open tracking, and you can set up to 10 different categories for tracking campaign stats and see delivery/bounces/opens/clicks/etc based on those categories. They also have a Google Analytics plugin that can feed back some analytics data to Google. And as #LinusR mentioned in his answer, the SendGrid Parse API can be set up in a way that reply Emails can get parsed and posted back to your site.
If the user will be interacting with your web site, you can use the "unique args" setup at SendGrid to set a unique string/hash to append to any URLs that can help identify a particular user, campaign, or whatever else you want to track.
I'm building a system that allows people to submit text and photos via email in addition to standard access on the website. I'm trying to weight the security advantages of two strategies in particular for verifying submissions from a user. Here they are as follows:
To based auth: Create a secret email address per user and present this to the user for submission. This strategy has the advantage that people can send from multiple devices that might be setup with different mail accounts
From based auth: Only accept emails from addresses that are registered in the user database. The idea being that it is impractical/difficult to impersonate registered users based on the sending address.
Can you think of other possible solutions? Which strategy of the ones proposed makes the most sense to you?
I would suggest that you not use From based authentication, at least not without some additional credentials (a passphrase, etc)
It's way too easy to forge, and certainly not difficult if you know someone's email address.
If you echo the email back to the user for confirmation, you can make things a little more difficult, but realize that your service can end up being used as a sort of spamming relay. (I could send 100 upload requests to you, with a forged FROM address, and you'd go ahead and spam the real person with 100 confirmation requests)
The better option is to check the registered email address but add the need for a code within the email subject known to the user. This way if they forge the email from address, they would still need a key to authenticate the incoming email.
I would go with "from" + confirmation, to avoid forging.
I.e. receive the email, but send a response with auth token in the subject line (or in the body) back to the "from" address. The user either will need reply, or click a link to confirm the submission.
And you post the content only after confirmation.