Hi Dan,
The .invalid is automatically appended to an email address when a bounce occurs if the sent email can't be delivered because of a permanent issue. For example, a bounce might occur if the user's email address is either invalid or the mailbox is full or unavailable (even an "out-of-office reply" has triggered this bounce). This information is supplied by AWS (Amazon Web Services), who we use to host all MoodleCloud sites and deliver site related emails.
MoodleCloud appends a user's email with ".invalid" when AWS tells us the email address bounces. This is automated to avoid repeated attempts to send an email that is bouncing back.
You can manually remove ".invalid" from the users' email addresses in your site and this should resolve the issue, unless the user's mailbox does not accept the email. The user should also check their email filters to make sure they accept (and not automatically reject) the email notifications from your MoodleCloud site. If your users use an institutional email, check your organisation's email server for filters that may have been applied that detect the email is from AWS/bulk email, and reject it.
Regards,
Christian
The .invalid is automatically appended to an email address when a bounce occurs if the sent email can't be delivered because of a permanent issue. For example, a bounce might occur if the user's email address is either invalid or the mailbox is full or unavailable (even an "out-of-office reply" has triggered this bounce). This information is supplied by AWS (Amazon Web Services), who we use to host all MoodleCloud sites and deliver site related emails.
MoodleCloud appends a user's email with ".invalid" when AWS tells us the email address bounces. This is automated to avoid repeated attempts to send an email that is bouncing back.
You can manually remove ".invalid" from the users' email addresses in your site and this should resolve the issue, unless the user's mailbox does not accept the email. The user should also check their email filters to make sure they accept (and not automatically reject) the email notifications from your MoodleCloud site. If your users use an institutional email, check your organisation's email server for filters that may have been applied that detect the email is from AWS/bulk email, and reject it.
Regards,
Christian
Thanks, Christian, that helps. Although, one of the emails that was getting an 'invalid' tacked on was mine, dan@sabier.org, which is a manager account. There are some 'fake' emails I created for students who don't have email and will never use email and are just test accounts. The other email address also use the sabier.org domain name. Could Moodle or AWS be marking any email with that domain as invalide?
Hi Dan,
The ".invalid" is added per email address, as the system is notified an email bounced. There is no bulk operation done for a domain as a whole.
Best regards,
Mathieu
The ".invalid" is added per email address, as the system is notified an email bounced. There is no bulk operation done for a domain as a whole.
Best regards,
Mathieu
We had the same issue, to stop tutors and admin staff getting .invalid when they went on holiday and had an out of office on, I instigated a rule on our email server that would not allow any email being sent to the noreply@ email address which sends all emails on behalf of the moodlecloud. This doesn't resolve the issue for learners, but did resolve the issue for staff.
The main issue was that users aren't told that they are no longer going to receive emails, they just stop. So staff members missed assignments being handed in, and other announcements.
We then do a monthly check on learners who have had .invalid added to their email address and see if something has changed. 98% of the time they have had an out-of-office on which has caused a bounce back.
The main issue was that users aren't told that they are no longer going to receive emails, they just stop. So staff members missed assignments being handed in, and other announcements.
We then do a monthly check on learners who have had .invalid added to their email address and see if something has changed. 98% of the time they have had an out-of-office on which has caused a bounce back.