-----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-----