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