What is your technique to handle stale / bounced email addresses?

[Dean]

If an account has had an email from the forum bounce, what else could be done besides these?

• disabling emails for the accounts
• deleting/banning accounts

Seeking creative solutions.

At the moment the best I can think of for our small forum is

• leave profile messages for the ones who seem to have trouble confirming accounts
• Send a PM to the active/frequent members (yes the email notification will bounce)
• Do nothing for the members that have abandoned the forum, and let them bounce anyway

 

[SchmitzIT]

I typically disable e-mailing for them, based on the reason why the mail bounced. If I get a "non existing" or "user does not exist" or something similar, that's my default action. If it's a simple matter of the mailbox being full, I'll just leave it as it is.

I'm very much looking forward to the xF ability to have mails bounce to a specific account, though. Very useful, and easy to create rules on, so my main inbox will not be cluttered anymore

 

[CTXMedia]

If it's for an active customer I usually send them a PM explaining that their email is bouncing back (and this is the motivator for them to update their account) - that there is a risk I will see their private messages if they don't update!!!

If they remain active and don't update, they get a sterner warning PM - after that a short 1-day ban followed by a 3-day ban. If they still refuse the ban becomes permanent (but it's never gone that far).

I have considered replacing the email address on their accounts with "bounce@mysitedomain" that drops into a POP box which is then deleted hourly/daily using a cron job on the server; but it only deals with the symptom, not the problem.

Cheers,
Shaun

 

[Paul B]

I'm very much looking forward to the xF ability to have mails bounce to a specific account, though.

You can already do that with the "Bounced Email Address" field in the Email Options.

I have considered replacing the email address on their accounts with "bounce@mysitedomain"...

I did something similar for my phpBB site but in XenForo all email addresses must be unique so you would need a different address for each one.

 

[Brett Peters]

With all the constant changes to email filters I dont like the idea of just letting emails bounce repeatedly.

I would have thought that moving a registered user to unregistered/unconfirmed would give that registered user a prompt to update and confirm their email address as well as stop all emails, Sort of like a ban until the user complies.

In any case I think that you need to submit a feature request to fully help automate this problem.

 

[SchmitzIT]

You can already do that with the "Bounced Email Address" field in the Email Options.


I did something similar for my phpBB site but in XenForo all email addresses must be unique so you would need a different address for each one.

I know, but am not running it on my live-forum yet Can't wait to see it in action, though.

 

[Markos]

Disable e-mailing is a good solution, but imho a perfect solution should be a dedicated mod to do this, like:
http://www.vbulletin.org/forum/showthread.php?t=83486

 

[Fred Sherman]

Just gather them up and write an SQL script to change "Receive site mailings" to no for those users every so often. Its such an easy sql script. Maybe there ought to be a way to do this fromt he admin panel?

 

[James]

Isn't there a risk of getting your site blacklisted by mail servers if you are sending too many bounced e-mails to a specific mail host (such as hotmail, gmail, yahoo)?

or have I just been reading crap...

 

[Brett Peters]

Isn't there a risk of getting your site blacklisted by mail servers if you are sending too many e-mails to a specific mail host (such as hotmail, gmail, yahoo)?

or have I just been reading crap...

You are correct to think that their is a big risk of getting flagged as spam if your bounce rate is to high, This is why most of the main email players have feedback loops.

 

[Markos]

A solution can be a third part service for sending mails...the problem is that system cost so much on a big community. The true solution imho is a script that check the mail returned and delete it on db (see the mod i have linked in my past message).

 

[Mike]

FWIW, if you get a permanent fault bounce for a user, if you change their user/account state back to "awaiting confirmation (from edit)", the only email they'll receive is the confirmation request. Conversation and watched thread emails won't be sent. (They will have the permissions of a guest though, so keep that in mind.)

 

[Dean]

FWIW, if you get a permanent fault bounce for a user, if you change their user/account state back to "awaiting confirmation (from edit)", the only email they'll receive is the confirmation request. Conversation and watched thread emails won't be sent. (They will have the permissions of a guest though, so keep that in mind.)

Nice.

What was the intended difference between "awaiting confirmation (from edit)" and "awaiting confirmation"? EDIT: the difference is what status they are after the re-confirmation vs initial confirmation. Specifically: new registrations can be set to be Moderated.


They both say this, and neither actually sends an email, the link needs to be clicked on:
Your account is currently awaiting confirmation. Confirmation was sent to email <email address>.
Resend Confirmation Email

 

[Dean]

I changed the phrase "your_account_is_currently_awaiting_confirmation_confirmation_sent_to_x" to:
Your account is currently awaiting confirmation. Confirmation was sent to {email}. Or, if you were an active member before and are seeing this message: emails that were sent to your account may have been undeliverable. Please check your email address and click the resend link below.

I believe that would take care of the people that fall into most of the categories. Though not suitable for every situation, at least for us. Actually... if it was automated I could simply tell the members that the forum software needs a valid and working email account, and put the blame squarely where it belongs - which is the recipient... no matter who they are.

 

[Paul B]

What was the intended difference between "awaiting confirmation (from edit)" and "awaiting confirmation"?

Awaiting email confirmation is for newly registered members who haven't yet clicked on the link sent to them.

Awaiting email confirmation (from edit) is for existing members who then change their email address.

 

[Dean]

Awaiting email confirmation is for newly registered members who haven't yet clicked on the link sent to them.

Awaiting email confirmation (from edit) is for existing members who then change their email address.

Well, yes, that is how it works. But..

• Are there any operational differences, such as the members see different text when they login
• Why have 2 states? My best guess at this time would be a member management viewpoint - so admins can tell the difference between an account which has never been confirmed vs an account that was confirmed at least once.

 

[James]

It'd make sense to have different text. If you're awaiting email from edit then you were a confirmed member to begin with (unless you'd gone from an inaccessible email to another inaccessible email), so it should show different text to someone who hasn't been activated at all.

 

[Dean]

I found the answer to my question 'why have 2 separate groups', and put that in my previous post here

I'll move this over in the general forum. Initially it was a general question regarding user management, but with Mikes help as turned into a thread specific to xf which showcases another awesome xf feature.

 

[novice]

Is there a query that will change ALL MEMBERS user/account state to "awaiting confirmation (from edit)" ?

Thanks

 

[Paul B]

UPDATE xf_user SET user_state = 'email_confirm_edit'