Sending Email
Last updated
Last updated
Your ExaVault appliance generates a variety of emails, such as notifications of new user accounts, password reset links, invitations to download or upload shared files, and notifications of file and user activity.
ExaVault does not include its own email sending service, so you must provide your own SMTP service's information in your appliance manager configuration. Your mail provider will give you the information needed for sending mails via SMTP.
The appliance manager is located at the address for your appliance on port 9002. If your domain is files.example.com, the appliance manager is reachable at https://files.example.com:9002/
Within the appliance manager, you must provide the following information on the Configuration page in order to send email:
Email Host: The address of the server that will deliver email messages generated by your ExaVault appliance.
Email Port: The port used for connecting to your mail service for sending.
Email SSL: If your mail sender requires the use of SSL, check this box. Typically, this will be the case when using port 465 for your email port.
Email Username & Email Password: The credentials used to authenticate with your mail service for sending.
Email From: The from email address that will be used for emails generated by the ExaVault appliance.
Whenever you make a change to these configuration settings, you must save the changes and services.
Emails are generated by the ExaVault services within your appliance and then sent via your mail provider's SMTP service. Mails are delivered to your recipient's mail server, where they may be filtered, rejected or suppressed at the server level or the individual mailbox level. Troubleshooting what happened when an email is not delivered is often a case of checking each step in the chain.
The ExaVault appliance is made up of a number of services running in docker containers. The log files for all of these services are in the /data/exavault/logs directory on your server. Outbound emails generated by your appliance are sent asynchronously using the Celery service, which creates log files with names that begin with celery.
If the Celery logs only show that emails were sent and do not show any error messages, you have determined that the email was successfully created and was sent to your mail provider. Your next step is to check your mail provider's logs for the message delivery status.
Search the Celery log file in your log directory for email sending attempts; searching for "send_email" will help you find relevant lines.
After you've determined that the ExaVault appliance was able to send an email using your mail provider's SMTP, you can check with your provider for any logs made available. The information available will vary, depending upon your provider.
You can usually determine whether the message that was sent using your mail provider was accepted by the recipient's mail server. If the recipient's mail server does not accept the email, this is known as a bounce, which can be a hard bounce or a soft bounce.
Soft bounces indicate temporary problems, such as the recipient's mailbox being full. A hard bounce happens when an email can't be delivered and never will be. A hard bounce usually means the email address doesn’t exist, the domain name is incorrect, or the recipient’s email server is blocking the message.
When you've determined that the recipient's mail server accepted your email and did not produce a bounce, the next logical place to check is the recipient's email filters. Emails from ExaVault may be wrongly identified as spam, particularly notifications of file activity, which often have repetitive subjects.
Search the Celery log file in your log directory for email sending attempts; searching for "send_email" will help you find relevant lines. If there's an error contacting your mail service provider, such as if your credentials are incorrect, you'll see a corresponding message in the logs about the failure. If you update your SMTP Configuration to fix this type of failure, you'll must after saving your configuration changes.
If no messages are added to the Celery log file when you try to generate an email, then the asynchronous workers are not processing jobs. This may mean that the queue service (RabbitMQ) or the worker service (Celery) have stopped responding. can resolve this problem.