1

Assuming I am creating an online service that allows my clients to send email (using their SMTP credentials), what risks should I consider and how to prevent them?

The sender of the emails will always be the username of the SMTP credentials.

My biggest concern is the possibility of my servers being blacklisted if my clients send spam. Can this happen even if the SMTP server is not mine but my servers act as a simple "email client" and if yes, how can I avoid it?

Improve this question
8
  • I'm sorry, but what is your primary concern here? There appear to be multiple problems.
    – schroeder ♦
    Commented Oct 23, 2022 at 12:47
  • Hoarding access credentials isn't a good idea, generally. You should check out Sender Rewriting Scheme where there's no need to use your clients' credentials.
    – Zac67
    Commented Oct 23, 2022 at 12:48
  • You are also missing some crucial details. Like, are you running the email server, or are you just an intermediary? Who is providing the email service?
    – schroeder ♦
    Commented Oct 23, 2022 at 12:49
  • Emails block lists are not populated by the account but by the server. Please review how email block lists work. I think that answers most of your question.
    – schroeder ♦
    Commented Oct 23, 2022 at 12:50
  • @schroeder I'm just an intermediary, I would not run the email server. Imagine an email client like Mozilla Thunderbird but as an online service, that is what I am doing. I read about email block lists but couldn't figure out if there are risks for me.
    – Bob
    Commented Oct 23, 2022 at 15:48

2 Answers 2

Reset to default
0

If you send mail using client credentials, you will certainly use the SMTP protocol with authentication, to send the mail to the client mail host. In one of your clients sends too much spam and triggers a spam detection filter on their host, your server will be blacklisted on that host. That means that all of your clients that would use the same host will have their (legitimate) mails rejected. Your server will functionally be a mail relay, so you are supposed to implement spam detection on it if you do not want it to be blacklisted.

That being said, your server will have to know the client mail passwords to be able to send mail. That means that you will be responsable for the security of personal and secret data. If one of your clients find their mail account compromissed, you could have to prove that the credentials cannot have been leaked from your system. Said differently, my opinion is that the possible legal outcomes should be considered...

Improve this answer
2
  • Theoretically, you could implement the SMTP authentication as a pass-through so it's never stored on your own servers, just something your customers pass through your API (this does not alleviate your reputation risk; search for email deliverability). Make sure you're not logging so verbosely that you capture the passwords!
    – Adam Katz
    Commented Oct 24, 2022 at 15:22
  • 1
    @AdamKatz: You are right. You still have to prove that you never stored it on purpose or in any log, and that your server were not compromissed to allow an attacker to peep at the password from the application itself. As far as I am concerned, I prefere for the systems I am in charge to never know client data not related to what I directly provide...
    – Serge Ballesta
    Commented Oct 24, 2022 at 15:27
2

Assuming I am creating an online service that allows my clients to send email (using their SMTP credentials), what risks should I consider and how to prevent them?

I'm going to infer that the question is, "What risks exist in creating a web application that utilizes a third-party SMTP service?"

You mention already that you're not using your own SMTP service, so you have a layer of concern to worry about prior to the possible IP Block listing. Will you be allowing your users to specify their own SMTP service provider? Or will you be using a dedicated third-party provider?

Risks

  • SMTP provider may have e-mail throttling in place (i.e. 1000 e-mail sent per 1 day)
  • SMTP provider may block SMTP requests coming from your web application
  • The IP Address of your web application is block listed, which can indeed still happen even if the SMTP servers that you are using are not yours. Typically, e-mail headers will contain details of the origin of the e-mail in the X-Originating-IP e-mail header.
  • Stolen credentials can be used to send spam, or malicious e-mail.
  • User credentials may be at risk of theft if logged or stored in an insecure manner.
  • Poorly configured headers. You'll need to put the e-mail together programmatically before sending to the SMTP server. Poorly configured email headers can lead to rejected e-mail.

Recommendations

  • Use Multi-factor authentication, or an additional authentication mechanism, along with SMTP authentication.
  • Use a dedicated, third-party SMTP provider and ensure you understand what they do and do not allow. Verify if they throttle e-mail, and what that throttling is.
  • Throttle the ability to send e-mail by your users (i.e. 1000 e-mail sent per 1 day), within your third-party provider limits.
  • Don't store your users credentials.
  • SPF, DKIM, and DMARC are DNS frameworks that provide additional security and reporting capabilities related to e-mail; I would highly recommend you understand how your SMTP provider has these configured.

Recommended Reading SIMPLE MAIL TRANSFER PROTOCOL - https://www.rfc-editor.org/rfc/rfc821.html

Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 - https://www.rfc-editor.org/rfc/rfc4408.html

DomainKeys Identified Mail (DKIM) Signatures - https://www.rfc-editor.org/rfc/rfc7489.html

Domain-based Message Authentication, Reporting, and Conformance (DMARC) - https://www.rfc-editor.org/rfc/rfc7489.html

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .