Topics

moderated Messages to +owner being wrongly routed to the whole group


 

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


Peter Martinez <Peter.Martinez@...>
 

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,

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


Chris Jones
 

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 Martinez <Peter.Martinez@...>
 

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


Peter Martinez <Peter.Martinez@...>
 

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


Dave Sergeant
 

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


Dave Wade
 

Chris,

The problem is that the affected person may not be a user of the service that’s messed up. I would however say that there may be a case for filing a GDPR failure against them

Dave

 

From: main@beta.groups.io <main@beta.groups.io> On Behalf Of Chris Jones via Groups.Io
Sent: 26 September 2019 09:12
To: main@beta.groups.io
Subject: Re: [beta] Messages to +owner being wrongly routed to the whole group

 

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


Chris Jones
 

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


Peter Martinez <Peter.Martinez@...>
 

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


Dave Wade
 

Mark,

GMAIL also ignores “+” and almost all special symbols. (it didn’t used to), but if moderators, one of whom is on BTINTERNET try and use this to chat to each other , then the results are disastrous.

As for the web interface, well many people have a mobile phone as well which uses IMAP/SMPTP so perhaps not as rare as you think

Dave

 

From: main@beta.groups.io <main@beta.groups.io> On Behalf Of Mark Fletcher
Sent: 26 September 2019 01:07
To: main@beta.groups.io
Subject: Re: [beta] Messages to +owner being wrongly routed to the whole group

 

Late replying to this.

 

I'm wary (used it right this time Shal!) of changing this, especially to a period. It's not like periods aren't interpreted differently by different mail servers. Gmail, for example, ignores all periods in email addresses. Next time you send an email to a friend with a gmail account, feel free to sprinkle some periods in the left side of their email address. Note that we do not ignore periods, even for Gmail accounts. If I had to do it over, I'd probably special case this to handle it, but it seems to only confuse people a few times a year.

 

Mark


Dave Wade
 

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

-----Original Message-----
From: main@beta.groups.io <main@beta.groups.io> On Behalf Of Shal Farley
Sent: 26 September 2019 02:38
To: main@beta.groups.io
Subject: Re: [beta] Messages to +owner being wrongly routed to the whole
group

Mark,


I'm wary (used it right this time Shal!) of changing this, ...
Indeed. ;-)

I too do not favor changing it.

Or even aliasing it. I thought of that but realized it wouldn't solve the problem -
the people who need to use the alias wouldn't know about it. That way lies only
more confusion.

> If I had to do it over, I'd probably special case this to handle it, > but it seems
to only confuse people a few times a year.

I'm not sure what you're thinking, but I thought perhaps you could notice when
receiving a message:

IF (message delivered to Groups.io by btinternet.com) AND
(Received chain includes synchronoss.net) THEN
Do something different.

The question is what to do. I initially thought you could look to the header To
and/or Cc fields to determine if there was a command and what it was, but I
think some of the messages I looked at had neither.
Probably cases of Bcc, but I'm not sure about that.

So the only two actions I can think of would be to either force the message to
Pending, and let the mods deal with it, or reject the message, with a message
text saying that btinternet users must post via the web interface, not via SMTP
client applications.

But either of those are pretty onerous for the 99.9% use case of a simple
message posting. So maybe accept the message for posting if there is a To or
CC that includes the group posting address without command.

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


 

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 Jones
 

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


 

Peter,

Groups.io may be the only organisation that has chosen to embed a "+"
within leftsides of addresses within it's own domain, ...
Gmail is another.

It uses + in the user part as the lead-in for an alias address. That feature won't work properly with messages sent from a synchronoss afflicted service.

so we may get no support for any campaign to get it fixed properly.
You can add to your leverage by telling them that they're breaking a Gmail feature.
https://support.google.com/mail/answer/22370?hl=en
(the "Use Gmail aliases" section at the bottom of the page)

Shal


Dave Sergeant
 

Um, the idea of btinternet users only posting via the web interface is
surely a non starter. 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.

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

Dave

On 25 Sep 2019 at 18:38, Shal Farley wrote:

So the only two actions I can think of would be to either force the
message to Pending, and let the mods deal with it, or reject the
message, with a message text saying that btinternet users must post via
the web interface, not via SMTP client applications.

http://davesergeant.com


Peter Martinez <Peter.Martinez@...>
 

Mark/Shal:

The fact that gmail ignores dots in the leftside of email addresses, is not relevant to this discussion. Gmail ONLY do this on emails coming into the gmail domain, and that's reasonable. This practice doesn't affect emails going to any other domain.

We are talking here only about interpreting emails coming into the groups.io domain. The format of the leftside on such emails is entirely at the discretion of groups.io. If groups.io assign special meaning to a leftside with an embedded + or an embedded dot, that doesn't interact in any way with what gmail might do with their incoming emails.

The problem in this case is that we know there are en-route hosts that (illegally) truncate leftsides of emails in transit, treating a "+" as marking the end of the leftside. OK, the proper solution is to get these en-route hosts to cease this practice, but what we are discussing here now is the possibility that groups.io could do something to avoid this bug (because we have a very low expectation of getting it fixed properly). Groups.io may be the only organisation that has chosen to embed a "+" within leftsides of addresses within it's own domain, so we may get no support for any campaign to get it fixed properly.

It shouldn't be difficult to implement. Just amend the code that looks for a "+ so it will accept a dot as marking the start of a commandword. If there ARE presently leftsides assigned within @groups.io that contain embedded dots, then its not as simple, but Mark will know how to deal with that.

As a trial, you could just ADD a process to detect a dot AS WELL AS "+" in the part of the code that parses for email commands. We can then check that groupname(dot)command works and solves the problem and there are no unexpected side-effects. The rest of the users carry on as before. Then it's just a case of amending the documentation and waiting until there are no remaining users who remember the purpose of a "+", then quietly remove the "+" from the code.

Needless to say I AM progressing this problem with binternet. I have had a fault report reference number for a week now but no-one has come back to me yet ...

I don't like the idea of patching the groups.io server to detect "synchronoss" and/or "btinternet" within headers and attempt a kludge. This could cause no end of confusion if btinternet solve the problem at their end, or change to another subcontractor. They have only been using synchronoss for a couple of years. Prior to that they were using Critical Path. This change may have been the onset of this problem of course!

regards
Peter


 

Mark,


I'm wary (used it right this time Shal!) of changing this, ...
Indeed. ;-)

I too do not favor changing it.

Or even aliasing it. I thought of that but realized it wouldn't solve the problem - the people who need to use the alias wouldn't know about it. That way lies only more confusion.

If I had to do it over, I'd probably special case this to handle it,
but it seems to only confuse people a few times a year.
I'm not sure what you're thinking, but I thought perhaps you could notice when receiving a message:

IF (message delivered to Groups.io by btinternet.com) AND
(Received chain includes synchronoss.net)
THEN
Do something different.

The question is what to do. I initially thought you could look to the header To and/or Cc fields to determine if there was a command and what it was, but I think some of the messages I looked at had neither. Probably cases of Bcc, but I'm not sure about that.

So the only two actions I can think of would be to either force the message to Pending, and let the mods deal with it, or reject the message, with a message text saying that btinternet users must post via the web interface, not via SMTP client applications.

But either of those are pretty onerous for the 99.9% use case of a simple message posting. So maybe accept the message for posting if there is a To or CC that includes the group posting address without command.

Shal


 

Late replying to this.

I'm wary (used it right this time Shal!) of changing this, especially to a period. It's not like periods aren't interpreted differently by different mail servers. Gmail, for example, ignores all periods in email addresses. Next time you send an email to a friend with a gmail account, feel free to sprinkle some periods in the left side of their email address. Note that we do not ignore periods, even for Gmail accounts. If I had to do it over, I'd probably special case this to handle it, but it seems to only confuse people a few times a year.

Mark