Secondary Email Address in Account

[Knight1]

When customer xy moves Domain SOA from Domain xyz.de to desec.io and there are Problems involving the Domain which makes the administration unavailable, for example wrong MX and Login forgotten.. An alternative Email for such cases would be great!

[peterthomassen]

If you forget to think of this and add the secondary address ahead of time, the feature does not help.

If you are lucky enough to think of it: it's already possible to change the account email address. Wouldn't the same effect be achieved by temporarily changing the account email address?

[Knight1]

Thought about it. But not implementing it because the user could forget it is a bit odd.

Second opinion, what if you block the account because of DDoS, ..? The User would not be able to communicate with you, nor you with the user.

[peterthomassen]

We do not block accounts because of DDoS. IP addresses are rate limited (for log-in attempts only), and if a user logged in successfully, then the number of API operations per interval is limited for that user. However, there is no scenario where a user cannot login from anywhere and use the account.

But not implementing it because the user could forget it is a bit odd.

That wasn't my point. I said that if users think of solving this problem at all, they might just as well change the account email address in order to migrate their main mail domain, and then change the address back. This way, if something goes wrong during the transfer, they can recover using the temporary address.

I am not at all trying to talk you out of the idea; I'm trying to discuss pros and cons so that we can properly think about whether it should be done, and what priority it should have. That's all :-)

Maybe @nils-wisiol has some thoughts too.

[mustelid]

I'd like to see this implemented as well. Offering the user the option of providing a backup/recovery email could reduce account lockout scenarios for this important service.

[pbiering]

I'd like to see this implemented as well. Offering the user the option of providing a backup/recovery email could reduce account lockout scenarios for this important service.

Me too, but not only for covering lockout scenarios but also "overseen" and/or potential "spam" categorized for one of the recipient mailboxes. In addition I would like to see "increased (and re-sent) notification and grace period" for regular but very important account confirmation...I've temporary lost my entries because I was on vacation for some weeks.

[peterthomassen]

Other use case: Users often sign up with special email addresses ([email protected]) but then start support requests from another address ([email protected]).

We keep telling them to resend from the former, which they're sometimes not set up to do. It would be easier if those folks could lodge a secondary address from which support requests can be started.

This raises the question of permissions on email addresses. Should some only be used to send notifications, while others are "equivalent" to the main address (password reset, support requests)?

---

Perhaps this could be addressed by categorizing email addresses as primary (fully functional) and secondary (read-only). However, data structures currently allow one primary address only; having the user "pick" one primary from all their addresses is much less implementation work.

An alternative to using secondary email addresses for support requests could be to send a verification link pertaining to the specific support request('s email) to the main address.

Not sure what all the trade-offs are.