Removing of bounce address from client.users?
Let's say I have an email subscribed to multiple lists and almost all of them are generating bounce messages upon sending to that address. It is pretty much it is confirmed that this address is now stale and does not work now.
Except from unsubscribing it from the lists I also think it would be wise to remove it from client.users.
I need some pointers regarding if this should be applied or not? Am I missing some crucial info here?
On Fri, Mar 15, 2019, at 9:52 AM, Aaryan Bhagat wrote:
When we are talking about Core, client.users doesn't make any
sense. A better term to use will be just "User entry". Client is a Python
API library, that can optionally be used to manage Core.
I don't think you need to remove a user entry, you should change properties of the address since a user could have multiple addresses and we don't want to disable delivery on all of them if only one of them in bouncing frequently.
You can always disable delivery on an address, without having to remove the membership or delete them. See how you can set preferences1 on a address to disable delivery.
-- thanks, Abhilash Raj (maxking)
Thanks for clarification abhilash, however a small query is there upon seeing you reply.
a user could have multiple addresses
This means a user having a specific email let's say "abc@example.com" is subscribed to multiple mailing-lists(addresses).
The email will be unique of every user. It is not like a single user can have multiple emails subscribed to multiple mailing-lists.
We will treat the multiple emails as separate users right?
Also I have begun writing the proposal. I have a concrete idea of what should we implement. Although it lacks multiple us-case diagrams as of now.
On Mon, 18 Mar 2019, 22:07 Abhilash Raj, <maxking@asynchronous.in> wrote:
On Mon, Mar 18, 2019, at 9:43 AM, aaryan bhagat wrote:
No, this means that a user can have multiple email addresses:
User Foo:
- Email: foo@example.com
- Email: foo1@example.com
- Emai: Foo4@example.org
The email will be unique of every user.
Yes, one email belongs to one user. But, one user can have many email addresses.
It is not like a single user can have multiple emails subscribed to multiple mailing-lists.
Yes, one user can have multiple emails subscribed to multiple mailing lists.
So from above, "User Foo" could be subscribed to
- "Member of list1.example.com" with "Email: foo@example.com"
- "Member of list2.example.com" with "Email: foo@example.com"
- "Member of list2.example.com" with "Email: foo1@example.com <mailto:foo@example.com>"
- "Member of list2.example.com" with "Email: foo4@example.com <mailto:foo@example.com>"
So, one user can subscribe to same mailing list with more than 1 email address.
We will treat the multiple emails as separate users right?
No, addresses belong to user, but more than 1 address can belong to same user.
Cool!
-- thanks, Abhilash Raj (maxking)
On 3/18/19 9:43 AM, aaryan bhagat wrote:
Thanks for clarification abhilash, however a small query is there upon seeing you reply.
I'm really just an outside observer here, but it seems to me that in this thread you (aaryan) are getting way ahead of yourself. I know you are interested in this as a GSOC project, but it seems to me you should be focusing on your GSOC proposal and getting accepted before you start worrying about implementation details.
Yes, a user can. A user can have multiple email addresses, say user@example.com, user@example.net and user@other.example.org, but possibly many more.
These addresses can be subscribed to multiple lists with multiple roles and settings. For example, user@example.com is owner of list1 and digest member of list2. user@example.net is regular member of list1 and list2 and user@other.example.org is a digest member of list2.
This would not be common, but it is allowable and it might not be uncommon for a user to have two or three addresses subscribed to the same list, say one receiving regular deliveries and the others not receiving mail but members for posting purposes.
We will treat the multiple emails as separate users right?
They are not separate users but they are separate addresses all associated with the same user, but for the purposes of bounce processing, we only want to consider the address which is bouncing.
I'm glad you are working on your proposal. You may be doing just fine with this, but sometimes it seems you are getting side tracked with questions that can be deferred to the actual implementation.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
I'm really just an outside observer here, but it seems to me that in this thread you (aaryan) are getting way ahead of yourself. I know you are interested in this as a GSOC project, but it seems to me you should be focusing on your GSOC proposal and getting accepted before you start worrying about implementation details.
I understand your concern and honestly was bit of reluctant asking this due to this reason only (me deviating). But my GSoC proposal demands implementation of bounce handling. I can just write the theoretical details only in the proposal, but that would be incomplete and misguiding. I also need to know whether implementation of feature/event X is possible, if possible then in which way it could be less demanding on resources. That is why I am considering all the cases and some background information.
I would definitely narrow and focus my approach even further from now on!. Thanks for pointing it out.
On Fri, Mar 15, 2019, at 9:52 AM, Aaryan Bhagat wrote:
When we are talking about Core, client.users doesn't make any
sense. A better term to use will be just "User entry". Client is a Python
API library, that can optionally be used to manage Core.
I don't think you need to remove a user entry, you should change properties of the address since a user could have multiple addresses and we don't want to disable delivery on all of them if only one of them in bouncing frequently.
You can always disable delivery on an address, without having to remove the membership or delete them. See how you can set preferences1 on a address to disable delivery.
-- thanks, Abhilash Raj (maxking)
Thanks for clarification abhilash, however a small query is there upon seeing you reply.
a user could have multiple addresses
This means a user having a specific email let's say "abc@example.com" is subscribed to multiple mailing-lists(addresses).
The email will be unique of every user. It is not like a single user can have multiple emails subscribed to multiple mailing-lists.
We will treat the multiple emails as separate users right?
Also I have begun writing the proposal. I have a concrete idea of what should we implement. Although it lacks multiple us-case diagrams as of now.
On Mon, 18 Mar 2019, 22:07 Abhilash Raj, <maxking@asynchronous.in> wrote:
On Mon, Mar 18, 2019, at 9:43 AM, aaryan bhagat wrote:
No, this means that a user can have multiple email addresses:
User Foo:
- Email: foo@example.com
- Email: foo1@example.com
- Emai: Foo4@example.org
The email will be unique of every user.
Yes, one email belongs to one user. But, one user can have many email addresses.
It is not like a single user can have multiple emails subscribed to multiple mailing-lists.
Yes, one user can have multiple emails subscribed to multiple mailing lists.
So from above, "User Foo" could be subscribed to
- "Member of list1.example.com" with "Email: foo@example.com"
- "Member of list2.example.com" with "Email: foo@example.com"
- "Member of list2.example.com" with "Email: foo1@example.com <mailto:foo@example.com>"
- "Member of list2.example.com" with "Email: foo4@example.com <mailto:foo@example.com>"
So, one user can subscribe to same mailing list with more than 1 email address.
We will treat the multiple emails as separate users right?
No, addresses belong to user, but more than 1 address can belong to same user.
Cool!
-- thanks, Abhilash Raj (maxking)
On 3/18/19 9:43 AM, aaryan bhagat wrote:
Thanks for clarification abhilash, however a small query is there upon seeing you reply.
I'm really just an outside observer here, but it seems to me that in this thread you (aaryan) are getting way ahead of yourself. I know you are interested in this as a GSOC project, but it seems to me you should be focusing on your GSOC proposal and getting accepted before you start worrying about implementation details.
Yes, a user can. A user can have multiple email addresses, say user@example.com, user@example.net and user@other.example.org, but possibly many more.
These addresses can be subscribed to multiple lists with multiple roles and settings. For example, user@example.com is owner of list1 and digest member of list2. user@example.net is regular member of list1 and list2 and user@other.example.org is a digest member of list2.
This would not be common, but it is allowable and it might not be uncommon for a user to have two or three addresses subscribed to the same list, say one receiving regular deliveries and the others not receiving mail but members for posting purposes.
We will treat the multiple emails as separate users right?
They are not separate users but they are separate addresses all associated with the same user, but for the purposes of bounce processing, we only want to consider the address which is bouncing.
I'm glad you are working on your proposal. You may be doing just fine with this, but sometimes it seems you are getting side tracked with questions that can be deferred to the actual implementation.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
I'm really just an outside observer here, but it seems to me that in this thread you (aaryan) are getting way ahead of yourself. I know you are interested in this as a GSOC project, but it seems to me you should be focusing on your GSOC proposal and getting accepted before you start worrying about implementation details.
I understand your concern and honestly was bit of reluctant asking this due to this reason only (me deviating). But my GSoC proposal demands implementation of bounce handling. I can just write the theoretical details only in the proposal, but that would be incomplete and misguiding. I also need to know whether implementation of feature/event X is possible, if possible then in which way it could be less demanding on resources. That is why I am considering all the cases and some background information.
I would definitely narrow and focus my approach even further from now on!. Thanks for pointing it out.
participants (5)
-
aaryan bhagat -
Aaryan Bhagat
-
Abhilash Raj -
Mark Sapiro -
Richard Damon