I'm using Azure websites and they offer email services vie the third party provider SendGrid.
It works fine so far but they put a tracking pixel in the emails in order to provide statistics. Some email clients (like Thunderbird) shows a warning message for a remote content in the email.
I want to provide safe to the maximum service for my users and want to remove this tracking pixel from the email. However I cannot find such an option in the settings.
I don't want third party content in my emails. Do you know how to remove it?
(I'm using free SendGrid plan)
Alternatively, does Azure have own SMTP service?
As per https://sendgrid.com/docs/Apps/open_tracking.html
Settings may be changed through:
SMTP API (on a per message basis)
Web API (on an account wide basis)
Web Interface (on an account wide basis) // have to log into account
You didn't say exactly how you we're implementing it, so it has links to a few different ways. Sounds like it would be easier to log into your account and disable it there.
EDIT:
updated answer from comments
go to sendgrid.com/app and its one of the three options there. with a big red disable button on it when you hover over it.
Related
Hi everyone I have been trying to know how to force gmail to add events to a calendar similar to how airbnb and airline tickets or even eventbrite does it, is there a standard email one can send or is it based on domain reputation to make it happen.
If we are talking about creating events in Google Calendar based on the content of an email (either inbound or outbound email) then Google already has these features called Smart features & controls. For trip information, you would need to set up your Google Account for Google Travel.
Just take note how Google indexes these search terms or metadata only includes the first 1MB of a content on an email to identify if the smart features will automatically detect and suggest a creation of event based on the content of an email. See info here
" is there a standard email one can send or is it based on domain
reputation to make it happen. "
Based on the question above, the domain reputation will only be relevant if you have integrated a third-party mail service within your Google Account, assuming you have Google Workspace, you can check this link for SMTP relay setup.
Other than that, using Google Calendar API only limits you based on your Quota Limits for Google Services.
See also:
Avoid Calendar use limits - Google Workspace Admin Help
Proper accounting with service accounts | Calendar API | Google Developers
Limiting Requests Per User | Capping API usage | Cloud APIs | Google Cloud
Testing out the platform I was running on both a developer account and a Trial Business Pro account until I purchased a standard plan.
Up until I purchased the standard plan, envelope statuses would update by the second and the functionality built with the Apex Toolkit was working well.
Once changing to the standard paid plan, envelopes statuses take 10-15 minutes to update and some functionality is not working.
My question is:
Do the different plans have different status updating times in Salesforce?
Is functionality of the Apex Toolkit limited between the different plans?
Does the Connect option (which is missing now) have anything to do with the above?
Thanks!
They do not. Writeback to Salesforce takes place via DocuSign Connect. Some plans don't support Connect out of the box but the actual writeback times / delays do not differ between account plan types.
Indirectly, the only way that a plan type can interfere with an API call that worked on another plan type is if it had entitlement to a feature that your new plan does not, IE: The ability to allow Comments, to set recipient signing language, to set envelopeID Stamp Control, etc...
I would highly suspect that it does -- in fact I'm a little surprised that your writebacks are happening at all if you don't have Connect enabled. Salesforce adds an object reference IE: Opportunity / AccountIds to the envelope's custom fields on send. When Connect sees these fields, it knows to write back to that specific object. Without Connect enabled and configured it shouldn't be able to process these writebacks at all.
I think you should have a conversation with your Account Rep first regarding Connect entitlement, then you can reconnect your Salesforce instances to the updated DocuSign account which is something that we can help you with.
Regards,
Matt
What is the correct way to setup mail notifications from your web app in the cloud era? Previously I always had some SMTP server, which I could use for that purpose, but this time my company mail is hosted and there is a limit of 500 mails per day sent from certain address in this system, so with rather high chances I can hit that limit. My first thought was to use services like sendpulse or mailchimp, but it seems that all these services are built having mass marketing campaigns in mind and I'm concerned about security in case of sensitive emails, like password restore or details about orders. I spent several hours searching for solution in the web, but did not find anything reasonable.
Ideally the service I'm looking for would guarantee, that content of my messages would never be stored or shown to anyone, besides email this service might also be able to send SMS (for password restore case) and have integration with messengers.
We are using the EnvelopeView: CreateSender endpoint on the server side and are authenticated under a service account we have dedicated for this process. Ultimately, we send a URL such as https://demo.docusign.net/Member/StartInSession.aspx?StartConsole=1&t=<GUID>&DocuEnvelope=<ENVELOPEID>&send=1 back to the end user to pick the signers, and populate tags.
All works fantastically, however, we were hoping to make it so the user can only see and populate the information for this single document. Currently, once the user clicks the link they are essentially authenticated as our backend service account and if they open another tab in their browser and go to (https://demo.docusign.net) they can see all documents and even change the password of the account if they wanted.
Is there a way to restrict this in any way? Would the experience be different if purchased an “API” account not tried to use an actual user account on the backend? Yes, we know about OAuth, but we don’t really want to impersonate the sender and prefer to keep a dedicated service account.
An "API" account would give you the same issues as dedicating one of your current users as a "Services Account," so I don't think that's a solution.
Instead, I suggest that you move all of the functionality that's needed upstream into your app. That way you will not need to present the Sender view to your users.
Your app can enable your users to:
choose who the envelope will be sent to
choose/edit the email messages, etc
choose the documents that will be sent
etc
If you have preset templates that include the document tabs/fields for the signers then there is no reason for the sender to deal with the sending screen for picking the tab/field locations on the documents.
This type of app will also give a smoother user experience to your users since they'll stay in your app rather than bouncing over to DocuSign for part of the task.
Is there a way to obtain GSuite Email Logs for a domain generally? I see that there is an Enterprise feature that allows for the export of email logs to Big Query. Is it possible to obtain the logs (doesn't need to be big query) for non Enterprise accounts? Or, if not the logs, then essentially the same metadata via an API?
According to About Email Log Search:
This feature is only available with the G Suite Enterprise or Business or Basic edition.
You can sift through the delivery logs for your domains and evaluate
message delivery using Email Log Search in the Google Admin console.
The reports help you track down missing messages, such as those
quarantined as spam or otherwise routed incorrectly. You can also use
the tool to determine message IP addresses and troubleshoot how
policies affect mail flow.
The Email Log Search tool isn't available to resellers when accessing
a resold domain Admin console using the reseller console.