Re: [Mailman-Users] Custom Pages

2013-06-02 Thread Janice Boothe


--- On Fri, 5/31/13, Mark Sapiro m...@msapiro.net wrote:


: Yes I do mean that.  I used confirm.html since that is the naming
: convention used to create custom pages for much of the other IO of:
: Mailman.
:
:Some of Mailman's GUI web pages are built from templates such as
:listinfo.html, options.html and subscribe.html. Many others including
:the entire web admin interface and much of the admindb interface are not.

I understand this.  It is the basis for teh discussion!  :)


: It seems rather odd and extremely limiting that Mailman functiuons as
: you describe in regards to confirm.  Most of the other pages are
: customizable (listinfo, etc), why in the world would the programmers
: make such a choice to not allow site owners to customize the confirm
: page?
:
:This wasn't as much of an issue when Mailman 2 was designed.

OK


: Is this something that can be fixed in future releases as it
: should not be very hard to do?
:
:Well, I don't know about 'hard' but it won't happen in Mailman 2.1 for
:several reasons having mostly to do with i18n considerations and the
:fact that were it to be done, I'm the one who would do it with whatever
:help I could scrounge from the community.

Maybe because I am not fully aware of il8n but I fail to see how that is an 
issue.  I know fo other software that uses end user selectable language sets 
and is highly customizable.  Also the fact that a lot of the rest of MM uses 
templates kind of points to the possibility that the rest ought to be able to 
as well.


:On the other hand, Mailman 3 is a different story. In MM 3 the core
:mailing list functions communicate with the outside via a REST API.
:Anyone is free to develop whatever web UI they want to communicate with
:the core. The web UI that will ship with MM 3 is Postorius
:https://launchpad.net/postorius and I think you'll find it much more
:template driven than the MM 2 UI.

I'll have to wit until the good folks at cpanel add MM3 before I can start 
using that.. :(


BTW thank for the work on this.  I am not trying to kick your cat here at all, 
merely sending in feedback on how to improve the product.
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org


Re: [Mailman-Users] Is Mailman 2.1 not plushack aware?

2013-06-02 Thread Tanstaafl

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...
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org


Re: [Mailman-Users] Custom Pages

2013-06-02 Thread Steve Burling
On Jun 2, 2013, at 11:23 AM, Janice Boothe nursejan...@yahoo.com wrote:

 Maybe because I am not fully aware of il8n but I fail to see how that is an 
 issue.  I know fo other software that uses end user selectable language sets 
 and is highly customizable.  Also the fact that a lot of the rest of MM uses 
 templates kind of points to the possibility that the rest ought to be able to 
 as well.

It's open-source software; grab a copy, and start working!
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org


Re: [Mailman-Users] Custom Pages

2013-06-02 Thread Mark Sapiro
On 06/02/2013 08:23 AM, Janice Boothe wrote:
 
 
 Maybe because I am not fully aware of il8n but I fail to see how that is an 
 issue.


Mailman 2.1.15 supports 37 non-English translations. Mailman 2.1.16 will
add Farsi to the list. Even assuming that switching to a template
doesn't add or change any strings in the message catalog, any new
template needs to be translated into 38 other languages. The users of a
language for which the template has not been translated see a page built
from the English template.

Thus, switching to a new template breaks that page for those users who
prefer one of the 38 non-English languages until the template is
translated into their language.

My experience tells me that this translation will happen in timely
fashion for at most 5 of the 38 languages leaving users of the other 33
or more languages with a page they may not be able to read.

This may not be an issue for you, but it is for me.

-- 
Mark Sapiro m...@msapiro.netThe highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org


Re: [Mailman-Users] Is Mailman 2.1 not plushack aware?

2013-06-02 Thread Mark Sapiro
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 u...@remote.example.com and user+ex...@remote.example.com belong to
the same person or even whether or not john...@remote.example.com and
john...@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+li...@example.com address, prefer delivery from list 2 to
her user+li...@example.com address and prefer delivery from list 3 to
her othern...@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 m...@msapiro.netThe highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org


Re: [Mailman-Users] Is Mailman 2.1 not plushack aware?

2013-06-02 Thread Bill Cole

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.

--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org


Re: [Mailman-Users] Is Mailman 2.1 not plushack aware?

2013-06-02 Thread Tanstaafl
On 2013-06-02 2:45 PM, Bill Cole 
mailmanu-20100...@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.

--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org


Re: [Mailman-Users] Is Mailman 2.1 not plushack aware?

2013-06-02 Thread Barry Warsaw
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
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org