Thanks for reaching out here!! Is there a reason you chose to use EmailProvider = sendmail? Normally, customers will set up EmailProvider = SMTP along with the SMTP-related configuration that points at their internal SMTP server.
In any case, this is definitely a supported component of the product, so you are welcome to submit a professional support request at support@rstudio.com , and we can help you through the process a bit more formally!
I'm using the free 45 days trial to familiarize myself with the platform, but I leave a lot to be desired in the IT part (I'm a statistician).
We have a Linux machine running on Digital Ocean (i created one droplet just for Rstudio Connect) and now i need to evaluate the platform to publish our apps.
Returning to the initial question, there is no special reason for choosing "sendmail" as a parameter for the "EmailProvider" argument in the Connect Server configuration file, simply because I thought this would be the easiest to configure.
Now, after your answer, I tried to use SMTP in the configuration, but I have a new error:
"Error: Cannot connect to SMTP host http: //---.---.---.---: 25: dial tcp: address http: //---.---.---. ---: 25: too many colons in addres "
I also tried the port 80, without success.
There is something i need to do in the linux machine/server before i configure the RStudio Connect Server?
Apologies for the delayed response here! I didn't get notification of your response for some reason!
Glad to hear you have something (almost) working! So typically sending emails relies on an external entity that relays emails. For instance, inside of a data-center, a company would have their own SMTP server that relays all emails (i.e. smtp.mycompany.com). The idea here is that you would point Connect at that SMTP server with the appropriate credentials so that it can then be used to relay emails from Connect to your inbox.
Some cloud providers have such SMTP services, and there are a handful of external entities out there (mailchimp, etc.). On AWS, I am familiar with "SES" (Simple Email Service), which can be used for relaying emails over SMTP. I'm not sure if/what DigitalOcean offers in that realm.
What is the scope of your proof of concept? Does your organization have an SMTP server? If you're expecting this thing to live for a while, you could either look into whether Digital Ocean offers any such service or if a third party provider makes sense. The other thing you could do is look into relaying emails on behalf of a user in a more standard mail setup like Gmail (although that comes with caveats). This article seems to do a decent job of exploring the tradeoffs, and I have no idea what biases they may have
Your best bet is probably to find out what standards your organization has for sending programmatic email and then see if there is a nice way to piggy back off of that
If you're cloud-agnostic and AWS is an option, we do have a cloudformtion template that can get you the whole of RStudio Team setup in a pretty basic setup with just a handful of clicks:
You would still be required to setup SES yourself to relay emails, but I know that is an avenue for cloud email delivery with a cloud provider, and there are lots of tutorials out there on the topic (which is how I learned)
That makes sense!! If you don't have an SMTP server and you're a small company, using a single user's SMTP creds for whatever your email service is may be do-able. Alternatively, many of the mail services have pretty cheap entrypoints. It looks like on mailgun your usage would probably be free (first 5k emails) to just route emails through there:
There are lots of such SMTP / email providers that could probably get you set up pretty quickly! Just FWIW I know nothing about mailgun and have never used their service - their name is just one that sticks out in my memory There may totally be better / cheaper / more reputable providers of such services.
Also, no worries at all asking basic questions!! That's exactly what the community is for! We're here to help each other out! Definitely let us know if you have any follow-up questions on this! We'd love for you to be successful here!
Also, keep our professional support team in mind. Although we do not have the resources to support the configuration of external SMTP servers themselves, we are definitely happy to help diagnose and troubleshoot any issues you are having in our products (even during a free trial)!
EDIT: I only skimmed it, but this article looks like a pretty good overview of some well-known names:
There may totally be better / cheaper / more reputable providers of such services.