I just subscribed to the virtualgl-users list at SF, and I subscribed with a plushacked email address, jra+vgl@
Got the confirmation email ok, of course, but when I tried to send something, it bounced "because I'm not subscribed to the list". I've never had that happen before, but it's possible that I've never tried to sub a plushack address to a Mailman list.
Does Mailman in fact not understand plushacked addresses as subscription addresses, and that it should canonicalize them when a) checking for duplicate subscriptions and b) accepting messages for restricted lists?
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 05/30/2013 11:30 AM, Jay Ashworth wrote:
I just subscribed to the virtualgl-users list at SF, and I subscribed with a plushacked email address, jra+vgl@
Which is fine, but then that address is the member and that's the address you need to post from. Mailman doesn't understand that jra+vgl@... and jra@... MAY be the same address (that actually depends on your MTA/MDA).
If you want to be able to post from jra@..., subscribe it too, set it to no mail and maybe turn off its password reminders.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 30 May 2013, at 14:30, Jay Ashworth wrote:
I just subscribed to the virtualgl-users list at SF, and I subscribed with a plushacked email address, jra+vgl@
Got the confirmation email ok, of course, but when I tried to send something, it bounced "because I'm not subscribed to the list". I've never had that happen before, but it's possible that I've never tried to sub a plushack address to a Mailman list.
Does Mailman in fact not understand plushacked addresses as subscription addresses, and that it should canonicalize them when a) checking for duplicate subscriptions and b) accepting messages for restricted lists?
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.
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.
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.
----- 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 2013-06-01 1:40 PM, Bill Cole wrote:
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").
On it's own, I agree.
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.
I would love to see this ability in MM3...
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 2 Jun 2013, at 11:50, Tanstaafl wrote:
On 2013-06-01 1:40 PM, Bill Cole wrote:
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").
On it's own, I agree.
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.
There's no reason MM *couldn't* be "enhanced" in many ways that it never *should* be. It's reasonably well-structured open source Python after all...
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. Postfix's recipient_delimiter has nothing to do with foreign domain addresses, it is only relevant to addresses in domains for which Postfix handles delivery. It is also worth noting one thing mentioned in that thread: it is trivial to replicate the functionality of having multiple delimiter characters with regular expression alias maps.
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".
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?
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.
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.
On Jun 02, 2013, at 02:45 PM, Bill Cole 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's no reason MM *couldn't* be "enhanced" in many ways that it never *should* be. It's reasonably well-structured open source Python after all...
Mailman can't really trust any email address it can't verify, even on an admin's say so. But it will be easier to manage multiple specific addresses in Mailman 3 so you should be able to register (and verify) any number of extended addresses you want.
-Barry
----- 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
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.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
----- 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
Jay Ashworth writes:
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. :-)
I still don't understand what you're asking for, unless it's
""" Mailman subscribes *exactly* the address you give it. In tests based on list membership, it will do a case-insensitive comparison on the domain, and a case-sensitive comparison on the local-part. Mailman does not know or care about variations like mail subdomains or the "plus hack". If you want Mailman to know about such variations, you will need to subscribe them to each relevant list (Mailman 2), or do something-we-don't-exactly-know-yet-but-IMHO-probably-will-be- almost-as-inconvenient (Mailman 3).[1] """
We could go on to say
""" Mailman *can't* be "plushack aware", because there's no standard for using it and there are common use cases with completely incompatible semantics. Some people have a "misc content" address and "specific topic" addresses, and use the plus hack to enable their MDA to sort by content into topic folders. Others have a real address and use the plus hack to provide fake addresses to identify which of their correspondents have been harvested by spammers and/or use reply-to-all. And then there are the sociopaths who use TMDA.
The only way to allow such a wide variety of use cases is for the user to explicitly specify which addresses are allowed to post and which receive mail, and that's already possible, at the reasonable cost of an extra subscription set to no-mail (unless you use runtime-generated plushack addresses like TMDA). """
but I think that's excessively technical.
Footnotes: [1] As Mark says, MM 3 will have Users, but I personally do not want all the addresses I use allowed to post to all the lists I subscribe to. So I'll still have to flip the toggle list-by-list, even on the same Mailman installation in some cases. I suspect without data that this is actually the common case.
----- 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
participants (6)
-
Barry Warsaw -
Bill Cole -
Jay Ashworth -
Mark Sapiro -
Stephen J. Turnbull -
Tanstaafl