[FreddysHouse] Bounced Email 0.1.6

[SheepCow]

SheepCow updated [FreddysHouse] Bounced Email with a new update entry:

Minor bug fixes

• Fixes the default value for one of the options.
• Fixes possible incorrect files in previous release (damn you Google Drive).

Read the rest of this update entry...

 

[SheepCow]

Yes, I made a clean install but it times out on every attempt. I checked the addon it seems to be installed but when I go over the options section the mail settings field is not visible and phrases show up messed up.

Try 0.1.3, I can install, upgrade and un-install it on a relatively clean install without issues.

 

[Matthew Hawley]

This looks very nice!!! I will install once the bugs are ironed out.

Edit: I'm pretty sure I use IMAP. Will IMAP support be added?

 

[yavuz]

Try 0.1.3, I can install, upgrade and un-install it on a relatively clean install without issues.

I was able to upgrade it without a hitch. Thanks

 

[Alpha1]

I've added that info to the FAQ tab.

The following headers make the add-on think an email is a bounce message:

• Existence of the x-failed-recipients header.
• content-type with report-type set to delivery-status

....Bounce detection is a bit over zealous.

That's indeed quite overzealous. This will deactivate an account if an email server sends any form of fail, even if its just a server time out or a full inbox. That could lead to a lot of angry & confused members and a lot of support requests.

Hopefully the conversation sent to the user is more obvious now, remember you can always customise it to say what ever you like.

Often people don't even read the conversation and get lost in the reactivation process. In my experience this leads to a significant number of support requests.

Have you considered to use notices to guide users trough the reactivation steps? (change email, send confirmation mail, click confirmation link)

The way I have this set in my vbulletin addon is that the flag in the user table is one of the following:
1. normal
2. bounced
3. email changed
4. confirmation mail sent
Once confirmed the flag in usertable goes back to normal.
Flag 2, 3 and 4 could be tied to a notice, so that members know exactly what to do next. Members find this function very helpful.

 

[SheepCow]

That's indeed quite overzealous. This will deactivate an account if an em... *snip*

There's no deactivation, the most intrusive action is to turn off email watches / site mailings. You can choose to make it more dramatic but that depends on what you configure the extra group to do.

Once I understand what all the status codes mean I'll make it a bit more configurable though

Often people don't even read the conversation and get lost in the reactivation process.

There is no reactivation process.

Have you considered to use notices to guide users trough the reactivation steps? (change email, send confirmation mail, click confirmation link)

That's up to you, XenForo can make notices appear for specific user groups so you can have a notice appear for bounced users that tells them how to check/change their email address. If they do change their email address XenForo itself will guide them through confirming the address.

In your list of states, 1 is normal, 2 is dealt with by this add-on, 3 and 4 are built-in to XenForo.

 

[Mouth]

Once I understand what all the status codes mean I'll make it a bit more configurable though

A good list for the hard bounce DSN codes is @ http://www.activecampaign.com/help/bounces-soft-bounce-vs-hard-bounce/

 

[Alpha1]

^ Thats a really good starting point.

 

[emc2]

Fantastic @SheepCow!

Definitely installing this mod.

 

[melbo]

Will this work with IMAP email accounts rather than POP?

 

[SheepCow]

Will this work with IMAP email accounts rather than POP?

It doesn't currently, but it should do eventually!

 

[HWS]

I don't think thats a good idea as that has undesired / unexpected effects. XenForo considers members awaiting email confirmation not as members and therefore all kinds of permissions are limited. It will also lower your member count significantly and prevent your members from fixing up their account.

You are not correct. There is a special user state named "Awaiting email confirmation (from edit)". This is where all members with bouncing email accounts should be added. This is the same state members are in if they try to change their email address but never confirm that new address.

I've left this out for now, could add it as an option - however, they won't really be awaiting confirmation since there isn't a valid email address to confirm.

Please add the option to add the bouncing member to the user state "Awaiting email confirmation (from edit)". This would make your add-on much more useful. There IS an email address. It is just wrong. Its the same situation it would be if you made a typo when changing your email address. This is exactly what this "user state" in Xenforo is about.

 

[HWS]

Will this work with IMAP email accounts rather than POP?

Most mail servers can handle IMAP and POP simultaneously. Even if you have an IMAP account you can try to configure it like if it is a POP account. But remember, POP protocol does delete all messages in the IN-box at the server.

 

[Alpha1]

You are not correct. There is a special user state named "Awaiting email confirmation (from edit)". This is where all members with bouncing email accounts should be added. This is the same state members are in if they try to change their email address but never confirm that new address.

The user state 'awaiting email confirmation' does not work optimally for members with bounced email. Users with this user state are not counted towards your member stats. Surely a member with 1000 posts and bouncing email address should be counted as a member.

This user state also prevented these members from editing their account and therefore they could not update their accounts with the correct email address. However, that problem has been fixed in the upcoming XenForo 1.3 release.

 

[HWS]

The user state 'awaiting email confirmation' does not work optimally for members with bounced email. Users with this user state are not counted towards your member stats. Surely a member with 1000 posts and bouncing email address should be counted as a member.

This user state also prevented these members from editing their account and therefore they could not update their accounts with the correct email address. However, that problem has been fixed in the upcoming XenForo 1.3 release.

We are doing that without problems since XF1.1. Bouncing users are set to "Awaiting email confirmation (from edit)" and can change their email address themselves without problems out of that state (which puts them automatically into the "Valid" state again).

Note that there are 2 different user states "Awaiting email confirmation (from edit)" and "Awaiting email confirmation". They are not the same. Maybe your findings are true with the "Awaiting email confirmation" state.

 

[yavuz]

We are doing that without problems since XF1.1. Bouncing users are set to "Awaiting email confirmation (from edit)" and can change their email address themselves without problems out of that state (which puts them automatically into the "Valid" state again).

Note that there are 2 different user states "Awaiting email confirmation (from edit)" and "Awaiting email confirmation". They are not the same. Maybe your findings are true with the "Awaiting email confirmation" state.

I had suggested this, but @SheepCow said somehing about the stane not being a usergroup therefore not possible to do. However, if a solution could be found, this would be awesome indeed.

 

[HWS]

I had suggested this, but @SheepCow said somehing about the stane not being a usergroup therefore not possible to do. However, if a solution could be found, this would be awesome indeed.

This add-on is pretty much useless if users are not transferred to the "valid" state of their initial usergroup again automatically after they've changed and confirmed their new email address.

Currently with that add-on the admin has to manually check all users in the bouncing group if the email works again and put them manually into the regular user group. Which is simply not possible at a larger forum.

Putting them into the "Awaiting email confirmation (from edit)" state would automatically take care of that.

 

[yavuz]

This add-on is pretty much useless if users are not transferred to the "valid" state of their initial usergroup again automatically after they've changed and confirmed their new email address.

Currently with that add-on the admin has to manually check all users in the bouncing group if the email works again and put them manually into the regular user group. Which is simply not possible at a larger forum.

Putting them into the "Awaiting email confirmation (from edit)" state would automatically take care of that.

Hence I had to stop using it because checking 20-30 emails a day wasn't an option unfortunately.

 

[Rob]

+Watch

This modification has some definite potential. I would like to see it handling usergroup changes automatically.... like yavuz I have little time for manual checking and with @ 50K users, manual intervention would be impossible.

Great work so far and subbed for future updates

 

[Alpha1]

We are doing that without problems since XF1.1. Bouncing users are set to "Awaiting email confirmation (from edit)" and can change their email address themselves without problems out of that state (which puts them automatically into the "Valid" state again).

Note that there are 2 different user states "Awaiting email confirmation (from edit)" and "Awaiting email confirmation". They are not the same. Maybe your findings are true with the "Awaiting email confirmation" state.

Thanks that is interesting information. I am referring to this change in XF 1.3:

Changing your email address is not limited by the "edit profile" permission in 1.3. Previously, it created situations where you could make a mistake and not be able to rectify it (as unconfirmed users can't modify their profile by default).

This indeed relates to the "Awaiting email confirmation" state.

But to resolve this XF 1.3 will have a new state for members with bouncing email:

You tell it when someone's email bounces by changing their state to that. (Hence, it's just a new user state