[GH-ISSUE #505] Activation process for new account #487

Open
opened 2026-02-27 11:12:01 +03:00 by kerem · 6 comments
Owner

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:

  1. We don't accept and store spam/malware for an inactive account
  2. The user explicitly has to consent to the domains filtering policy. The consent creates the legal ground. If spam is e.g. suppressed the user can't complain, because he/she consented in the first. Without consent the account must not be activated.
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: 1. We don't accept and store spam/malware for an inactive account 2. The user explicitly has to consent to the domains filtering policy. The consent creates the legal ground. If spam is e.g. suppressed the user can't complain, because he/she consented in the first. Without consent the account must not be activated.
Author
Owner

@tonioo commented on GitHub (Jan 3, 2014):

How would you to that? Display a specific wizard on first login?

<!-- gh-comment-id:31520033 --> @tonioo commented on GitHub (Jan 3, 2014): How would you to that? Display a specific wizard on first login?
Author
Owner

@patrickbenkoetter commented on GitHub (Jan 3, 2014):

  • Antoine Nguyen reply@reply.github.com:

    How would you to that? Display a specific wizard on first login?

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

<!-- gh-comment-id:31560548 --> @patrickbenkoetter commented on GitHub (Jan 3, 2014): - Antoine Nguyen reply@reply.github.com: > How would you to that? Display a specific wizard on first login? 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
Author
Owner

@tonioo commented on GitHub (Jan 4, 2014):

Ok I see. That's an interesting idea, I guess it would be usefull for ISP.

<!-- gh-comment-id:31578525 --> @tonioo commented on GitHub (Jan 4, 2014): Ok I see. That's an interesting idea, I guess it would be usefull for ISP.
Author
Owner

@patrickbenkoetter commented on GitHub (Jan 4, 2014):

  • Antoine Nguyen reply@reply.github.com:

    Ok I see. That's an interesting idea, I guess it would be usefull for ISP.

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

<!-- gh-comment-id:31582841 --> @patrickbenkoetter commented on GitHub (Jan 4, 2014): - Antoine Nguyen reply@reply.github.com: > Ok I see. That's an interesting idea, I guess it would be usefull for ISP. 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
Author
Owner

@tonioo commented on GitHub (Jan 4, 2014):

Le 04/01/2014 17:57, Patrick Ben Koetter a écrit :

  • Antoine Nguyen reply@reply.github.com:

    Ok I see. That's an interesting idea, I guess it would be usefull
    for ISP.

I think it would be useful to any commercial organization that wants a
good
mail administration frontend - at least in Germany.

I don't know for other countries. France for example doesn't require
such a process.

<!-- gh-comment-id:31583900 --> @tonioo commented on GitHub (Jan 4, 2014): Le 04/01/2014 17:57, Patrick Ben Koetter a écrit : > - Antoine Nguyen reply@reply.github.com: > > Ok I see. That's an interesting idea, I guess it would be usefull > for ISP. > > I think it would be useful to any commercial organization that wants a > good > mail administration frontend - at least in Germany. > > I don't know for other countries. France for example doesn't require > such a process.
Author
Owner

@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

<!-- gh-comment-id:262422074 --> @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
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/modoboa-modoboa#487
No description provided.