moderated Alias sending from Gmail is not working correctly for non-member aliased addresses #bug


 

Hi Mark,

I did some testing for something else and found out that this, Changes in how we determine the sender of a message , is not working right again.  Could be Gmail changed something since then, or there was a particular case/scenario which wasn't accounted for, or if there it needs tweaking, not sure, but it is in there somewhere as in both mismatched scenarios below, both FROM: in View Source and log entries record the wrong main account address for the purposes of group-membership checking, not the aliased one which sent the emails.

A. If a non-group-member aliased account (eg. mainacct+alias1@gmail) sends in a message it interprets the sender as the main account (eg. mainacct@gmail), not the aliased one.  (If an existing-group-member aliased account sends in a message it all works and matches fine.)

B. The same condition also manifests when applying to a group by email, the aliased address sends in a +subscribe email but it gets interpreted as the main account and added to the group as such, not the aliased one.

Cheers,
Christos


 

On Thu, Sep 29, 2022 at 3:22 PM Christos Psarras <christos@...> wrote:

I did some testing for something else and found out that this, Changes in how we determine the sender of a message , is not working right again.  Could be Gmail changed something since then, or there was a particular case/scenario which wasn't accounted for, or if there it needs tweaking, not sure, but it is in there somewhere as in both mismatched scenarios below, both FROM: in View Source and log entries record the wrong main account address for the purposes of group-membership checking, not the aliased one which sent the emails.

A. If a non-group-member aliased account (eg. mainacct+alias1@gmail) sends in a message it interprets the sender as the main account (eg. mainacct@gmail), not the aliased one.  (If an existing-group-member aliased account sends in a message it all works and matches fine.)

I'm not sure I understand. Are you saying that:

mainacct+alias1@gmail is not subscribed to the group but mainacct@gmail is subscribed to the group? And that if a message is sent from mainaccount+alias1@gmail to that group, it gets accepted when it should not?

Thanks,
Mark 


 


I'm not sure I understand. Are you saying that:

mainacct+alias1@gmail is not subscribed to the group but mainacct@gmail is subscribed to the group?

Yes.

And that if a message is sent from mainaccount+alias1@gmail to that group, it gets accepted when it should not?

Yes, and it gets accepted as coming from mainaccount@gmail, not mainaccount+alias1@gmail.


In addition, in a group where neither the main or the aliased account are members, if mainaccount+alias1@gmail sends in a +subscribe email, the pending member shows up as mainaccount@gmail, not mainaccount+alias1@gmai.

In both cases, the problem is when mainaccount+alias1@gmail is not a group member and emails something in.

Cheers,
Christos


 

On Fri, Sep 30, 2022 at 7:59 PM Christos Psarras <christos@...> wrote:

I'm not sure I understand. Are you saying that:

mainacct+alias1@gmail is not subscribed to the group but mainacct@gmail is subscribed to the group?

Yes.

And that if a message is sent from mainaccount+alias1@gmail to that group, it gets accepted when it should not?

Yes, and it gets accepted as coming from mainaccount@gmail, not mainaccount+alias1@gmail.

The problem is that Gmail is sending the message with an envelope from of mainaccount@gmail. We first check the message From: address, but then if we don't find a match, we check the envelope from address, which in this case does match. So the system is working as designed. It seems like we're talking about an edge case; does it happen often where you don't want a message sent from an alias of someone who is subscribed to the group? Can that person just not send the message?
 

In addition, in a group where neither the main or the aliased account are members, if mainaccount+alias1@gmail sends in a +subscribe email, the pending member shows up as mainaccount@gmail, not mainaccount+alias1@gmai.

I'm not able to reproduce this. Can someone else try?

Thanks,
Mark 


 

Mark,

In addition, in a group where neither the main or the aliased account are members, if mainaccount+alias1@gmail sends in a +subscribe email, the pending member shows up as mainaccount@gmail, not mainaccount+alias1@gmai.

I'm not able to reproduce this. Can someone else try?

I just retried it and attached the email IDs, and left the user in the group's pending members for your examination.  The scenario is:

1. Neither the main or an alias account is a member of the group.
2. mainaccount_aliasX@gmail sends in a group+subscribe email. (happens only using email, not doing it online)
3. The confirmation email is sent back but it is sent to mainaccount@gmail, not mainaccount_aliasX@gmail.
4. If I reply to it, (as expected) the mainaccount@gmail is placed in the pending members queue, not mainaccount_aliasX@gmail.

The disconnect happens in no.3.  What I think is happening, and of course not knowing how the process/logic is setup, but let's assume for example we have a IsGroupMember code block/path.  Back when you fixed this, Changes in how we determine the sender of a message , you tweaked the IsGroupMember path but did not tweak the Not(IsGroupMember) path, so the former correctly navigates the From/ReplyTo/Envelope values and but the latter doesn't, and it behaves how the former also was behaving ("dropping" the alias) before getting fixed, so the latter still "drops" the alias part of the address.  Or something to this effect, I hope it makes sense.  In Changes in how we determine the sender of a message , if a group subscription is found using the From: field we stop there and use that value from now on for further account interaction, therefore the inbound message now correctly shows as coming from the alias.  But if a group subscription is not found using the From: value, we keep on checking and now come across the Envelope: value which is checked last and is different, and this address end up now being used from now on for further account actions.  I think the NotFound path should revert back to using the From: value for further processing since that's the original+sending+acting address, maybe for Gmail only, unless others do it too.  This should take care of this and totally segregate the alias from the main account in groups.io for any main or alias membership or message-posting scenario.


The problem is that Gmail is sending the message with an envelope from of mainaccount@gmail. We first check the message From: address, but then if we don't find a match, we check the envelope from address, which in this case does match. So the system is working as designed. It seems like we're talking about an edge case; does it happen often where you don't want a message sent from an alias of someone who is subscribed to the group? Can that person just not send the message?

It is an edge/special case in a sense.  Only people using aliases can get potential problems with this, and they are not that many I'd guess.  In my case I use it for testing so I don't mind.  But the ones using the aliases as "separate-emailaddy group subscriptions" so they can get everything in a single inbox, when they try to join a new group using an alias and +subscribe email, it will fail, in the sense that the main account gets added, not the alias.  They can only join that group with an (Gmail I guess) alias if they do it online (login with the alias, then join group)

Cheers,
Christos