Confirmed user becomes system unconfirmed due to bounce?

luison · May 30, 2018, 4:06pm

Hi again
On my endless “challenge” to learn and optimise my bounce rules (see Please help clarifying Advance Bounce Processing and Error when creating advance bounces rules) just came across something I am uncertain if it is a bug or a system standart procedure which I don’t get. In both case I would be most grateful if someone could clarify how to avoid/fix.

I include the history of a user removing (with XXXXXXX) personal references:

129738	164.132.xxx.190	30 May 2018 16:41:51	Bounced system message
Detail

&lt;br/&gt;Subscriber marked unconfirmed
&lt;br/&gt;&lt;a href=&quot;./?page=bounce&amp;amp;id=629&quot;&gt;View bounce&lt;/a&gt;

Info
REMOTE_ADDR = 164.132.xxx.190
REQUEST_TIME = 1527691255

-----------------------
119159	188.76.xxx.47	27 May 2018 20:53:12	Confirmation
Detail
Lists: 
*XXXXXXXXXXXX

Info
HTTP_USER_AGENT = Mozilla/5.0 (Linux; Android 7.0; SAMSUNG SM-T813 Build/NRD90M)         AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/7.2 Chrome/59.0.3071.125 Safari/537.36
REMOTE_ADDR = 188.76.xxx.47
REQUEST_TIME = 1527447192

-----------------------
119150	188.76.xxx.47	27 May 2018 20:42:07	Change
Detail
email = gimaxxxxxxxx@gmail.com
*changed* from GIMAxxxxxxx@HOTMAIL.COM
confirmed = 0
*changed* from 1
Saludo - Title = D.
*changed* from 
Acepto los términos de la política de privacidad disponibles en http://xxxxxxxxx.com/esp/privacy.php = on
*changed* from 
Idioma - Language = esp
*changed* from 

List Membership: 
* xxxxxxxxxxxxxxxxxxxxxx

I understand this process in reverse order was:

user access his prefrerencesurl
– user changed his email from a hotmail to a gmail account
– user accepts new privacy policy and changes languages
the system sends a confirmation message to both old and new email with link for confirmation
the user, access the confirmation URL and accepts it from his mobile, so becomes confirmed
today, when I process bounces, the “old” address email bounce, marks the user as unconfirmed again

The bounce email displays as “bounced system message” so I am assuming is not to do with our own rules! I can included if necessary but I am wondering:

is it not enough if the user clicks the link of the new email address?
does “any kind” of bounce produce the user “unconfirmed” of the previous email address?
do the “system messages” take precedence to the advance rules… this is… could I try to get a rule to “Delete this kind of bounces” of previous email address or would that never work as the system ones would be executed first?

Many thanks again. Kind regards.

Jose Luis

samtuke · June 1, 2018, 11:05am

Others will likely be able to shed more light on this, but preliminarily: system message bounces and campaign bounces should be treated the same as far as automatic unconfirming and blacklisting is concerned. I’d be surprised if confirmation messages were sent to both the old and the new address when the preferences were changed.

Presumably you’re aware of the configurable bounce thresholds for automatic unconfirming and blacklisting.

luison · June 1, 2018, 11:43am

I have two cases like that. The other one, the bounce on the “old address” was caused by a spam report.
The threshold I understand does not work here… that system action marks immediately as unconfirmed. Unless I can fore a rule to ignore those “old email” bounces I don’t see how to avoid it. Thanks.

luison · June 4, 2018, 6:15pm

Further to this issue which I still have not managed to resolve I have another similar related behaviour it would be great to understand too:

This subscribers history is:

116834	95.245.xxx.43	25 May 2018 19:45:33	Re-Subscription
Detail
Subscribe page: 2
Nombre - Name = Alberto
Provincia - Province = XXXXXXXXX
Apellidos - Surname = XXXXXXX
Saludo - Title = D.
Acepto los términos de la política de privacidad disponibles en http://xxxxxxxx.com/esp/privacy.php = on
Pais - Country = Italia
Idioma - Language = eng
email = A.romano@xxxxxxxnoriva.it
*changed* from a.romano@xxxxxxxnoriva.it
subscribepage = 2
*changed* from 
Saludo - Title = D.
*changed* from 
Acepto los términos de la política de privacidad disponibles en http://golfinspain.com/esp/privacy.php = on
*changed* from 
Idioma - Language = eng
*changed* from 

List Membership: 

* xxxxxxxxxxxxxxxxxxxxx
* 

Info
HTTP_USER_AGENT = Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) AppleWebKit/604.5.6         (KHTML, like Gecko) Version/11.0 Mobile/15D100 Safari/604.1
HTTP_REFERER = https://listas.xxxxxxx.com/?p=subscribe
REMOTE_ADDR = 95.245.xxx.43
REQUEST_TIME = 1527270332

---------------------------

116830	95.245.xxx.43	25 May 2018 19:42:00	Unsubscription
Detail
Unsubscribed from * Todas las listas
Info
HTTP_USER_AGENT = Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) AppleWebKit/604.5.6     (KHTML, like Gecko) Version/11.0 Mobile/15D100 Safari/604.1
HTTP_REFERER = https://listas.xxxxxxx.com/?p=unsubscribe&id=2
REMOTE_ADDR = 95.245.xxxx.43
REQUEST_TIME = 1527270120

My understanding in this case is that the user initially unsubscribes (?) ar 19:42 and later access the preferences pages changes his email (only changing capital A. from lowercase a.)

This user remains unsubscribed… now the question is:

should it not be that fillin in the preferences pages, marking accepting conditions and ticking the lists you want to subscribe mean… this user is confirmed?
not sure if in this case a system message (confirmation mail) was sent due to the change of “A.” from “a.”… should system messages reflected on the users history?

Thanks.

luison · July 2, 2018, 2:40pm

Still haven’t been able to confirm this issue, any help will be appreciated.

luison · July 16, 2018, 10:35am

Further to this I today found another case beyond what I understand phplist should work.
This is the subscription history phplist reports, I’ve removed irrelevant data.

The way I read it the user unsubscribed from all list and was added to blacklist (which not even sure why that is standard procedure) at 19:42, then he changed his data and subscribed again at 19:45. Not saying that this is logical but… should have the user not come out of blacklist if he fills in subscription page again? Is blacklist a “forever” category that only can be removed via backend?

Subscriber is blacklisted since 25 May 2018 19:42:00
Blacklist info
reason  (empty)	 

Subscription history
116834	95.245.103.43	25 May 2018 19:45:33	Re-Subscription
Detail
Subscribe page: 2
Nombre - Name = Alberto
Provincia - Province = XXXXX
Apellidos - Surname = XXXXXX
email = A.rxxxmano@unrealdomain.it
*changed* from a.rxxxmano@unrealdomain.it
subscribepage = 2
*changed* from 
Saludo - Title = D.
*changed* from 
(terms) = on
*changed* from 
Idioma - Language = eng
*changed* from 

List Membership: 

* Boletín de ofertas de golf en español
* Ofertas Privadas, Escapadas Secretas

Info
HTTP_USER_AGENT = Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) AppleWebKit/604.5.6 (KHTML, like Gecko) Version/11.0 Mobile/15D100 Safari/604.1
HTTP_REFERER = https://xxxxx.xxxxxxx.com/?p=subscribe
REMOTE_ADDR = 95.xxxx.103.43
REQUEST_TIME = 1527270332

--------------------------------------
116830	95.xxx.103.43	25 May 2018 19:42:00	Unsubscription
Detail
Unsubscribed from * (all lists)
Info
HTTP_USER_AGENT = Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) AppleWebKit/604.5.6 (KHTML, like Gecko) Version/11.0 Mobile/15D100 Safari/604.1
HTTP_REFERER = https://xxxxx.xxxxxxx.com/?p=unsubscribe&id=2
REMOTE_ADDR = 95.xxxx.103.43
REQUEST_TIME = 1527270120