Issue:
I have a working production process for initiating remote signing via the DocuSign REST API. For the most part, it works great. However, for the initial 20 contracts we've sent out, a few clients have not received their emails from DocuSign requesting their signature. I can confirm that DocuSign reports that they successfully SENT them to the signers even though clients have reported never receiving them (despite looking through spam/junk/deleted). In these few circumstances we're stuck at a dead-end because if they don't receive that email for whatever reason, we have to revert back to manual contracts.
Having read through the following article:
https://support.docusign.com/en/articles/Why-aren-t-my-signers-receiving-DocuSign-Notification-emails
It's clear that this is a common issue and the only options we have is to either send it to another email address, have the client reach out to their ISP and figure out why it might be rejected (This is not a good / professional option), or resort to a manual contract.
One thought I had...
was to use the API to obtain the link for the current signer that DocuSign provides in the emails they send and give my app's users an alternative option to send our branded email containing this link to the remote signing page from our email service since we have zero reputation issues.
Edit based on Inbar's reply
After reading through Larry's Blog as provided by Inbar in the comments below, my idea above would need to have my app send an email to the signer with a unique URL back to my App (so that this URL is Long-Lived / limited only based on business rules) which, when clicked, would make a request to EnvelopeViews:createRecipient (time-limited / must be used in 5 mins) to retrieve a url and redirect the user to the Remote Signing page which is governed by DocuSign's session policy.Should my client need to go away and click the link in their email again, the Long Lived ==> Time Limited & redirect would repeat starting a new session.
Support seems to be better here on SO than via ticketing, so I'm hoping a DocuSign rep/guru has some ideas on what I can do to handle these scenarios.
First off, yes there are cases where emails from DocuSign are rejected as SPAM by the ISP or by the email provider. These will not even show in the spam folder because they reject them before they send them to the end-user and we do need to work with these to fix the issue. Especially if these users will be receiving more than one contract etc. For that - you will need to contact support since we need to know the email address etc.
Your idea is possible, but you'll have to read Larry's blog here. This is because the URLs are typically very short lived and expire in 5 min so sending the regular URLs over email will not work very well.
Related
We're using the Docusign API to set the return url so that the user returns to our application after signing the envelope, but we want more control over when that redirect actually happens. Is delaying the redirect possible? Not seeing that option in the docs so was wondering if I missed something. Thanks in advance.
There's no such option but you can easily do that on your application side. You can put a server side delay before you show the page to the user so that the browser would still show the previous page until the server gets back with a response from your page.
(not seeing why you would like to delay, most people like things to be fast, but if you wish - you can certainly do that on your page).
It is not a good idea to use webhooks (Connect) to confirm that someone has signed the document via the signing ceremony. As you've discovered, it takes too long for the notification to be sent by DocuSign.
Instead, I suggest either of the following:
After the embedded signing ceremony has redirected back to your application, you put up a "busy wait" page while your app makes an API call to DocuSign to check that the document was, in fact, signed. In other words, do not wait for the notification message--doing so provides a poor user experience.
Assume that the signer did sign, proceed with your interaction with the signer. In the background, if you don't receive the notification about the signature, deal with that issue at that time. Eg, don't make any final commitments to the signer until you've received the notification but don't block the UX waiting for it. Remember that 99% of the time, the signer did sign.
I am building an application in NodeJS + Express where teams can share information with one and other and chat (kind of like an internal messaging forum).
Sometimes there is a need for the team's clients to view and edit some of this stored information on a case by case basis (e.g. a client asks a question and wants to message back and forth with the team, using my app). I don't want the client to have to sign up for an account in this case.
I am thus wondering what is the most secure strategy for generating a URL where anyone with the URL can view and edit a document/POST data to my app within the confines of a single document, without signing in?
(I've seen a couple of posts on this topic but they're quite old and don't focus on this specific case.)
First of all, I can absolutely understand the benefits, but still it is not an optimal idea. However, I would like to summarize some thoughts and recommendations that will help you with the development:
A link like this should not be able to perform critical actions or read highly sensitive data.
Access should be unique and short-lived. For example, the customer could enter his e-mail address or mobile phone number and receive an access code.
If you generate random URLs, they should be generated in a secure random manner (e.g. uuid provides a way to create cryptographically-strong random values).
If I had to design this I would provide as little functionality as possible. Also, the administrator would have to enter a trusted email address and/or mobile phone number when releasing the document. The URL with a UUIDv4 is then sent to this channel and when the customer clicks on the link, he gets a short-lived access code on a separate channel if possible (on the same channel if only one was configured). This way you prevent the danger of an unauthorized person accessing the document in case a customer forwards the original URL out of stupidity.
I'm creating a WebApi project that aims to handle payments in my project.
Actually, my approach is like:
CreatePaymentMethod(creates the payment, contact paypal and redirect the user to the payment page. If payment is done, redirect to PaymentApprovalMethod)
PaymentApprovalMethod (confirm the payment on my system, allowing the user to access the content)
What I'm wondering is... What if an users directly creates a message to invoke the PaymentApprovalMethod?
Suppose:
- CreatePaymentMethod is called, user sniffs with Fiddler the Transaction ID of the redirect
- Creates and adhoc call of the PaymentApprovalMethod like.
I see two possibles scenario to handle this situation:
Restrict (I don't know how) the calling of PaymentApprovalMethod to the messages from Paypal only
Cross Check the payment inside the PaymentApprovaMethod (ok, user, you said the transaction ID 123 is done, I'll contact paypal to verify this before trust this call)
The second one seems more safe but also more "time / resource" problematic..
Do I'm missing something? Is there something else I can do to avoid this problem?
Take a look at Instant Payment Notification (IPN). PayPal's system will POST transaction data to a listener script that you setup for all transactions on your account, be it a payment, refund, dispute, cleared payment (from pending), etc. You can use this to completely automate many post-payment procedures.
Part of your IPN listener will include a call back to PayPal's server to verify that the data actually came from them. You can then log IPN's separately, and only process verified IPN's, which means you know somebody didn't just POST directly to it on their own.
Some people do go a step further and only accept traffic to that script from PayPal's IP addresses, however, they do change their addresses quite a bit and I think that just becomes a hassle. The verification has always been enough for me.
IPN is definitely what I would recommend for you.
I have 2 Windows 2008 R2 boxes running in Microsoft Azure. My ASP.NET 4.0 site (let's imagine it's running at "example.com") has a standard Contact Us form.
When a user sends a Contact Us message, I use System.Net.Mail and SmtpDeliveryMethod.Network to deliver mail to an IIS6 SMTP server running on each box, which sends the mail to a Google Apps "enquiries#example.com" account, using the email address the user entered into the Contact Us form as the "From" address.
This was working beautifully for a year until I checked it today, and found this error in a .BDP file in the \Badmail folder:
550-5.7.1 Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been blocked. Please visit http://www.google.com/mail/help/bulk_mail.html to review our Bulk Email Senders Guidelines.
Obviously Google upped their anti-spam strategies in the last 6 months - last time it worked was Feb 2013 (yeah, we don't get much mail luckily... yet).
I've read the Bulk Senders Guidelines linked above, but they're not really suited to my use case. My case is not sending emails from our server to users of our site (I simply use the Gmail API and send from our enquiries#example.com for that), but rather to collect users' enquiries so that we can easily respond by clicking Reply in that inbox.
I am looking for the easiest solution here. In response to the ones in Google's Bulk Senders Guidelines:
Use a consistent IP address to send bulk mail: I already do, doesn't seem to help
Reverse DNS: Godaddy, my domain and DNS provider doesn't seem to support them: http://support.godaddy.com/groups/domains-management-and-services/forum/topic/how-do-i-setup-reverse-dns/ Anyone know if there's a way?
Use the same address in the 'From:' header on every bulk mail you send: This is totally not my use case. I'll have different From headers in every email
SPF record: I think this only works if I am sending From ...#example.com every time. Is that right? My feeling is SPF doesn't help me here. Would love someone to enlighten me.
DKIM: This looks hellishly complicated, but I'll pursue it if someone thinks it can work in this case. Specifically is it OK that the From address doesn't match the "signing domain"? Anyone got any good "how to" links? And will this be sufficient for Google to un-blacklist me?
Sendgrid: Azure's preferred mail sending app. This means signing up, code changes, testing, and unknowns like "does Sendgrid allow any From address? It's non-trivial, and I'd like to avoid this, but again, will go there if it's what people think is the sanest option.
As a general answer to your questions, sending email on behalf of many different domains from one IP (e.g. example.net, example.org, and ex.co from 10.0.0.1) is generally seen as spammy behavior (and therefor not recommended).
Your points 1-5 only apply if you're sending from one domain. rDNS, SPF, and DKIM only improve delivery for one IP to one domain (in a generally 1:1) relationship.
Generally, the best way to avoid getting marked as spam in a situation like this is to set the From email as a consistent one that you actually control (e.g. enquery-sender#example.com), and then setting the Reply-To as the entered address (e.g. enquirer#someprovider.com). This way you consistently send from one domain, while still getting the benefit of replies going to the message originator (for example LinkedIn does it this way). Doing this will allow you to setup rDNS, SPF, and DKIM with benefit.
That said, if you decide that you don't want to use the recommended Reply-To method, you can use SendGrid to send from any arbitrary domain. It should not require any significant code change (just switching your current SMTP credentials to SendGrid's).
Disclaimer: I am a SendGrid employee.
We have a password reset web application. The application sends out an confirmation code to an alternative e-mail. My manager believes it is not a good idea to include a link to the page were you have to enter the code.
I see his argument. However, the helpdesk has been overwhelmed with users who are confused about the process. I'm assuming this is because many our users browse using only one tab/window and navigate out of our web application to check their e-mail for the confirmation code.
My question: How should we approach this issue? I would like to alleviate helpdesk and, in turn, make the process pain free for our users. Any suggestions?
Clarification
He believes that we are doing the user a disservice by training them to click links from a sender that cannot be verified (in this case, it's an automatic message with a "no-reply" address). This, would in turn, make users more susceptible to phishing attempts which we've had a lot of issues with in our organization.
I think sending links is the standard way of doing it. If a customer is really worried about the integrity of this email account, he better gets that sorted out first.
Essentially you don't gain extra security by not sending the link, but you gain a lot of comfort. Just do it like everyone else - put it in there (time limited).
The only thing on the top of mind would be the option to have a unique identifier in the e-mail's subject an have the customers reply to that mail.
Then an automated script checks 'password-forgotten#mycompany.de' for emails with the subject 'Re: Forgot your password? [UNIQUEID]'. The script would then mail them their new password.
Since most users won't modify the subject when hitting "Reply To" and won't do a "Compose new mail" and enter the recipient address manually, chances are big, incoming mails to "password-forgotten" will have that UNIQUEID in the subject.
Plus helpdesk would only have help those that actually modify the email's "Subject". ;-)
There are security considerations, though. Maybe your manager might argue, that anyone might send a forged "Forgor your password" mail and set the "Reply-To" header to the attacker's address. The processing script has to intercept these attempts of forgery...
I see no reason why the link shouldn't be included, especially if the code is something like a hash because the chances of somebody cracking that are slim to none.
You could however, add an extra protection to the page where the code is being inserted and limit the number of tries to something like 3. For even more protection, send the email address to that page as well, and allow 3 tries per email address instead of 3 tries / IP, which can be easily bypassed.