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

[radarsymphony]

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.
   
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.
   

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.
   

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]

Which mail server are you using?

[radarsymphony]

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

[freescout-helpdesk]

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]

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]

@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]

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

[radarsymphony]

@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]

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]

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]

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]

Can this please be replicated in the new 1.8 version?