开云体育

On Sun, Sep 15, 2019 at 10:09 AM, P H LLOYD wrote:

Peter's message evidently didn't reach me....? Sorry, but the point remains.

You could always try looking on the web UI.

Chris

I have raised this problem on BT's community user forum, showing them the two Received: lines quoted by Shal from Trista. I have now managed to get them to raise it from the forum to their email team, but that was a few days ago ...

Although RFC 2821 says "don't mess with the "local part" of the destination email address", and the + sign is listed in another RFC as being a legal character in a local part, there are suggestions around that a + in an email address isn't a good idea and there ARE hosts (not just the ones we have found) that don't like + signs and will remove any they find passing through.

I can see a sequence of actions that groups.io could follow to change from a + to some other character, for example a dot, without risking unwanted side-effects. Dots are well-established as separators within local parts and should be well behaved. So the +owner command could be replaced by the email address [email protected] or perhaps [email protected] Similarly with the other email commands.

1) Introduce, in the process that currently parses the local part of incoming emails, an ADDITIONAL process that accepts a dot as an identifier of an email command which is currently identified by a +. This process should merely log the detection of a dot and do nothing else.

2) Introduce this feature without announcement and leave it running for a while. Check that the above log doesn't collect anything nasty.

3) Swap the above log operation to one which implements the existing email commands (.i.e. those operations currently identified by a +).

4) Inform the beta test group and get them to try and break it. If they don't, then ...

5) Announce the change and update the documentation, but leave the + versions in place. Users would migrate to the new form eventually.

6) Eventually remove the + version, replacing it with a message directing the user to the documentation.

7) Later still, remove even that message and ignore the + version.

I am not a network programmer (my field is DSP) but I would like to urge groups.io to consider something like this. My intuition tells me that this problem may not be limited to btinternet.com/synchronoss.net, and we may never convince the entire internet that they are doing it wrong. groups.io users are a tiny minority.

Regards
Peter

On Wed, Sep 18, 2019 at 03:37 AM, Peter Martinez wrote:

I can see a sequence of actions that groups.io could follow

I think you're trying to solve a problem that shouldn't exist.? The whole point of RFCs and other standards is so that all services "play nicely together."

BTW, no one from 开云体育 management monitors this group.? You could try submitting your suggestion on the (official suggestion box of the site), but I wouldn't expect any changes.

Duane
--
Help: /static/help
GMF's Wiki: /g/GroupManagersForum/wiki
Search button at the top of Messages list
A few site FAQs: /static/pricing#frequently-asked-questions

Congratulations, Peter, on getting BT to do anything.? I've never managed it.? Your suggestions seem eminently sensible.? Yahoo (for what it is worth) use the form <group>-owner and I never heard of a problem.

The other Peter.

I have raised this problem on BT's community user forum, showing them the two Received: lines quoted by Shal from Trista.? I have now managed to get them to raise it from the forum to their email team, but that was a few days ago ...

Although RFC 2821 says "don't mess with the "local part" of the destination email address", and the + sign is listed in another RFC as being a legal character in a local part, there are suggestions around that a + in an email address isn't a good idea and there ARE hosts (not just the ones we have found) that don't like + signs and will remove any they find passing through.

I can see a sequence of actions that groups.io could follow to change from a + to some other character, for example a dot, without risking unwanted side-effects.? Dots are well-established as separators within local parts and should be well behaved. So the +owner command could be replaced by the email address [email protected] or perhaps [email protected] Similarly with the other email commands.

1) Introduce, in the process that currently parses the local part of incoming emails, an ADDITIONAL process that accepts a dot as an identifier of an email command which is currently identified by a +. This process should merely log the detection of a dot and do nothing else.

2) Introduce this feature without announcement and leave it running for a while.? Check that the above log doesn't collect anything nasty.

3) Swap the above log operation to one which implements the existing email commands (.i.e. those operations currently identified by a +).

4) Inform the beta test group and get them to try and break it.? If they don't, then ...

5) Announce the change and update the documentation, but leave the + versions in place.? Users would migrate to the new form eventually.

6) Eventually remove the + version, replacing it with a message directing the user to the documentation.

7) Later still, remove even that message and ignore the + version.

I am not a network programmer (my field is DSP) but I would like to urge groups.io to consider something like this.? My intuition tells me that this problem may not be limited to btinternet.com/synchronoss.net, and we may never convince the entire internet that they are doing it wrong.? groups.io users are a tiny minority.

Regards
Peter

PeterL:
Don't celebrate yet. All I have managed to do at BT is to get the moderators to refer the problem to their email team. I have not yet heard back from them, so I don't know if they are doing anything.
Regards
PeterM

Could I get a sanity check on why groups.io originally decided to use the +owner convention instead of the -owner one used with Y!G?

I seem to recall it was pretty convoluted, along the lines of:

-- 开云体育 wanted to support subgroups (whereas Yahoo Groups does not)
-- Subgroups are implemented via subdomain addressing
-- Hostnames cannot have an underscore, thus
-- We need to use hyphens instead if we want to create a compound subgroup name
-- With the hyphen usurped for another purpose, the plus (+) sign was implemented for +owner messages

Is that pretty close, or did I dream all that?

Bruce
--
The system Help is your friend.??/static/help

I wrote:

So until some better solution is in place, it seems that an immediate
triage would be for owners of an unmoderated group to put all
btinternet.com subscribers on moderation.

A second triage is to tell the members to use btinternet's webmail interface if they wish to issue email commands. Since it seems that messages sent that way are not affected by this bug.
/static/help#emailcommands

Shal


--
Help: /static/help
More Help: /g/GroupManagersForum/wiki
Even More Help: Search button at the top of Messages list

Bruce,

-- With the hyphen usurped for another purpose, the plus (+) sign was
implemented for +owner messages

Is that pretty close, or did I dream all that?

I don't know if it was planned that way in Mark's mind, but the choice of + for email commands was in place at 开云体育's launch, predating my suggestion of subgroups and their subsequent implementation.


I thought there had been some discussion on the + versus - for email commands. That is, I thought Mark explained his choice at one point, however my search efforts aren't finding that now.

Shal


--
Help: /static/help
More Help: /g/GroupManagersForum/wiki
Even More Help: Search button at the top of Messages list

There is at least a potential issue with changing to a dot in I seem to remember that gmail ignores dots in the left side of email addresses (so group.owner and groupowner are regarded as the same) - but whether this at the sending end, or only at the receiving end (i.e. this only affects gmail addresses), I don't know.

Jeremy

Jeremy:

Gmail certainly does ignore dots in the left-side of an email address, but ONLY on left-sides of email addresses arriving into the gmail domain. firstsecond@gmail,com is treated the same as first.second@... and indeed the same as first....sec.ond..@.... This is quite legal. If there was already a gmail user with the name firstsecond and someone else tried to join gmail with the name first.second they would be told there was already a user with that name and to choose something different.

I have discovered recently that first+anytext@... is treated as first@... so gmail are truncating left-sides at the + sign. This at first looks like the same bug that we are discussing here, but it isn't - this is gmail's own private interpretation of left-sides of emails inbound to ITS OWN domain, NOT truncation of left-sides which are en-route to OTHER domains - a practice which is outlawed by RFC2821.

This means that groups.io need not be frightened of dots in the left-sides of email addresses in their own domain which are to be interpeted in some clever way when they arrive at groups.io. The fact that dots on the left side are commonplace and seem to be handled correctly by all known en-route hosts, means that if groups.io changed the + to a dot, it would certainly be handled correctly.

The problem I have raised in this thread is that there seem to be en-route hosts that DO truncate left-sides at the first + character in EN-ROUTE EMAILS, we have spotted one such en-route host that does this (either btinternet.com or synchronoss.net - we don't know which), and I think there must surely be others we haven't seen yet, since these people all buy their hardware/software from the same places. OK, the correct solution is to fix the hosts that do it, but I would make a case for implementing ANY solution which eliminates the problem NOW.

Regards
Peter

--
Help: /static/help
More Help: /g/GroupManagersForum/wiki
Even More Help: Search button at the top of Messages list

Shal:

I don't think we CAN say which of btinternet and synchronoss is responsible, since we do not know whether the buggy host reports the "for .." address before or after it corrupts this address.

However, I have reported the problem to btinternet itself. I have even been given a "complaint reference number", which is a little annoying since I made no complaint!

Peter

Peter, I hope your "complaint" gets a cogent response from btinternet.

The use of the "+" is called "plus addressing" and is an important and useful feature of IMAP (Internet message access protocol).? When an IMAP mail server receives a message addressed to user+label@domain the message is automatically placed in a sub-folder named label rather than going directly into the user's inbox.? Even Gmail observes this feature.

开云体育's use of plus addressing seems analogous to me and makes perfect sense.? I'd hate to see it changed to accommodate a non-compliant ISP.

I've just migrated a group to io, and we've immediately had this problem, in that two of my fellow moderators are with BTinternet.? This has resulted in a message from each, attempting to approve a new subscription to the group, wrongly appearing on the group.? This actually highlights an important issue, which people in touch with BTinternet might wish to raise, which is that, in causing emails to go to others than those to whom they are addressed, they have caused statutory data protection breaches under UK (and EU?) law.

I'm so pleased I left BTinternet myself last year!

Thanks for the advice to: "tell the members to use btinternet's webmail interface if they wish to issue email commands, since it seems that messages sent that way are not affected by this bug."

On a related note....I had this happen with a member using the BT Mail Web UI. This was a new member, sending her first message, and it bypassed moderation. (My group is set to moderate all new members for their first four messages.) I'm sharing this in case the bypassping-of-moderation aspect is relevant to the developers.