On Thu, Sep 26, 2019 at 08:17 AM, Dave Sergeant wrote:

It all comes down to the decision by Mark to use + as the only
distinguisher of an owners message was a poor one.

Sorry; I think that is unfair. If + is supposed to be acceptable character under the terms of RFC 2821 then using it was a perfectly reasonable decision. The fact that a particular combination of (apparently any) email client, mail provider (BT) and "traffic handler" corrupts addresses with + in them does not negate Mark's original decision.

I have in the non - recent past sent messages to a +owner address without mishap, but clearly I have no idea about what might be responsible for the change in behaviour. I still have some hope that Peter Martinez' enquiry via "BT Community" might bear fruit, although a little of that hope is starting to fade. If other mail service providers allow + addresses to work uncorrupted, then so should BT (etc) under all circumstances.

Having said that I agree that most subscribers are "use by email client" and expecting them to use their mail provider's web UI is probably unrealistic.

Mark; are you in any position whereby you could chase the errant provider(s) from your perspective?

Chris

Dave,

Um, the idea of btinternet users only posting via the web interface is
surely a non starter.

They can post messages to the group using whichever interface they like. It is only email commands (including messages to +owner) that are afflicted by synchronoss' error.

I have no statistics but I sense on the groups I moderate that
probably 80% of users, including a LOT of btinternet users, only use
email and most have never been anywhere near the web interface.

Whose web interface are you talking about? I'm not talking about using Groups.io's web interface, I'm saying those members need to send email commands using btinternet's webmail interface.

From what I've heard, it is only fossils like myself that cling to SMTP email clients like Thunderbird and Outlook Express - that most email users now use their service's webmail interface instead.

Shal

Chris,

Sorry; I think that is unfair. If + is supposed to be acceptable
character under the terms of RFC 2821 then using it was a perfectly
reasonable decision.

Moreover, it is a decision with precedent. Gmail has been using + for aliases since long before Groups.io was started.

Shal

Folks,

The trouble is when it goes wrong, the effect can be somewhat devastating. When it happened on one of the lists I am on some very personal information about an individual that should not have been sent to the list was disclosed to the whole list....

Dave

On Thu, Sep 26, 2019 at 08:54 AM, Dave Wade wrote:

Folks,

The trouble is when it goes wrong, the effect can be somewhat devastating.
When it happened on one of the lists I am on some very personal information
about an individual that should not have been sent to the list was disclosed
to the whole list....

Dave

Thanks for that Dave! For the benefit of the others reading this, I believe Dave is referring to a group in which both Dave and I (and Chris) are members, and the individual in question was ME!

regards

On Thu, Sep 26, 2019 at 08:54 AM, Dave Wade wrote:

When it happened on one of the lists I am on some very personal information about an individual that should not have been sent to the list was disclosed to the whole list....

IMHO this is a very strong lever to try to get the service provider(s) to get their act in order; an address that was acceptably formatted was corrupted with the result that personal information sent in confidence was revealed to a large number of people.

If a service provider is allowed to get away with one corruption then there is no means of obtaining restitution if they suddenly come up with another one.

Chris

And also being on that group I have seen the offending message that
should have just been sent to owners. Some owner messages should never
be accidentally sent to the whole list.

As for gmail ignoring special characters like '.' I had an interesting
one involving this. A member has been subscribed for some time as
fxxxxn.wxxt@... and for some reason changed his email program to
use fxxxxnwxxt@... and wondered why he couldn't post to the list
with that address but could still receive OK. Gmail was ignoring the
'.' but groups.io was not.

Like Shal I am also a dinosaur who only uses real email on a real email
client. I absolutely hate web mail.

Dave

On 26 Sep 2019 at 1:10, Peter Martinez via Groups.Io wrote:

The trouble is when it goes wrong, the effect can be somewhat
devastating. When it happened on one of the lists I am on some very
personal information about an individual that should not have been
sent to the list was disclosed to the whole list....

Dave

Thanks for that Dave! For the benefit of the others reading this, I
believe Dave is referring to a group in which both Dave and I (and
Chris) are members, and the individual in question was ME!

http://davesergeant.com

Shal's reference to gmail using "+" in some way associated with aliases, is not consistent with the observation (by me and others) that gmail truncates leftsides at a "+" . An email to username+anytext@... is delivered to username@... and NOT rejected back to the sender as "No such user". The link Shal gave to a Gmail help page about aliases doesn't contain any reference to the "+" character..

Dave's reference to moderators "using this to chat to each other" is a reference to using the <groupname+owner@groups.io> address as a mini-group.

Peter

In my last message message, something or someone downstream of me replaced the word "gmail" after the @ symbol, by three dots,in two places, and that wrecked the meaning. Truncation of the user-part at the + sign only occurs WITHIN the gmail domain, not in ANY domain!

Peter

On Thu, Sep 26, 2019 at 09:23 AM, Dave Wade wrote:

I would however say that there may be a case for filing a GDPR failure against them

Which was the point I was making, albeit rather obliquely in my earlier post.

An email to the ICO (Information Commissioner for non - UK readers) might just stir things up a bit.

Chris.

Peter,

Shal's reference to gmail using "+" in some way associated with
aliases, is not consistent with the observation (by me and others)
that gmail truncates leftsides at a "+" . An email to
username+anytext@... is delivered to username@... and NOT
rejected back to the sender as "No such user".

That's exactly what Gmail means by an alias: username+foo is an alias for username. But it isn't stripped - the +foo part shows in the received message and is available for use in filter definitions (which is the intended use case).

The link Shal gave to a Gmail help page about aliases doesn't contain
any reference to the "+" character..

You need to open the expander titled "Filter using your Gmail alias".

Shal

Shal:

Understood now.

So if no aliases are defined and I send an email to <myname+sometext@...>, it will simply strip and discard "+sometext" (which is what I have seen), whereas if I define an alias as "myname+other", it will recognise an incoming email to <myname+other@... and process it as a valid address.

So I can indeed cite this when I talk to BT as a feature which the synchronoss/BT bug will break.

Peter

Peter,

So if no aliases are defined and I send an email to
<myname+sometext@...>, it will simply strip and discard
"+sometext" (which is what I have seen), whereas if I define an alias
as "myname+other", it will recognise an incoming email to
<myname+other@... and process it as a valid address.

Both cases are received by the same user account at gmail, whether an alias was predefined or not. The alias case simply allows the user to filter incoming messages based on the alias.

So I can indeed cite this when I talk to BT as a feature which the
synchronoss/BT bug will break.

Hopefully it will help you persuade them.

Shal