mirror of
https://github.com/modoboa/modoboa.git
synced 2026-04-27 01:45:58 +03:00
[GH-ISSUE #505] Activation process for new account #487
Labels
No labels
bug
bug
dependencies
design
documentation
duplicate
enhancement
enhancement
enhancement
feedback-needed
help-needed
help-needed
installer
invalid
looking-for-sponsors
modoboa-contacts
new-ui
new-ui
pr
pull-request
pyconfr
python
question
security
stale
webmail
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/modoboa-modoboa#487
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @patrickbenkoetter on GitHub (Jan 2, 2014).
Original GitHub issue: https://github.com/modoboa/modoboa/issues/505
modo should offer an activation process for new accounts. The mailsystem should not route or filter messages for an account that hasn't been activated yet.
This gives us two advantages:
@tonioo commented on GitHub (Jan 3, 2014):
How would you to that? Display a specific wizard on first login?
@patrickbenkoetter commented on GitHub (Jan 3, 2014):
Yes, I think that's how I would do it. The overall process I have on my mind
goes somewhat like this:
Before that an (domain)admin would have to describe a filter policy and enable
the activation process.
A new account would be created, but not activated.
Maybe we would drop a message into the accounts mailbox telling the recipient
she would have to follow this URL to activate the account.
When the user logs into modo she would - immediately after login - have to
read the/a page that describes the filter policy.
Maybe modo/the admin would let the user choose if a certain content class
should be rejected, quarantined or delivered? The choice could lead to
appropriate amavis SQL entries.
Maybe the user would have no choice except accepting the given policy.
If the user accepts the filter policies, the account will be activated; the
user may send and receive messages. The activation date would be noted in the
database. The admin could have a 'lastlogin' command to tell which accounts
have been activated and when.
If the user rejects the policy the mailbox remains deactivated. Maybe a
notification about this should be sent to the (domain)admin.
p@rick
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
@tonioo commented on GitHub (Jan 4, 2014):
Ok I see. That's an interesting idea, I guess it would be usefull for ISP.
@patrickbenkoetter commented on GitHub (Jan 4, 2014):
I think it would be useful to any commercial organization that wants a good
mail administration frontend - at least in Germany.
p@rick
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
@tonioo commented on GitHub (Jan 4, 2014):
Le 04/01/2014 17:57, Patrick Ben Koetter a écrit :
@almereyda commented on GitHub (Nov 23, 2016):
In my reading this would assume the secondary email option mandatory, am I right @patrickbenkoetter?
Also it may be linked to https://github.com/tonioo/modoboa/issues/892#issuecomment-262417834