freescout-help-desk / freescout

FreeScout — Free self-hosted help desk & shared mailbox (Zendesk / Help Scout alternative)
https://freescout.net
GNU Affero General Public License v3.0
2.99k stars 490 forks source link

Misspelled address in 'Bcc' field generates hourly duplicate emails for the valid recipient #870

Closed radarsymphony closed 1 year ago

radarsymphony commented 3 years ago

Summary

When a user misspells an address in a 'Bcc' field, the valid recipients in the 'To' field receive hourly duplicates of the email.

Steps to reproduce

1) Create a New Conversation from within a mailbox. 2) Optional: Add text for body and subject-line. 3) In the ‘To Field’, add a valid address (the Recipient). 4) In the ‘Bcc Field’, add a misspelled address. Clipboard_2020-11-15-15-43-32 5) Send. 6) The (initial) email arrives in the Recipient’s inbox. 7) In this example, a duplicate email is received 5 minutes later, and then another duplicate every hour after that. Clipboard_2020-11-15-15-49-48

What is the current bug behaviour?

If a user misspells a Bcc'd address, the main recipient will keep receiving duplicate emails (until the job queue is cleared). As expected, the following error appears within ‘Outgoing Email’ and ‘Send Errors’ in the logs: Send error. Expected response code 354 but got code "554", with message "554 5.5.1 Error: no valid recipients ".

What is the expected or correct behaviour?

If an address is misspelled, other recipients should only receive one email, even if the undelivered email is added to a job queue and attempted a few more times. In an additional test, the valid and misspelled addresses were swapped. No email came through to the Bcc'd recipient (this is good and expected), the job just sat in the queue until cleared.

Possible fixes

Is there a way to keep track of successful deliveries for each recipient separately?

Interim Solution: 1) In mailboxes, Click on ‘Manage’ → ‘System’ 2) Scroll to the ‘Background Jobs’ section. 3) Click ‘Cancel’ for the job that is repeatedly sending an email. Clipboard_2020-11-15-15-35-41

Note: From the subheading under “Background Jobs”, it looks like this issue would have resolved itself after some time limit: “Queued and failed jobs are cleaned automatically once in a while. No need to worry or delete them manually.” Question: How often are queued and failed jobs auto-cleaned from the system?

freescout-helpdesk commented 3 years ago

Which mail server are you using?

radarsymphony commented 3 years ago

We are using postfix, but we can recreate the issue with others as the problem arose outside of an internal message.

freescout-helpdesk commented 3 years ago

You won't be able to reproduce this on https://demo.freescout.net/

It looks like the problem here is that the mail server sending emails returns an error immediately if the recipient address does not exist. This is a strange behavior. Normally mail server accepts an email for delivery, returns successful status code and if the email can not be delivered, sends a bounce message to the sender.

tiredofit commented 3 years ago

Interesting, I am able to replicate this as well on my own instance. I utilize a postfix (MTA) (lookup against LDAP) which forwards via dagent to Kopano Mail services (Formerly Zarafa) It seems that if a user is not in the usertable it instantly rejects, which I feel is the right way to do things, otherwise a user could effectively DoS a mail server with recipients that don't exist and clog their network bandwidth/fill their queue.

I also tried it with a MX in front of it ie Postal MTA -> Postfix (LDAP Lookup) -> Kopano.

fvdm commented 3 years ago

@freescout-helpdesk

It looks like the problem here is that the mail server sending emails returns an error immediately if the recipient address does not exist. This is a strange behavior. Normally mail server accepts an email for delivery, returns successful status code and if the email can not be delivered, sends a bounce message to the sender.

Bounce mails are not okay anymore thanks to back scatter spam and tight mail integrations. When a user does not exist the receiving MTA immediately returns a permanent error, allowing the sending MTA to handle it in a clean way.

freescout-helpdesk commented 3 years ago

@radarsymphony do you have "IMAP Folder To Save Outgoing Replies" configured in the mailbox "Fetching Emails" settings?

radarsymphony commented 3 years ago

@freescout-helpdesk That field is currently blank under our "Fetching Emails" settings. As in, we don't have that option active, but could implement it.

freescout-helpdesk commented 3 years ago

This issue is not trivial.

With servers like in this case, which are returning an error when one of the recipients can not receive the email, on PHP side there is no way to find out which emails were actually sent and which - not.

For example, if an email to a customer contains 2 CC addresses and 3 BCC addresses. Your mail server delivers an email to all BCC and to one CC address, but one CC address fails, your mail server returns a failure response without specifying which recipients succeeded and which - not:

Send error. Expected response code 354 but got code "554", with message "554 5.5.1 Error: no valid recipients ".

By the way Gmail/GSuite and other popular mail services behave normally.

freescout-helpdesk commented 3 years ago

What we can do is to collect most popular mail server responses designating delivery failure to one or more recipients (like 554 5.5.1 Error: no valid recipients) and consider the email successfully delivered in such cases and not try to resend it.

So, please post in this issue error messages you are receiving (see "Outgoing Emails" or "Manage > Logs > Send Errors" ), when FreeScout sends duplicate emails.

radarsymphony commented 3 years ago

Hi @freescout-helpdesk When the issue is triggered, the following error gets added to "Manage > Logs > Send Errors":

Expected response code 354 but got code "554", with message "554 5.5.1 Error: no valid recipients "; File: /www/html/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php (457)

fulldecent commented 2 years ago

Can this please be replicated in the new 1.8 version?

freescout-helpdesk commented 1 year ago

Closing for no activity.

dabesa commented 1 year ago

I just got this behavior and we sent dozen of emails to the same recipients that were in BCC. The email we sent was like this: From: To: cc: bcc:

Each recipient in BCC got dozens of emails until I killed the processes in the FreeScout queue.

Do you need any information for this?

Thanks

freescout-helpdesk commented 1 year ago

Can you send error messages for this email from Manage > Logs >Send Errors.

dabesa commented 1 year ago

Hi, I don't find that option: image

Where is it?

freescout-helpdesk commented 1 year ago

Try to check App Logs.

dabesa commented 1 year ago

There's no error log under there: image

dabesa commented 1 year ago

Under queue-jobs I see the tasks Processed:

image

I see a laravel error, around the time I killed the job:

Call to undefined method App\Misc\Helper::checkRequiredExtensions() {"userId":1,"email":"","exception":"[object] (Symfony\Component\Debug\Exception\FatalThrowableError(code: 0): Call to undefined method App\Misc\Helper::checkRequiredExtensions() at /home/cafeanal/helpdesk.cafe-analog.nl/app/Http/Controllers/SystemController.php:34)

dabesa commented 1 year ago

@freescout-helpdesk was it helpful somehow?

malejoavilas commented 10 months ago

What we can do is to collect most popular mail server responses designating delivery failure to one or more recipients (like 554 5.5.1 Error: no valid recipients) and consider the email successfully delivered in such cases and not try to resend it.

So, please post in this issue error messages you are receiving (see "Outgoing Emails" or "Manage > Logs > Send Errors" ), when FreeScout sends duplicate emails.

Hello,

I'm getting this errors when I send an email from a Ticket.

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'smtp_queue_id' in 'field list' (SQL: insert into send_logs (thread_id, message_id, email, mail_type, status, customer_id, user_id, status_message, smtp_queue_id, updated_at, created_at) values (3843, reply-3843-7ac3f1e2687b4b60@mobiera.net, m.avila@mobiera.com, 1, 1, 6, , , 65A9D200EC, 2023-12-11 16:21:03, 2023-12-11 16:21:03)); File: /var/www/html/vendor/laravel/framework/src/Illuminate/Database/Connection.php (664)

nooblag commented 8 months ago

Hi there, yes there may be a possible regression on this issue?

I experienced the same sort of issue today on version 1.8.117. Messages with BCC recipients that fail caused the whole conversation to resend, which meant successful recipients also received it again every minute (which is when the cronjob for artisan schedule:run is set to operate)...