What precautions should I take before letting users send email through my app?

Question

I'm working on a contact management/lightweight CRM app, and I'd like to be able to allow my users to send email to their contacts through my application. Obviously this opens up a huge can of worms in terms of security, so I'd like to know what can be done to mitigate or minimise the risk to both my organisation and genuine (non-spamming) users, as well as keeping my app reputable.

The application itself will make API requests to a third-party mass SMTP provider and let them do the actual sending, rather than send it directly from our server(s).

These are some current precautions I am taking:

• Users will only be allowed to send email to their contacts or accounts already on the system, no mass emailing lists of addresses only.
• Emails are rate limited, each user will only be able to send n emails in a 24 hour period where n is based on their subscription plan.
• Using the "on behalf of" feature for the sender address.

What I would specifically like to know is:

• Some users may want to send from a no-reply or other corporate address, different from the email they use to log in. How should I best verify users own or have access to the address? I can't always use verification emails because if they want to send from an unmonitored address they obviously won't be able to check for said verification email.
• Is anyone able to explain how I should make use of SPF records (or get my users to make use of them) in this instance? I have read about them but my knowledge is still shaky in this area.
• Will there be any special precautions to take if we scale the app over multiple servers?

As an additional note, like the market leader Salesforce, I intend to allow my users to send an unlimited number of single (non-bulk) emails to other users, but above I am talking specifically about emails sent to non-users.

Answer 1

Emails are rate limited, each user will only be able to send n emails in a 24 hour period where n is based on their subscription plan.

• Obvious first step, rate-limit emails per user.

• Rate-limit new signups. In your case it looks like users have to pay for access, so that is an effective rate-limit. This is important if you rate-limit emails per-user. You obviously don't want a single person bypassing this by easily creating a large pool of users.

The application itself will make API requests to a third-party mass SMTP provider and let them do the actual sending, rather than send it directly from our server(s).

• Mail receivers often track sender reputation per IP address. Since you are using a third-party provider to send the emails, then it is their IP which will take the reputation hit not yours. This is important, as you don't want your all-important company Email Server to be on the same IP that sends less-vetted emails.

• It may be best to throttle emails sent so you are not recognized as a DoS attacker by various mail receivers, but your provider may do this for you automatically.

Some users may want to send from a no-reply or other corporate address, different from the email they use to log in. How should I best verify users own or have access to the address? I can't always use verification emails because if they want to send from an unmonitored address they obviously won't be able to check for said verification email.

• If you cannot verify they own the email address, you must instead verify they own the domain. This is a good subject for a separate question, but in short, I would suggest you look at how SSL Certificate providers verify ownership.

  • Email verify to limited set of known admin account usernames. ([email protected], etc)

    Alternatively, check the WHOIS and send your email verification to the Admin contact there.

  • DNS verify by requiring them to add a specific random TXT rule.

  • You could use HTML web page verify but that could potentially be disconnected from what really needs to be verified.

Is anyone able to explain how I should make use of SPF records (or get my users to make use of them) in this instance? I have read about them but my knowledge is still shaky in this area.

• SPF records are managed by the From domain holder.

  • If you are sending From your domain, with a Reply-To of the customer's domain, then SPF is simple to configure, but should be a separate question.

  • If you are sending From the customer's domain, then it is your customer's responsibility to list your sending server IPs, so that they are not accidentally adding spam points to those emails.

    • For customer convenience, you should probably publish an SPF rule, so that your customer can include it. This way if you make any changes, such as switching SMTP providers, then your customers will not have to update their SPF ruleset.

      • The SPF rule you publish can be a simple include of whatever your SMTP provider has published on their end.

Will there be any special precautions to take if we scale the app over multiple servers?

As I said above, receivers track reputation per IP. (in your case, the SMTP provider) I would point out that your servers should be synchronized so that rate-limiting is enforced. You don't want the user connecting to a different server to be able to bypass a rate-limit error.

As an additional note, like the market leader Salesforce, I intend to allow my users to send an unlimited number of single (non-bulk) emails to other users, but above I am talking specifically about emails sent to non-users.

• You may consider sending these from yet another IP (if your SMTP provider assigns IPs to you) so they get a separated mail reputation from the bulk emails.

• You should always have some rate-limit, even if it is not advertised, to prevent robotic or user-script submission.

Users will only be allowed to send email to their contacts or accounts already on the system, no mass emailing lists of addresses only.

This is helpful from a user perspective, but I assume that technically they can add contacts to their system using a user-script, so this probably is not relevant to the determined spammer?

Using the "on behalf of" feature for the sender address.

I'm not 100% sure how your are doing this, but it does sound like a reasonable thing to do.

Answer 2

What has been said in this answer, plus input validation and SANITIZATION

Please make sure all special characters and bytes, especially ; : ' " \ % <> and 0x00 Are represented by some codified form of the original before they are stored and transferred. Then translate them back when showing the message.