Lindsay Haisley writes:
> I posted code and patches earlier on this list, but the patch is against
> Mailman 2.1.15 rather than Mailman 3, which is the current development
> focus. I imagine it's rather different.
The code is organized quite differently, but I suspect that the
handler archite
On Wed, 2012-06-20 at 14:39 +0900, Stephen J. Turnbull wrote:
> Lindsay Haisley writes:
>
> > Any chance of requesting this in Mailman 3?
>
> As usual, the advice is to file a bug report/RFE on Launchpad, Mailman
> project, tag it Mailman 3 (or maybe that's milestone Mailman 3?)
>
> If you want
Lindsay Haisley writes:
> Any chance of requesting this in Mailman 3?
As usual, the advice is to file a bug report/RFE on Launchpad, Mailman
project, tag it Mailman 3 (or maybe that's milestone Mailman 3?)
If you want more discussion from the core people (well, Barry; Mark's
presumably already
On Tue, 2012-06-19 at 21:07 -0400, Dave (FitEyes) wrote:
>
>
> On Tue, Jun 19, 2012 at 8:55 PM, Lindsay Haisley
> wrote:
> On Tue, 2012-06-19 at 20:42 -0400, Dave (FitEyes) wrote:
> > It now seems pretty clear that we can use these reports in the way
> > Lindsay and othe
gene wrote:
>I have a lan with several machines on it. I've installed MM 2.1.14 on the
>unix host 'genesis' which also runs my apache server. In order to browse to
>genesis' web server from within the lan, I have to use something like:
> "http://genesis/mailman/listinfo";
>Using the fqdn (genesi
On Tue, Jun 19, 2012 at 8:55 PM, Lindsay Haisley wrote:
> On Tue, 2012-06-19 at 20:42 -0400, Dave (FitEyes) wrote:
> > Now that you motivated me, I actually read the blog post too:
> >
> http://postmaster-blog.aol.com/2008/08/13/more-on-the-upcoming-feedback-loop-conversion/
> >
> > It now seems p
On Tue, 2012-06-19 at 20:42 -0400, Dave (FitEyes) wrote:
> Now that you motivated me, I actually read the blog post too:
> http://postmaster-blog.aol.com/2008/08/13/more-on-the-upcoming-feedback-loop-conversion/
>
> It now seems pretty clear that we can use these reports in the way
> Lindsay and o
On Tue, Jun 19, 2012 at 8:17 PM, Russell Clemings wrote:
> I'm surprised to read in this thread that the terms of service for AOL's
> feedback loop forbid us from using its reports to identify users.
>
> The page where you sign up for the FBL seems to say just the opposite (end
> of third paragrap
I'm surprised to read in this thread that the terms of service for AOL's
feedback loop forbid us from using its reports to identify users.
The page where you sign up for the FBL seems to say just the opposite (end
of third paragraph):
"We suggest using opaque identifiers for the email recipient o
On Tue, Jun 19, 2012 at 6:51 PM, William Yardley
wrote:
> On Sat, Jun 16, 2012 at 11:58:46PM -0500, Lindsay Haisley wrote:
> > I have no idea why AOL wants to make it difficult for list
> > administrators to unsubscribe people who don't want to be subscribed
> > and who complain to AOL about list
On Tue, 2012-06-19 at 15:51 -0700, William Yardley wrote:
> I think the point of the
> FBL is more to alert you to problems on your network
What problems??? I'm running a collection of opt-in Mailman lists,
administered by FMP's customers. There are no problems.
> eYes, people will click the "r
On Sat, Jun 16, 2012 at 11:58:46PM -0500, Lindsay Haisley wrote:
> I have no idea why AOL wants to make it difficult for list
> administrators to unsubscribe people who don't want to be subscribed
> and who complain to AOL about list posts being spam.
To prevent listwashing or retaliation, for one
This has been a fascinating discussion that I've been enjoying very much.
However, one thing we need to remember is that we, as list administrators, usually (but not always)
have far greater insight than the average user into the realities of what spam is and what spam
isn't. Most of us underst
Lindsay Haisley writes:
> provided to properly unsubscribe from a list, so they just find all the
> list posts that they can and report them as spam, hoping that AOL will
> help them unsubscribe.
Which is exactly what AOL's feedback service is designed to
prevent. :-( More irony
The sad
Lindsay Haisley writes:
> Well the implementation I've developed for use with Resent-Message-ID
> incorporates a random factor into the AES encryption so that every
> encryption of the same address is different, although all decrypt
> properly using the key with which they were encrypted. Thi
Geoff Shang writes:
> > Ah, but we can just say "this allows us to VERP without exposing
> > addresses on anybody's disk; this helps protect your users' privacy."
>
> Oh the irony.
Thank you for noticing!
--
Mailman-Users mailing list Mailm
On Tue, 2012-06-19 at 15:05 -0400, David wrote:
> Furthermore, without exception on our list, when an AOL user triggers
> a feedback report, they do so on all the emails from our list that are
> currently in their inbox. There is zero content-specific selectivity.
> I've never seen it (on our list)
On Wed, 2012-06-20 at 03:30 +0900, Stephen J. Turnbull wrote:
> Lindsay Haisley writes:
>
> > EVERP = Encrypted VERP
>
> Ever heard of "Occam's Razor"?
Yes, I'm quite familiar with it :)
> Most folks who run Mailman lists can't
> expand "VERP", and wouldn't understand the expansion when told.
On Tue, Jun 19, 2012 at 4:17 AM, Stephen J. Turnbull wrote:
> David writes:
>
> > In terms of privacy, as list admins we already have the member's
> > information. All we are doing in this case is helping that member stop
> > receiving messages they obviously no longer wish to receive. This is
On Tue, 2012-06-19 at 17:17 +0900, Stephen J. Turnbull wrote:
> Nice try, but we still can't define AOL's policy for them. AOL's
> claim is that we need to fix our spam problem, not unsubscribe the
> member,
Isn't that the same thing? The object is to prevent the complaining
recipient from recei
On Wed, 20 Jun 2012, Stephen J. Turnbull wrote:
> >From a practical point of view my EVERP proposal may not be a good
> scheme for dealing with AOL's redaction policy in Email Feedback
> Reports. Although it would obviously fool the existing automated
> redaction process, a radical change to th
Lindsay Haisley writes:
> EVERP = Encrypted VERP
Ever heard of "Occam's Razor"? Most folks who run Mailman lists can't
expand "VERP", and wouldn't understand the expansion when told. It's
not obvious to me that practioners would get it right, either. Let's
not proliferate unnecessary acronyms
On Mon, 2012-06-18 at 13:23 -0700, Brad Knowles wrote:
> On Jun 18, 2012, at 12:06 PM, Larry Stone wrote:
>
> > And the problem that I'm trying to fix is that their user has
> >violated MY TOS regarding reporting list mail (that they subscribed
> >to) as spam. That AOL sent their Feedback Loop mes
On Tue, 2012-06-19 at 17:25 +0900, Stephen J. Turnbull wrote:
> Brad Knowles writes:
> > On Jun 18, 2012, at 11:44 AM, Lindsay Haisley wrote:
> >
> > > It might be very convenient to have what one might call EVERP, where the
> > > recipient address is encrypted into the envelope sender address
Hi All:
I have a lan with several machines on it. I've installed MM 2.1.14 on the
unix host 'genesis' which also runs my apache server. In order to browse to
genesis' web server from within the lan, I have to use something like:
"http://genesis/mailman/listinfo";
Using the fqdn (genesis.domain.n
I love a recursive solution. ;-}
Kirke Johnson Internet: kjohn...@pcc.edu
Email Administrator, TSS , Sylvania Campus
Portland Community College, Portland, OR, USA (971) 722-4368
On Mon, Jun 18, 2012 at 10:07 AM, Lindsay Haisley wrote:
> The irony is not lo
Brad Knowles writes:
> On Jun 18, 2012, at 11:44 AM, Lindsay Haisley wrote:
>
> > It might be very convenient to have what one might call EVERP, where the
> > recipient address is encrypted into the envelope sender address, as an
> > alternative choice to Mailman's VERP implementation.
It's
David writes:
> In terms of privacy, as list admins we already have the member's
> information. All we are doing in this case is helping that member stop
> receiving messages they obviously no longer wish to receive. This is
> clearly not an invasion of privacy (especially with a properly encr
28 matches
Mail list logo