Aggiunta del certificato TLS insieme alla configurazione SMTP

Supporto Installazione
1

Sto cercando di utilizzare il mio server in sola trasmissione per inviare email. Sto eseguendo questo gateway SMTP per utilizzare TLS, motivo per cui il client che uso per inviare email richiede un certificato. Sto utilizzando un certificato autofirmato, che è molto semplice da configurare se uso postfix/ssmtp per l’invio di email, ma non sono sicuro di come possa utilizzare un certificato personalizzato nel client di posta di Discourse.

Per avere una breve panoramica:

Scenario semplice:
Discourse —invia-email—> mailgun —invia-email—> utente

Il mio scenario:
Discourse —invia-email—> il mio server in esecuzione con gateway SMTP —inoltra-email-utilizzando-API-AWS-SES—> utente

Grazie.

2

I would like to correct my question. So I really don’t need to add any certs for this to work but still its failing to communicate on TLS. If I am testing it with swaks its working fine. Example command:

swaks --to user@example.com --from me@example.com --auth PLAIN --auth-user myusername -tls -s smtp.somehost.com:2525
3

You can directly use the AWS SES SMTP to achieve this why do you want to have a local relay?

4

@itsbhanusharma AWS ses provides 60k emails per month free and as far as I know these email calls should be requested from ec2 instance to work otherwise they are charged as normal. My discourse instance is hosted on a digital ocean droplet. I could be wrong but this is my understanding and the reasoning behind it.

5

So even if Your SES API is receiving emails from a DigitalOcean IP, it would make it chargeable, You may decide to use another service or spin up exim on an ec2 instance to be a bridge between your DO droplet and AWS SES. I don’t think it’ll work but You can try.

It should (in theory anyway) be like:

  1. Discourse (on DO) sends emails to exim IP in EC2
  2. EC2 relays emails received from DO to SES
  3. SES delivers emails to the end user.
1 Mi Piace
6

I have already solved the relaying problem by running a local smtp server in ec2 which eventually forwards the smtp request to ses. The problem is discourse is failing on TLS handshake with this smtp server where as postfix/swaks and similar applications are working just fine.

7

Solving that should be as simple as using port 25 (without encryption)

8

Is there a way I can see where this SMTP handshake is handled? Like any library discourse is using in ruby behind the scenes? I don’t want to disable TLS here.

9

Then use a Valid SSL certificate (even letsencrypt should work fine)

2 Mi Piace
10

Using valid cert from letsencrypt didn’t help for some reason. Don’t know why.
But after setting this in app.yaml, emails are working now.

DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none

Someone with more knowledge about SMTP might provide why this is working but I am good for now I guess.

1 Mi Piace
11

Does this end up being cheaper than simply moving the discourse instance into S3?

1 Mi Piace
12

I have a $ 5 ec2 instance running on aws which I am using for relaying multiple domains. Moving discourse to ec2 would be a little costly from digital ocean, not much to be honest(few dollars over all).

But the point is even if I move discourse to ec2, I would still need that relay service to support rest of the droplets that I have on DO for other domains that I own. So why not just fix discourse :slight_smile:

13

Well, by your own admission Discourse isn’t broken, it interfaces with SES perfectly fine.

You’re doing this to circumvent an SES restriction to relay emails for free.

3 Mi Piace
14

That is true, but discourse has nothing to do with SES here. Discourse is communicating with a SMTP server, which could be anything(right now its a relay service). I was wondering how does postfix/swaks and all are working just fine with this SMTP server(from same DO vpc) and not discourse. After setting that var, it is working though. Still I would like to know what library we are using in discourse for SMTP handshake so that I can personally verify if there is anything we can do to improve in discourse.