-
Notifications
You must be signed in to change notification settings - Fork 508
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Misspelled address in 'Bcc' field generates hourly duplicate emails for the valid recipient #870
Comments
Which mail server are you using? |
We are using postfix, but we can recreate the issue with others as the problem arose outside of an internal message. |
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. |
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. |
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. |
@radarsymphony do you have "IMAP Folder To Save Outgoing Replies" configured in the mailbox "Fetching Emails" settings? |
@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. |
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:
By the way Gmail/GSuite and other popular mail services behave normally. |
What we can do is to collect most popular mail server responses designating delivery failure to one or more recipients (like So, please post in this issue error messages you are receiving (see "Outgoing Emails" or "Manage > Logs > Send Errors" ), when FreeScout sends duplicate emails. |
Hi @freescout-helpdesk
|
Can this please be replicated in the new 1.8 version? |
Closing for no activity. |
I just got this behavior and we sent dozen of emails to the same recipients that were in 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 |
Can you send error messages for this email from Manage > Logs >Send Errors. |
Try to check App Logs. |
Under queue-jobs I see the tasks Processed: 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) |
@freescout-helpdesk was it helpful somehow? |
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 |
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 |
Hello, Queue job logs: |
"malformed address" error has been added to |
Thank you! You’re huge |
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
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:
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?
The text was updated successfully, but these errors were encountered: