Some users receive mail twice
We never had this issue before. We believe the cause is most recent update of Typo3 4.5.15.
We use Directmail 2.7.0 and acquire recipients by special query on base of group membership ("Group contains 16").
There are 170 recipients in list. Until yesterday, only 170 recipients received mail.
Yesterday statistics read:
Recipient total/sent: 170 / 220
Some users must have received mail twice or more.
When accessing recipient list there pops up error in Typo3 log:
Core: Error handler (BE): PHP Warning: Invalid argument supplied for foreach() in /typo3_src-4.5.15/typo3/template.php line 2000
I don't know if this is core issue or directmail?
#3 Updated by Ivan Dharma Kartolo over 7 years ago
the foreach warning is fixed in r59435 http://forge.typo3.org/projects/extension-direct_mail/repository/revisions/59435/diff/trunk/mod1/index.php
this can be found in trunk and branch swiftmailer, where the swiftmailer integration is taking place.
you can check the sys_mail_log table. Every sent mail is logged there. maybe it's just a bug in statistic module.
#4 Updated by Grischa Schüring over 7 years ago
I review sys_mail_log table as well as mail server log. Some recipients received mails twice some few three times.
But this time there were 171 recipients in list
2 recipients received 3 duplicate mails
21 recipients received mails twice
Recipient total/sent: 171 / 184
What do you need to know to track it down?
#5 Updated by Ivan Dharma Kartolo over 7 years ago
- Status changed from New to Needs Feedback
- % Done changed from 0 to 60
- mid = the dmail UID you're sending
- response_type = 0 => other than 0 is the Mail error code, if you set the return mail handling
- return_code = 0
rid => the UID of the recipient
rtbl => f for fe_users t for tt_address
#6 Updated by Grischa Schüring over 7 years ago
I have done as requested.
Still there are duplicate email addresses present, all with response_type=0 and return_code = 0.
What I discovered: We have both cases of duplicate mail addresses with different rid as well as identical rid.
Excerpt (email adresses have been anonymized)
uid, mid, rid, email, rtbl, response_type, return_code
830, 61, 32431, firstname.lastname@example.org, f, 0, 0
831, 61, 32432, email@example.com, f, 0, 0
832, 62, 32433, firstname.lastname@example.org, f, 0, 0
833, 62, 32434, email@example.com,f, 0, 0
837, 62, 32729, firstname.lastname@example.org, f, 0, 0
838, 62, 32729, email@example.com, f, 0, 0
839, 62, 32939, firstname.lastname@example.org, f, 0, 0
840, 62, 32939, email@example.com, f, 0, 0
uid 830 and 831: identical email, different rid
uid 837 and 838: identical email, identical rid
In both cases, uid 830,831 as well as uid 837,838, mails where delivered twice to mail server.
Recipient list was generated by special query (usergroup contains 16).
#8 Updated by Grischa Schüring over 7 years ago
I had already done.
SELECT uid,pid,deleted FROM fe_users WHERE ( usergroup LIKE '%16%' AND usergroup LIKE '%%') AND fe_users.deleted=0
It contained just 171 results which is exactly the same as directmail BE module recipient list output.
From this point of view query is correct, result is correct.
#9 Updated by Grischa Schüring over 7 years ago
Today we sent newsletter and encountered same problems. Some users received mails twice again.
Regarding recipient list module, there were 171 recipient.
Reviewing sys_dmail_maillog, 11 users with identical rid received mail twice.
Please tell us what to do to help track down problem.
#13 Updated by Grischa Schüring over 7 years ago
I believe I found the answer to these problems. Finally. And it is quite simple :-|
Our provider forgot to delete old dmailer cronjob when inserting scheduler. It seems that scheduler activity didn't get synchronized with dmailer cronjob activity.
We tested once with dmailer cron disabled and received results as expected.
Maybe there is a safety way to implement in dmailer logic that stops a parallel task sending mail twice?!
#14 Updated by Ivan Dharma Kartolo over 7 years ago
there is or was a security built in to prevent this kind of things. before the scheduler even exists and the sending only set per Cron, the cron script creates a .lock file in the typo3temp folder to prevent such event. Since the scheduler automatically detects and (can) prevents parallel job, its not in the scheduler task anymore :)
since the cron script will be removed in the upcoming direct_mail 3.0, so I'll let it be :)