#71 Email confirmation not sent after sending a Fedora Happiness Packet
Closed: complete 5 years ago by jflory7. Opened 5 years ago by tushar100.


Metadata Update from @tushar100:
- Issue private status set to: True

5 years ago

thanks for the report @tushar100 - we are aware of this problem and we will fix it.

Metadata Update from @jonatoni:
- Issue assigned to jonatoni

5 years ago

@jonatoni I would like to solve the issue.If you allow

sure :) I will assign it to you

Metadata Update from @jonatoni:
- Issue assigned to tushar100 (was: jonatoni)

5 years ago

Thanks.Will solve this issue for sure.Will contact you if i need help

Metadata Update from @jflory7:
- Issue private status set to: False (was: True)

5 years ago

Metadata Update from @jflory7:
- Issue priority set to: waiting on assignee (was: awaiting triage)
- Issue tagged with: PASSED, difficulty - medium, help wanted, improvement, type - backend, type - summer coding

5 years ago

I was able to reproduce this on the production site. I sent a Happiness Packet to an alternate email and I never received either my confirmation email or my Happiness Packet. A good next step here is to reproduce this issue locally. I'm not sure if it's a bug or a misconfiguration in the production environment.

@tushar100 Are you still working on this? If not, I would like to take over.

Metadata Update from @jflory7:
- Issue untagged with: help wanted, improvement
- Issue tagged with: bug

5 years ago

I was able to reproduce this on the production site. I sent a Happiness Packet to an alternate email and I never received either my confirmation email or my Happiness Packet. A good next step here is to reproduce this issue locally. I'm not sure if it's a bug or a misconfiguration in the production environment.

In the local development environment, the emails are send in the console, justified by CELERY_EMAIL_BACKEND = "django.core.mail.backends.console.EmailBackend" setting in dev.py. I have been successfully able to send and receive happinesspackets through the console.

Hi @tushar100, we haven't heard any updates back from you yet. Are you still interested in working on this? Please let us know by the end of today if you are. I'd like to discuss how to fix this bug.

I have been successfully able to send and receive happinesspackets through the console.

This is how I have been managing email in my local development environment too.

I think this is a high priority bug fix. Before we roll out a new update to the production environment, I think this ticket should be solved first before we try pushing an update.

I'm opening this ticket up for someone else to work on. This is a high-priority bug and it would be helpful to figure this one out before we push an update to the staging site.

Metadata Update from @jflory7:
- Assignee reset
- Issue tagged with: good first issue, help wanted

5 years ago

@jflory7 I'd like to work on this :)

@shraddhaag Sure! Do you have any thoughts on what is happening here?

I think it's best to focus on reproducing this locally first. I'm not sure how the production environment is set up today as it relates to this bug. I haven't had a chance to debug this locally.

If you are on a Linux system, I think you can use a local mailbox on your machine to test email functionality (i.e. not sending test emails out on the public Internet from your laptop). You can send email to your system username on localhost. For me, this would be jflory@localhost for the email address. If I remember right, the email content should be found at /var/spool/mail/$USER. I did try this on my machine but did not receive an email.

Metadata Update from @jflory7:
- Issue untagged with: help wanted
- Issue assigned to shraddhaag

5 years ago

If you are on a Linux system, I think you can use a local mailbox on your machine to test email functionality (i.e. not sending test emails out on the public Internet from your laptop). You can send email to your system username on localhost. For me, this would be jflory@localhost for the email address. If I remember right, the email content should be found at /var/spool/mail/$USER. I did try this on my machine but did not receive an email.

Sorry about the delayed response! I configured the mail to be sent on the local mailbox but the messages aren't being sent there. I also tried configuring it to send the mails using the gmail SMTP server but that didn't work out either. In both the cases though, no errors were logged. I'm trying to figure out a solution for this.

I'll be sure to post my findings here :)

@jflory7 I have been successfully able to send emails using Gmail SMTP server. The changes to the code base made are:

In settings/dev.py:

CELERY_EMAIL_BACKEND = "django.core.mail.backends.smtp.EmailBackend"
EMAIL_BACKEND = 'djcelery_email.backends.CeleryEmailBackend'
EMAIL_HOST = "smtp.gmail.com"
EMAIL_USE_TLS = True
EMAIL_PORT = 587
EMAIL_HOST_USER = "<HOST@EMAIL.COM>"
EMAIL_HOST_PASSWORD = "<HOST_EMAIL_PASSWORD>"

In docker-compose.yml, under the service celery:

ports:
  - "587:587"

As to why it was not working previously, it was because of my college network configurations. Switching to a different network solved the problem for me.
I'm not entirely sure as to why the above is not working on the production server. The main differences between the two is port being configured for sending the mail ie EMAIL_PORT = 587 and the ports: -"587:587"

@jflory7 Could you please guide me as to how should I proceed further?

@shraddhaag Nice digging. Just now, I checked the configuration on the server of the production site and it is set up to be a mail server on localhost. However, I don't think it is correctly figured to be a mail server and it probably doesn't make sense for us to spend time setting up an email server.

Instead, we could use something like Sendgrid to handle SMTP for us. We could configure our application to point to the Sendgrid SMTP servers. This saves a lot of headache over battling email in our deployment.

I think a pull request with the changes you suggest is still useful, since eventually we want to deploy via Docker (production is not set up with containers yet). But I have a feeling the root cause of this bug is that email is not being delivered by the production server or it is getting lost in spam filters.

Edit: See this README with some mentions of various email providers.

Metadata Update from @jflory7:
- Issue marked as depending on: #198

5 years ago

it probably doesn't make sense for us to spend time setting up an email server.

That makes sense to me

Instead, we could use something like Sendgrid to handle SMTP for us. We could configure our application to point to the Sendgrid SMTP servers. This saves a lot of headache over battling email in our deployment.

I looked into Sendgrid and found this could be used to configure Sendgrid to handle sending emails. Should I configure it or this is to be done in staging/production environment?

Apart from this, I found this in settings/deployment.py
EMAIL_HOST = 'in.mailjet.com'
I am wondering if mailjet was configured to be used with fedora-happiness-packets before?

I think a pull request with the changes you suggest is still useful, since eventually we want to deploy via Docker (production is not set up with containers yet).

I've opened the PR #199 for the same :)

I looked into Sendgrid and found this could be used to configure Sendgrid to handle sending emails. Should I configure it or this is to be done in staging/production environment?

It's okay for this to be done in the staging/production environment only. For testing in the development environment, I think it's acceptable to use the console output from Celery to get to the email message when testing changes out.

Apart from this, I found this in settings/deployment.py
EMAIL_HOST = 'in.mailjet.com'
I am wondering if mailjet was configured to be used with fedora-happiness-packets before?

Great question. I am not sure myself since this is before my time on the project. I assume this was used before but we can probably use something to meet our needs today and make a note in documentation.

I've opened the PR #199 for the same :)

Super, thanks! :tada: I will work at reviewing this PR soon (Friday by the latest).

Metadata Update from @jflory7:
- Issue set to the milestone: Summer Coding 2019: community bonding

5 years ago

Metadata Update from @jflory7:
- Issue unmarked as depending on: #198

5 years ago

Since @shraddhaag addressed this in #199, I am closing this ticket as complete. To fix this in production, we need to set up an outgoing mail service provider when we get to #111. Perhaps Fedora Infra has something we can use or we can use a third-party provider.

Thanks again for working on this one @shraddhaag! Closing. :clapper:

Metadata Update from @jflory7:
- Issue close_status updated to: complete
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata
Attachments 1