-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Mark,
On Feb 8, 2009, at 6:49 PM, Mark Sapiro wrote:
Barry Warsaw wrote:
Does anybody set USE_ENVELOPE_SENDER to Yes these days?
There are potential issues with this with umbrella lists. Perhaps
Mailman 3 will handle these differently, but here is the issue.
MM3 should implement the functionality of umbrella lists quite
differently. My plan is to use roster composition instead.
There are two message methods, get_sender() and get_senders().
USE_ENVELOPE_SENDER only affects get_sender(). With
USE_ENVELOPE_SENDER false, get_sender() returns the first address
found in From:, Sender: and unixfrom (envelope sender). With
USE_ENVELOPE_SENDER true, the order is Sender:, From: and unixfrom, so
it doesn't even really do what it claims.
Indeed. Strike one!
BTW, I am thinking about replacing get_sender() with a `sender`
attribute, which would return the first non-false value from the
`senders` attribute. This latter is the new get_senders(). `senders`
takes its cue from a configurable list of headers (which can include
the envelope sender) and simply returns a list of all the email
addresses found in the specified headers.
The potential issue is if you want posts to the umbrella list to be
accepted by the child lists without being held, one technique is to
put the umbrella's listname-bounces address in accept_these_nonmembers
of the children, and this requires USE_ENVELOPE_SENDER to be true in
order to work.
Yep. It's very unfortunate that USE_ENVELOPE_SENDER is a system-wide
configuration. Strike two!
I agree that the use of USE_ENVELOPE_SENDER as an anti-spoof is
outdated, particularly because it doesn't even come into play for the
member/nonmember decision.
Strike three. :)
BTW, the default value is No, which tells Mailman to use the From:
header first. I propose hardwiring that default value.
Let me know if this would cause you pain.
I think it will impact some users with umbrella lists depending on how
(or if) umbrella lists are handled in Mailman 3.
Cool, thanks for this message. The use case of composite mailing
lists is an important driver for separating out the concept of a
roster in MM3, and I expect that we'll have direct support for this
without all the nasty workarounds or problems described in the FAQ.
It's not there yet, but it is planned, and shouldn't need to rely on
the envelope sender for posting permissions and such.
Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkmPdF8ACgkQ2YZpQepbvXEkrwCfYHJQjoWAN0GFNTkCi1da+TR7
IZUAn1oyosfUFg0e4GZkNwGRKsovclIn
=/ls6
-----END PGP SIGNATURE-----
------------------------------------------------------
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9