----- Original Message -----

From: "Bill Cole" <mailmanu-20100705@billmail.scconsult.com>

It is altogether always wrong for ANY mail software outside of a domain to parse the local part of an address in that domain except for a tiny handful of standard special local parts (e.g. "postmaster"). The use of '+' as a tag delimiter is widespread but it is not in any sense a "standard" and comes nowhere near universality. There is no way for a Mailman instance to know which domains make "user+tag" and "user" equivalent and which do not, so canonicalizing as you suggest would result in breakage.

Noted. FWIW, in 30 years, I have not seen *any* use of the + sign in LHSs which did not appear on its face to be a plushack... though as you imply, I can't really tell for sure.

Beyond that risk of breakage, "canonicalizing" local parts which one does not own is wrong in principle: it violates the core assumption which makes Sendmail-style plus-tagging useful. The tagged address is supposed to be unique in the view of everyone except its owner and the owner's delivery agent, which can easily discern that an address is tagged (maybe with '+' but maybe not) and then handle the address and tag in whatever locally customized manner their whims dictate. Outside entities should never try to guess what those whims are at any particular time and more importantly should never translate an address from what it actually is to what their guesses about the owner's whims implies.

Ok, I guess I'll buy that. I appreciate you showing the work for me, Bill; I hadn't thought it all the way through.

Note: you might look at my address for this list and make any of a number of reasonable guesses about how its structure (which *IS* significant) relates to its delivery and handling. Most would be operationally wrong and none would be complete. I tag addresses in opaque ways precisely because of past rude & clueless attempts by others (mostly spammers) to break + tagging.

Heh.

Cheers, -- jra

Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

On 06/02/2013 08:50 AM, Tanstaafl wrote:

There is no reason that Mailman couldn't be enhanced with a configurable *option* that would allow the domain Admin to *tell* it which character(s) (there was recent talk on the postfix list of postfix being enhanced to allow multiple characters to be defined as this delimiter) were to be used as delimiters.

There is a huge difference between telling your local MTA that some character in the local part of an address is a delimiter and that it and what follows are not part of the address for user validation/delivery purposes, and guessing that the same thing might be true for some remote user's MTA.

I.e. no one without knowledge of the specific domain can know whether or not user@remote.example.com and user+extra@remote.example.com belong to the same person or even whether or not johndoe@remote.example.com and JohnDoe@remote.example.com belong to the same person.

Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address. RFC 5321, sec 2.3.11

I would love to see this ability in MM3...

The issue is moot in MM 3. There, users are distinct from their addresses. In one installation, a user may have several addresses, be an owner of a few lists, a member of a few lists, prefer delivery from list 1 to her user+list1@example.com address, prefer delivery from list 2 to her user+list2@example.com address and prefer delivery from list 3 to her othername@other.example.net address, and have her posts to any of the lists from any of the addresses be recognized as member posts.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 2013-06-02 2:45 PM, Bill Cole <mailmanu-20100705@billmail.scconsult.com> wrote:

Beyond a few formally standardized cases, assuming equivalency between different address local parts in a foreign domain is wrong in principle and bad in practice.

You (and Mark) are correct of course.

I only use Mailman for our local lists for our domain, where members are only our own users, so was thinking only in that context, which, of course, was wrong.

----- Original Message -----

From: "Bill Cole" <mailmanu-20100705@billmail.scconsult.com>

The original poster's difficulty was that MM did not see "user@domain" as a valid confirmer of a subscription by "user+tag@domain" but it would be profoundly wrong for MM to do so. Making MM recognize multiple tag delimiters would multiply the wrongness. The solution for that original problem is not in MM, it is for people using tagged addresses to have the right mix of tools and presence of mind to send mail using a suitable address for each message, i.e. if you subscribe to a MM list as "user+tag", you need to confirm the subscription from "user+tag", NOT "user".

In fact, I had no problem confirming, as I used the weblink. It was actual *posting* I could not then do.

There would be less of a problem with a subscriber-specific setting that would allow confirmed subscribers to tell MM that it should treat some pattern of tagged addresses as equivalent to their subscribed address. That would not address the OP's complaint, but it could help for people who are error-prone in how they send mail.

...

I would love to see this ability in MM3...

To solve what problem?

To solve the problem I initially queried about -- and I *did* query about it in sufficient detail, Bill, for you to not mischaracterize it here; he wants MM to recognize plushacked subscriptions for "can I post" purposes, as do I.

I abandoned simple tagging years ago precisely because of would-be mail wizards who thought it could be useful to programmatically de-tag my addresses, allowing them to intentionally override up my personal and domain-level mail handling. In place of the transparent "plus hack" I now have slightly more complexity in server config that buys me and my users safer tagging while occasionally dropping a wannabe deliverability wizard into a blackholed moat of his own digging. The feature you want to see in MM3 would probably make it easier for a clueless MM admin to do that without bad intent or even thought. There's a certain bofhly appeal to that, but I try not to let that side hold sway.

Very clever response, but I think it's a response to a "1% of 1%" problem, and thus not pertinent to this architectural problem.

To recap:

RFE: That mailman 3 permit users to specify that they subscribe with plus-hacked addresses (and optionally what delimiter character they use), for the purpose of poster-address validation on lists for which subscriber- only posting is enabled.

Cheers, -- jra

Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

----- Original Message -----

From: "Mark Sapiro" <mark@msapiro.net>

On 06/03/2013 10:23 AM, Jay Ashworth wrote:

...

RFE: That mailman 3 permit users to specify that they subscribe with plus-hacked addresses (and optionally what delimiter character they use), for the purpose of poster-address validation on lists for which subscriber- only posting is enabled.

As has been pointed out, MM 3 is different. Whereas, in MM 2.1 every email address on a list is a separate entity unrelated to any other on that list or other lists within that installation, MM 3 is different.

In an MM 3 installation, a person has a user record with multiple addresses and roles. See my post at <http://mail.python.org/pipermail/mailman-users/2013-June/075216.html>.

I think MM 3's design already satisfies your RFE. You would just add your un-plus-hacked address to your user record.

Yeah, I saw that after, and given that you only need to add the one extra address to cater for all the lists you might plushack separately, I guess it really does solve the problem.

A few grafs on this in the doco or on the wiki might not go amiss, unless I'm really the only person who's ever asked, in which case nevermind. :-)

Cheers, -- jra

Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

----- Original Message -----

From: "Tanstaafl" <tanstaafl@libertytrek.org>

...

The use of '+' as a tag delimiter is widespread but it is not in any sense a "standard" and comes nowhere near universality. There is no way for a Mailman instance to know which domains make "user+tag" and "user" equivalent and which do not, so canonicalizing as you suggest would result in breakage.

Currently factually and technically correct, But...

There is no reason that Mailman couldn't be enhanced with a configurable *option* that would allow the domain Admin to *tell* it which character(s) (there was recent talk on the postfix list of postfix being enhanced to allow multiple characters to be defined as this delimiter) were to be used as delimiters.

In fact, Bills response convinces me -- and I was the OP -- that in fact that's probably a bad idea: you're trying to make a decision ("does an address LHS with a plus sign denote a plushack") at a granularity where it's not valid.

You could do this in MM, but you would have to allow users to set it (likely, to enable it) at the user-subscription level, not the list or server levels. With that caveat, I'd vote for the RFE. :-)

Cheers, -- jra

Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

----- Original Message -----

From: "Bill Cole" <mailmanu-20100705@billmail.scconsult.com>

It is altogether always wrong for ANY mail software outside of a domain to parse the local part of an address in that domain except for a tiny handful of standard special local parts (e.g. "postmaster"). The use of '+' as a tag delimiter is widespread but it is not in any sense a "standard" and comes nowhere near universality. There is no way for a Mailman instance to know which domains make "user+tag" and "user" equivalent and which do not, so canonicalizing as you suggest would result in breakage.

Noted. FWIW, in 30 years, I have not seen *any* use of the + sign in LHSs which did not appear on its face to be a plushack... though as you imply, I can't really tell for sure.

Beyond that risk of breakage, "canonicalizing" local parts which one does not own is wrong in principle: it violates the core assumption which makes Sendmail-style plus-tagging useful. The tagged address is supposed to be unique in the view of everyone except its owner and the owner's delivery agent, which can easily discern that an address is tagged (maybe with '+' but maybe not) and then handle the address and tag in whatever locally customized manner their whims dictate. Outside entities should never try to guess what those whims are at any particular time and more importantly should never translate an address from what it actually is to what their guesses about the owner's whims implies.

Ok, I guess I'll buy that. I appreciate you showing the work for me, Bill; I hadn't thought it all the way through.

Note: you might look at my address for this list and make any of a number of reasonable guesses about how its structure (which *IS* significant) relates to its delivery and handling. Most would be operationally wrong and none would be complete. I tag addresses in opaque ways precisely because of past rude & clueless attempts by others (mostly spammers) to break + tagging.

Heh.

Cheers, -- jra

Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

On 06/02/2013 08:50 AM, Tanstaafl wrote:

There is no reason that Mailman couldn't be enhanced with a configurable *option* that would allow the domain Admin to *tell* it which character(s) (there was recent talk on the postfix list of postfix being enhanced to allow multiple characters to be defined as this delimiter) were to be used as delimiters.

There is a huge difference between telling your local MTA that some character in the local part of an address is a delimiter and that it and what follows are not part of the address for user validation/delivery purposes, and guessing that the same thing might be true for some remote user's MTA.

I.e. no one without knowledge of the specific domain can know whether or not user@remote.example.com and user+extra@remote.example.com belong to the same person or even whether or not johndoe@remote.example.com and JohnDoe@remote.example.com belong to the same person.

Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address. RFC 5321, sec 2.3.11

I would love to see this ability in MM3...

The issue is moot in MM 3. There, users are distinct from their addresses. In one installation, a user may have several addresses, be an owner of a few lists, a member of a few lists, prefer delivery from list 1 to her user+list1@example.com address, prefer delivery from list 2 to her user+list2@example.com address and prefer delivery from list 3 to her othername@other.example.net address, and have her posts to any of the lists from any of the addresses be recognized as member posts.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 2013-06-02 2:45 PM, Bill Cole <mailmanu-20100705@billmail.scconsult.com> wrote:

Beyond a few formally standardized cases, assuming equivalency between different address local parts in a foreign domain is wrong in principle and bad in practice.

You (and Mark) are correct of course.

I only use Mailman for our local lists for our domain, where members are only our own users, so was thinking only in that context, which, of course, was wrong.

----- Original Message -----

From: "Bill Cole" <mailmanu-20100705@billmail.scconsult.com>

The original poster's difficulty was that MM did not see "user@domain" as a valid confirmer of a subscription by "user+tag@domain" but it would be profoundly wrong for MM to do so. Making MM recognize multiple tag delimiters would multiply the wrongness. The solution for that original problem is not in MM, it is for people using tagged addresses to have the right mix of tools and presence of mind to send mail using a suitable address for each message, i.e. if you subscribe to a MM list as "user+tag", you need to confirm the subscription from "user+tag", NOT "user".

In fact, I had no problem confirming, as I used the weblink. It was actual *posting* I could not then do.

There would be less of a problem with a subscriber-specific setting that would allow confirmed subscribers to tell MM that it should treat some pattern of tagged addresses as equivalent to their subscribed address. That would not address the OP's complaint, but it could help for people who are error-prone in how they send mail.

...

I would love to see this ability in MM3...

To solve what problem?

To solve the problem I initially queried about -- and I *did* query about it in sufficient detail, Bill, for you to not mischaracterize it here; he wants MM to recognize plushacked subscriptions for "can I post" purposes, as do I.

I abandoned simple tagging years ago precisely because of would-be mail wizards who thought it could be useful to programmatically de-tag my addresses, allowing them to intentionally override up my personal and domain-level mail handling. In place of the transparent "plus hack" I now have slightly more complexity in server config that buys me and my users safer tagging while occasionally dropping a wannabe deliverability wizard into a blackholed moat of his own digging. The feature you want to see in MM3 would probably make it easier for a clueless MM admin to do that without bad intent or even thought. There's a certain bofhly appeal to that, but I try not to let that side hold sway.

Very clever response, but I think it's a response to a "1% of 1%" problem, and thus not pertinent to this architectural problem.

To recap:

RFE: That mailman 3 permit users to specify that they subscribe with plus-hacked addresses (and optionally what delimiter character they use), for the purpose of poster-address validation on lists for which subscriber- only posting is enabled.

Cheers, -- jra

Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

----- Original Message -----

From: "Mark Sapiro" <mark@msapiro.net>

On 06/03/2013 10:23 AM, Jay Ashworth wrote:

...

RFE: That mailman 3 permit users to specify that they subscribe with plus-hacked addresses (and optionally what delimiter character they use), for the purpose of poster-address validation on lists for which subscriber- only posting is enabled.

As has been pointed out, MM 3 is different. Whereas, in MM 2.1 every email address on a list is a separate entity unrelated to any other on that list or other lists within that installation, MM 3 is different.

In an MM 3 installation, a person has a user record with multiple addresses and roles. See my post at <http://mail.python.org/pipermail/mailman-users/2013-June/075216.html>.

I think MM 3's design already satisfies your RFE. You would just add your un-plus-hacked address to your user record.

Yeah, I saw that after, and given that you only need to add the one extra address to cater for all the lists you might plushack separately, I guess it really does solve the problem.

A few grafs on this in the doco or on the wiki might not go amiss, unless I'm really the only person who's ever asked, in which case nevermind. :-)

Cheers, -- jra

Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

----- Original Message -----

From: "Tanstaafl" <tanstaafl@libertytrek.org>

...

The use of '+' as a tag delimiter is widespread but it is not in any sense a "standard" and comes nowhere near universality. There is no way for a Mailman instance to know which domains make "user+tag" and "user" equivalent and which do not, so canonicalizing as you suggest would result in breakage.

Currently factually and technically correct, But...

There is no reason that Mailman couldn't be enhanced with a configurable *option* that would allow the domain Admin to *tell* it which character(s) (there was recent talk on the postfix list of postfix being enhanced to allow multiple characters to be defined as this delimiter) were to be used as delimiters.

In fact, Bills response convinces me -- and I was the OP -- that in fact that's probably a bad idea: you're trying to make a decision ("does an address LHS with a plus sign denote a plushack") at a granularity where it's not valid.

You could do this in MM, but you would have to allow users to set it (likely, to enable it) at the user-subscription level, not the list or server levels. With that caveat, I'd vote for the RFE. :-)

Cheers, -- jra

Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274