subject:"\[Mailman\-Users\] AOL redacts user addresses even with VERP and full personalization enabled"

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 more discussion from the core people (well, Barry; Mark's
 presumably already said everything he wants to say about this subject
 :-), you could send mail to mailman-developers, but I think this idea
 is already pretty well-baked, and maybe you even have a patch you
 could attach to the issue?

I was thinking of posting to the dev list, to which I also subscribe,
and inquiring with regard to the advisability of putting this, as you
suggested, into the Resent-Message-ID header, as opposed to the VERP
address or some custom header.

My thinking, from corresponding with Dave and my own observation, is
that both the list address and the recipient address should be AES
encrypted and passed in a single header, and because this information is
pretty much guaranteed to be unique per message, given that my AES
encryption routine uses random input, using the Resent-Message-ID header
would fulfill a dual purpose and satisfy RFC 2822.  The use of this
header would depend on whether the current v3 development blueprint has
plans for this header which would preempt its use for this purpose.

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.  I'd have to take a look at the
code and figure out where the patch might go.

I'm also not up on what the execution time hit would be in generating a
short AES cipher for each outgoing message.  This might be considerable
on a large list with many thousands of subscribers.  As it is now, in my
patch, if VERP is not enabled, or there is no personalization, which I
believe excludes VERP, then no encrypted recipient cipher would be
generated.

When I get a chance I'll take a look at the v3 code.


--
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] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-20 Thread Stephen J. Turnbull

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 architecture will look familiar to you.
--
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] AOL redacts user addresses even with VERP and full personalization enabled

On Tue, 2012-06-19 at 14:48 -0500, Mike Starr wrote:
 Many of the mailman cognoscenti are highly skilled technical folks
 with little respect (and often little tolerance) for clueless users.
 Sometimes you just have to choke back the bile and lovingly correct
 those who have less understanding.

On the lists which I administer myself I try to make the unsubscribe
process very easy and transparent.  Every user who tries,
unsuccessfully, to unsubscribe is sent the following clear and
unambiguous message with easy-to-follow instructions:

On Sat, Jan 31, 2009 at 11:18 PM, Mary Fireman maryj...@fortuitus.net
wrote:
unsubscribe

Hmph.  You can't get out that easy.

Please Note:  In some later model unsubscribe kits, the OFF indicator
has been replaced by POWER-UP STANDBY ENABLE.  Accordingly the ON
indicator has been replaced by the much clearer, POWER-DOWN STANDBY
ENABLE.  Contact your internet service provider for a list of affected
model numbers.  An ON-OFF retrofit panel kit is available for those
who have difficulty with the new and much clearer labeling.

First, ask your Internet Provider to mail you an Unsubscribing Kit. Then
follow these directions. The kit will most likely be the standard
no-fault type. Depending on requirements, System A and/or System B can
be used. When operating System A, depress lever and a plastic dalkron
unsubscriber will be dispensed through the slot immediately underneath.
When you have fastened the adhesive lip, attach connection marked by the
large X outlet hose. Twist the silver-coloured ring one inch below 
the connection point until you feel it lock.

The kit is now ready for use. The Cin-Eliminator is activated by the
small switch on the lip. When securing, twist the ring back to its
initial condition, so that the two orange lines meet. Disconnect. Place
the dalkron unsubscriber in the vacuum receptacle to the rear. Activate
by pressing the blue button.

The controls for System B are located on the opposite side. The red
release switch places the Cin-Eliminator into position; it can be
adjusted manually up or down by pressing the blue manual release button.
The opening is self-adjusting. To secure after use, press the green
button, which simultaneously activates the evaporator and returns the
Cin-Eliminator to its storage position.

You may log off if the green exit light is on over the evaporator . If
the red light is illuminated, one of the Cin-Eliminator requirements has
not been properly implemented. Press the List Guy call button on the
right of the evaporator . He will secure all facilities from his control
panel.

To use the Auto-Unsub, first undress and place all your clothes in the
clothes rack. Put on the velcro slippers located in the cabinet
immediately below. Enter the shower, taking the entire kit with you. On
the control panel to your upper right upon entering you will see a
Shower seal button. Press to activate. A green light will then be 
illuminated immediately below. On the intensity knob, select the desired
setting. Now depress the Auto-Unsub activation lever. Bathe normally.

The Auto-Unsub will automatically go off after three minutes unless you
activate the Manual off override switch by flipping it up. When you
are ready to leave, press the blue Shower seal release button. The
door will open and you may leave. Please remove the velcro slippers and
place them in their container.

If you prefer the ultrasonic log-off mode, press the indicated blue
button. When the twin panels open, pull forward by rings A  B. The knob
to the left, just below the blue light, has three settings, low, medium
or high. For normal use, the medium setting is suggested.

After these settings have been made, you can activate the device by
switching to the ON position the clearly marked red switch. If during
the unsubscribing operation, you wish to change the settings, place the
manual off override switch in the OFF position. You may now make the
change and repeat the cycle. When the green exit light goes on, you may
log off and have lunch. Please close the door behind you.


Occam's Razor strikes again!!


-- 
Lindsay Haisley   | Everything works if you let it
FMP Computer Services |
512-259-1190  |  --- The Roadie
http://www.fmp.com|

--
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] AOL redacts user addresses even with VERP and full personalization enabled

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 others have proposed.
 
Well if this is so, are they still redacting the VERP recipient
addresses?

-- 
Lindsay Haisley   |  We are all broken toasters, but we still
FMP Computer Services |manage to make toast
512-259-1190  |
http://www.fmp.com|- Cheryl Dehut

--
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] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-20 Thread Mike Starr


Ah, if only I could write documentation as clear as that!

Best regards,

Mike
--
Mike Starr WriteStarr Information Services
Technical Writer   -Online Help Developer   -   WordPress Websites
Graphic Designer - Desktop Publisher - Custom Microsoft Word templates
(262) 694-1028   -  m...@writestarr.com   -  http://www.writestarr.com
President, Working Writers of Wisconsin http://www.workingwriters.org/


On 6/19/2012 4:23 PM, Lindsay Haisley wrote:

On Tue, 2012-06-19 at 14:48 -0500, Mike Starr wrote:

Many of the mailman cognoscenti are highly skilled technical folks
with little respect (and often little tolerance) for clueless users.
Sometimes you just have to choke back the bile and lovingly correct
those who have less understanding.


On the lists which I administer myself I try to make the unsubscribe
process very easy and transparent.  Every user who tries,
unsuccessfully, to unsubscribe is sent the following clear and
unambiguous message with easy-to-follow instructions:

On Sat, Jan 31, 2009 at 11:18 PM, Mary Fireman maryj...@fortuitus.net
wrote:
 unsubscribe

Hmph.  You can't get out that easy.

Please Note:  In some later model unsubscribe kits, the OFF indicator
has been replaced by POWER-UP STANDBY ENABLE.  Accordingly the ON
indicator has been replaced by the much clearer, POWER-DOWN STANDBY
ENABLE.  Contact your internet service provider for a list of affected
model numbers.  An ON-OFF retrofit panel kit is available for those
who have difficulty with the new and much clearer labeling.

First, ask your Internet Provider to mail you an Unsubscribing Kit. Then
follow these directions. The kit will most likely be the standard
no-fault type. Depending on requirements, System A and/or System B can
be used. When operating System A, depress lever and a plastic dalkron
unsubscriber will be dispensed through the slot immediately underneath.
When you have fastened the adhesive lip, attach connection marked by the
large X outlet hose. Twist the silver-coloured ring one inch below
the connection point until you feel it lock.

The kit is now ready for use. The Cin-Eliminator is activated by the
small switch on the lip. When securing, twist the ring back to its
initial condition, so that the two orange lines meet. Disconnect. Place
the dalkron unsubscriber in the vacuum receptacle to the rear. Activate
by pressing the blue button.

The controls for System B are located on the opposite side. The red
release switch places the Cin-Eliminator into position; it can be
adjusted manually up or down by pressing the blue manual release button.
The opening is self-adjusting. To secure after use, press the green
button, which simultaneously activates the evaporator and returns the
Cin-Eliminator to its storage position.

You may log off if the green exit light is on over the evaporator . If
the red light is illuminated, one of the Cin-Eliminator requirements has
not been properly implemented. Press the List Guy call button on the
right of the evaporator . He will secure all facilities from his control
panel.

To use the Auto-Unsub, first undress and place all your clothes in the
clothes rack. Put on the velcro slippers located in the cabinet
immediately below. Enter the shower, taking the entire kit with you. On
the control panel to your upper right upon entering you will see a
Shower seal button. Press to activate. A green light will then be
illuminated immediately below. On the intensity knob, select the desired
setting. Now depress the Auto-Unsub activation lever. Bathe normally.

The Auto-Unsub will automatically go off after three minutes unless you
activate the Manual off override switch by flipping it up. When you
are ready to leave, press the blue Shower seal release button. The
door will open and you may leave. Please remove the velcro slippers and
place them in their container.

If you prefer the ultrasonic log-off mode, press the indicated blue
button. When the twin panels open, pull forward by rings A  B. The knob
to the left, just below the blue light, has three settings, low, medium
or high. For normal use, the medium setting is suggested.

After these settings have been made, you can activate the device by
switching to the ON position the clearly marked red switch. If during
the unsubscribing operation, you wish to change the settings, place the
manual off override switch in the OFF position. You may now make the
change and repeat the cycle. When the green exit light goes on, you may
log off and have lunch. Please close the door behind you.


Occam's Razor strikes again!!




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

Re: [Mailman-Users] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-20 Thread Russell Clemings

From the reports I've received, it looks as if they redact only from the
headers. With personalization on, I put a %(user_address)s token in the
non-digest footer and as of the last report I got (June 8) it came through
the feedback loop intact. I've never figured out a similar fix for digests,
however, and that seems to be where most of the reports come from. So maybe
there's room for a new approach there.

rac

-- Forwarded message --
 From: Lindsay Haisley fmo...@fmp.com
 To: mailman-users@python.org
 Cc:
 Date: Tue, 19 Jun 2012 19:54:34 -0500
 Subject: Re: [Mailman-Users] AOL redacts user addresses even with VERP and
 full personalization enabled
 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 others have proposed.
 
 Well if this is so, are they still redacting the VERP recipient
 addresses?

 --
 Lindsay Haisley   |  We are all broken toasters, but we still
 FMP Computer Services |manage to make toast
 512-259-1190  |
 http://www.fmp.com|- Cheryl Dehut



--
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] AOL redacts user addresses even with VERP and full personalization enabled

On Wed, 2012-06-20 at 18:23 -0700, Russell Clemings wrote:
 From the reports I've received, it looks as if they redact only from the
 headers. With personalization on, I put a %(user_address)s token in the
 non-digest footer and as of the last report I got (June 8) it came through
 the feedback loop intact.

This may be true, however relying on cleartext in the footer information
to identify the recipient has two problems.  

First, it restricts the freedom of the list administrator to put
whatever he/she wants in the footer, and because the form of footer
information is friable, depending on the list admin, it's impossible to
write a one-size-fits-all script to pull subscriber addresses from
Feedback Reports and deal with complaining subscribers.  Putting this
information in a header which is added depending only on whether
personalization/verp is enabled or not is independent of what the list
admin decides he/she wants subscribers to see in the footer - which
should be there for the benefit of subscribers, not list admins.  

Second, putting the subscriber's email address as cleartext in _any_
part of a post makes it subject to AOL's redaction process.  Whether or
not they are currently redacting this in footer information doesn't
mitigate the fact that they reserve the right to do so, according to
their TOS.  Changes to what is and isn't redacted over the past couple
of years indicates that they periodically change or refine this process.
It seems, however, according to their online documents, that if the
recipient address is encrypted or hashed, then it meets their spec and
won't raise objections, or redactions.  

  I've never figured out a similar fix for digests,
 however, and that seems to be where most of the reports come from. So maybe
 there's room for a new approach there.

If the information in in the header, it's there regardless of whether a
subscriber chooses to receive digests or individual posts.

-- 
Lindsay Haisley   | The only unchanging certainty
FMP Computer Services |is the certainty of change
512-259-1190  |
http://www.fmp.com| - Ancient wisdom, all cultures

--
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] AOL redacts user addresses even with VERP and full personalization enabled

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 encrypted
  implementation).

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, so trying to identify the member *is* an invasion of privacy.
Nor should we judge what the member obviously wants, especially
given the draconian solution.  Unsubscribing the member is a
forceful act that they may not want (you in particular should not
forget that, Dave!)

Note, I do *not* have a better solution.[1]

The point is that there are several points of view from which what we
are proposing here is not nice.  I think we should do it anyway; the
argument that it's for the greatest good of the greatest number is
irrefutable.  But let's remember that the Internet is a big place, and
we don't make the rules, except on our own servers.  On AOL's, the
rules are made by AOL.  If you have a lot of AOL subscribers, you
probably don't want AOL upset at you, even if their policy is bogus.


Footnotes: 
[1]  My policy is that I don't care if my list ever successfully
delivers a message to AOL; my subscribers -- including some who
happen to be stuck on AOL for some reason -- think that's perfectly
fine.  So far we haven't been banned by AOL AFAIK :-).  But that won't
work for most of you!

--
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] AOL redacts user addresses even with VERP and full personalization enabled

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 just VERP, please.  It doesn't require any difference in MTA
behavior at all.

  Uh, trust me -- you really don't want to get into the discussion of
  creating new SMTP protocol enhancements.  I was on the DRUMS WG.
  You really, really don't want to go there.

I don't understand the technical issue here.  VERP simply requires the
(reasonably standard) existing feature that the final MTA ignore
random goop in the mailbox spec if properly marked (usually with '+',
sometimes with a '-').  As far as I know, no MTA ever checks that the
random goop is well-formed random goop -- that's an oxymoron, isn't
it?  If this proposal won't fly, normal VERP shouldn't, either.

And even if one does, the ones we recommend don't, right?  So somebody
who wants to use Lindsay's proposal just needs to change MTAs.  (I
know that's not zero-cost, but machines are cheap these days; you can
dedicate a (virtual) machine to Mailman at very low cost.  I'll bet
Brian would do it for zero extra dollars per month over his standard
Mailman service! :-)
--
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] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-19 Thread Kirke Johnson

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 fmouse-mail...@fmp.comwrote:

 The irony is not lost :)  The snake eats itself tail-first until it
 disappears.

--
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] AOL redacts user addresses even with VERP and full personalization enabled

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, as an
alternative choice to Mailman's VERP implementation.
 
 It's just VERP, please.  It doesn't require any difference in MTA
 behavior at all.

EVERP = Encrypted VERP

   Uh, trust me -- you really don't want to get into the discussion of
   creating new SMTP protocol enhancements.  I was on the DRUMS WG.
   You really, really don't want to go there.
 
 I don't understand the technical issue here.  VERP simply requires the
 (reasonably standard) existing feature that the final MTA ignore
 random goop in the mailbox spec if properly marked (usually with '+',
 sometimes with a '-').  As far as I know, no MTA ever checks that the
 random goop is well-formed random goop -- that's an oxymoron, isn't
 it?  If this proposal won't fly, normal VERP shouldn't, either.

Exactly.  Strictly speaking, this is a MDA issue, although the MTA must
accept mail to user-random-goop@example.com based on the existence of
an mail account for user.  If user is a Mailman list, then what's
done with random-goop is Mailman's concern alone.

 And even if one does, the ones we recommend don't, right?  So somebody
 who wants to use Lindsay's proposal just needs to change MTAs.

Not really, because if the MTA and MDA will deal properly with mail
addressed to list-bounce+user=example@foo.com, a standard VERP
address, it will handle list-bounces+aesencryptedaddr...@foo.com.  Only
Mailman needs to extend the way it handles the VERPed address.

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 the contents of the VERP address
in the envelope sender would probably attract the notice of a real
person, no matter how clueless.  Better to go with a stealth
Resent-Message-ID header.

-- 
Lindsay Haisley   |Friends are like potatoes.
FMP Computer Services |If you eat them, they die
512-259-1190  |
http://www.fmp.com|  - Aaron Edmund

--
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] AOL redacts user addresses even with VERP and full personalization enabled

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 message to me is
 therefore part of the violation of my terms. So whose terms ends up
 governing when they're in conflict?
 
 When you sign up for the feedback loop, you do so under the TOS of the
 feedback loop.  If their user violates your TOS by reporting your list
 traffic as spam, that doesn't change the TOS of the feedback loop that
 you signed up for.

Which brings up an interesting point, albeit it's mostly academic.  It's
been years since I read the TOS for AOL's Feedback Loop email.  Does the
TOS disallow trying to determine the address of the recipient, or just
acting on this knowledge.  The former is unenforceable, as are
prohibitions on reverse-engineering proprietary software in my
possession.  Acting on this knowledge is another matter.  I'm free to
put whatever information I choose in an email I send to an AOL user,
including a header with an encrypted recipient address.  If AOL accepts
it and sends it back to me in a spam report, and has not redacted
information I put into it (and they are free to redact whatever they
choose), then I must be able to learn what I can from the offending
message, including from the headers.

If indeed the TOS prohibits determining the address of the AOL recipient
from the email, then it's only enforceable if I take action based on
this knowledge, since this hardly rises to the level of industrial
espionage.  All kinds of things get put into TOS documents that are
ridiculous and unenforceable on the face of it.  Yes, AOL is under no
obligation to send me Email Feedback Reports, and can stop doing so at
any time for any reason.  They can even cut off access to their user
base from my servers.  They don't have enough clout on the Internet
anymore so that this would really hurt anyone but themselves.

-- 
Lindsay Haisley   |  Humor will get you through times of no humor
FMP Computer Services |  better than no humor will get you through
512-259-1190  | times of humor.
http://www.fmp.com|- Butch Hancock

--
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] AOL redacts user addresses even with VERP and full personalization enabled

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.

N.B. That expansion doesn't say what kind of values the variable
takes, although the usual implementation assumes a friendly Internet
and uses addressee mailboxes.  Wikipedia says, However, some VERP
implementations use message number or random key as part of VERP,
which is close enough to encrypted VERP for me, YMMV.  It's just an
implementation detail that really only concerns implementers

I'm not sure of this, but it seems to me that encrypted VERP should
work fine with greylisted recipients (if you can ever call the results
of greylisting fine :-P) as long as you don't change the encryption
key very often.

In Mailman 3, I would suppose it won't be hard to store the encrypted
form along with the rest of the user's profile.

  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 the contents of the VERP address
  in the envelope sender would probably attract the notice of a real
  person, no matter how clueless.

Ah, but we can just say this allows us to VERP without exposing
addresses on anybody's disk; this helps protect your users' privacy.

--
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] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-19 Thread Geoff Shang


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 the contents of the VERP address
 in the envelope sender would probably attract the notice of a real
 person, no matter how clueless.

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.

Geoff.

--
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] AOL redacts user addresses even with VERP and full personalization enabled

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 receiving offensive emails, whatever one calls them.  The
complaint is, in AOL's collective mind, evidence of a spam problem
which needs to be fixed.  It's a far stretch of their assumed authority
to presume that the spam problem is the list itself.  What action,
other than severing the link between the sender (the list) and the
recipient (the AOL subscriber) would AOL expect, or consider a justified
use of an Email Feedback Report?

  so trying to identify the member *is* an invasion of privacy.

Mailman identifies recipients all the time in the process of doing
bounce processing.  The only difference here is that the bounce is
explicitly initiated by the recipient by pressing the Report spam
button, rather than implicitly by, say, changing email addresses without
updating associated list subscriptions.

 Nor should we judge what the member obviously wants, especially
 given the draconian solution.

Unsubscribing a list subscriber is hardly draconian.  Perhaps banning
the user from resubscribing might be considered so, but I don't think
that automatic unsubscription of an address rises anywhere near this
level.  The system I've built here to parse AOL's Feedback Reports uses
a withlist script to identify the list administrator and provides
him/her with a detailed explanation of the automated action and what the
admin's options are, which include counseling the unsubscribed user and
re-subscribing him/her.

 Unsubscribing the member is a
 forceful act that they may not want (you in particular should not
 forget that, Dave!)
 
I would use intentional rather than forceful, and in many cases,
perhaps most, hitting the Report Spam button is probably seen as a way
to to get AOL to help them stop receiving emails that they may have long
ago subscribed to, and they don't have the patience or knowledge to jump
through the hoops required to explicitly unsubscribe from the list.

-- 
Lindsay Haisley   | It is better to bite a single
FMP Computer Services |cannibal than to curse the doggies
512-259-1190  |
http://www.fmp.com|-- John Day

--
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] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-19 Thread David

On Tue, Jun 19, 2012 at 4:17 AM, Stephen J. Turnbull step...@xemacs.orgwrote:

 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 encrypted
   implementation).

 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,


Yes, I know that is their perspective. And I know you are playing devil's
advocate, Stephen, which I appreciate. It is worthwhile to make sure we all
understand their perspective, and I don't disagree with anything you wrote.

In fact this is the natural way I think too, so I just assume everyone else
also tries to see all sides of any given situation. But at some point we
have to take action and we have to be practical. A judge may be good at
impartially hearing arguments from both sides, but he also makes a decision
in the end.

When it comes to running our list on our server, AOL is wrong to attempt to
conceal the member identity (both by obfuscation and policy). I'll
elaborate why I come down to that decision while accepting that AOL's
position is (or was) right for them in a certain set of circumstances that
existed when they wrote their TOS.

Our list does not contain any spam. There is no spam problem to fix. Every
post to our list is moderated by a human and we reject posts even from
well-known members when those posts don't meet our guidelines. There is no
way to eliminate something that doesn't exist.

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). So we may get a dozen or more feedback reports
within a minute, all triggered by the same user and without regard for the
actual content of the messages. I believe I have evidence that would prove
this to any rational person, and I suspect most other people on this list
could put together similar evidence (if they are running spam-free lists
like ours).

This is absolutely *not* a content problem, as AOL would like to pretend
(or define it to be in their TOS). They can define the problem any way they
wish, but the reality is that this is a problem with specific users, not
with content.

Therefore, while AOL can define any policy they wish, their current policy
is completely broken for most of us. Since any and all valid content from
our list can trigger an AOL feedback abuse report, to comply strictly and
eliminate these abuse reports would mean shutting down our list completely.
They give no other option that I can see.

Given that thousands of members value our list greatly, shutting it down to
comply with AOL's broken policy is not a viable solution.

The only solution (given our situation where the trigger is not
content-specific) is to remove the member who won't remove themselves. My
statements may not apply to all users of Mailman, but they are facts in our
specific situation. And all I can deal with are the facts. Therefore, if
our list is to survive (and provide a service to any AOL user), we have to
remove individual AOL users in response to these feedback reports. We have
to do that or we have to shut down Mailman or we have to face having our
server blacklisted. I choose to take the reasonable course of action which
allows me to do the most good for the most people.

In fact, in our specific situation, everyone wins nearly every time. And in
the rare case (hasn't happened yet) that we remove an AOL member who marked
us as spam by mistake, we can easily fix that with little damage or cost to
anyone. So this is not only the reasonable course of action, it is the one
which does the least harm.
--
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] AOL redacts user addresses even with VERP and full personalization enabled

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.  It's
 not obvious to me that practioners would get it right, either.  Let's
 not proliferate unnecessary acronyms.

I would not presume on the patience of the world (nor of the people on
this list) by seriously proposing a YASA (Yet Another Stupid Acronym).
My use of EVERP was for reference purposes on this list only.  All other
uses are explicitly and strictly prohibited.

 N.B. That expansion doesn't say what kind of values the variable
 takes, although the usual implementation assumes a friendly Internet
 and uses addressee mailboxes.  Wikipedia says, However, some VERP
 implementations use message number or random key as part of VERP,
 which is close enough to encrypted VERP for me, YMMV.  It's just an
 implementation detail that really only concerns implementers

Exactly.  VERP refers to the concept of including a delivery address
within the envelope sender address, which takes advantage of the
RFC-prescribed practice of returning undeliverable email to the envelope
sender address.

 I'm not sure of this, but it seems to me that encrypted VERP should
 work fine with greylisted recipients (if you can ever call the results
 of greylisting fine :-P) as long as you don't change the encryption
 key very often.

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.  This could, of
course, be changed.

 In Mailman 3, I would suppose it won't be hard to store the encrypted
 form along with the rest of the user's profile.

Yes, which would make the VERP consistent, if greylisting cares.  It
might also be possible to generate and store encryption keys per list
rather than per site, as my experimental implementation (mm 2.1.15)
does. 

-- 
Lindsay Haisley   | The only unchanging certainty
FMP Computer Services |is the certainty of change
512-259-1190  |
http://www.fmp.com| - Ancient wisdom, all cultures

--
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] AOL redacts user addresses even with VERP and full personalization enabled

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). So we may get a dozen or more
 feedback reports within a minute, all triggered by the same user and
 without regard for the actual content of the messages.

I've seen this as well on a number of occasions.  As I noted in my
previous email, a lot of people, I might say _especially_ AOL users, are
not highly computer literate, and many may indeed be computer-phobic.
They don't have the patience or confidence to follow the directions
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.

-- 
Lindsay Haisley   | We have met the enemy and he is us.
FMP Computer Services |
512-259-1190  |  -- Pogo
http://www.fmp.com|

--
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] AOL redacts user addresses even with VERP and full personalization enabled

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 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] AOL redacts user addresses even with VERP and full personalization enabled

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.  This could, of
  course, be changed.

It sounds like it would be easy enough to make it a parameter, to be
disabled only if a list has trouble with greylisting.

   In Mailman 3, I would suppose it won't be hard to store the encrypted
   form along with the rest of the user's profile.
  
  Yes, which would make the VERP consistent, if greylisting cares.

I had more in mind very high volume sites where the expense of
encryption would be a factor in achieving timely delivery.

--
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] AOL redacts user addresses even with VERP and full personalization enabled

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 thing is that most Mailman lists will have a List-Unsubscribe
header, so AOL could provide an actual unsubscribe button.

Hm ... I wonder if it would be possible to use DKIM or other
signatures that are typically present to verify that *that* user did
indeed hit unsubscribe?  (And it wasn't a malicious third party or
another AOLuser who hit the unsubscribe link in the 23rd footer
instead of the 24th)  Not that this would help for AOL, since the
heads are wa-a-ay up where the sun don's shine, but it's an often-
requested feature in general.

--
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] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-19 Thread Mike Starr

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 understand the technical definitions of what spam is. But there's a massive
amount of users who don't have a clue. They may believe that the email that expresses an opinion
(conforming to the TOS of the mailing list to which they're subscribed) that they vehemently
disagree with *is* spam. They also may have never even scanned the bottom of each email they
receive from their mailing list and noticed the (usually) clear instructions for unsubscribing from
the list. How often have we all seen an email posted to one of our lists that says
Unsubscribe me from this list or perhaps stop sending me this crap?

Many of the mailman cognoscenti are highly skilled technical folks with little respect
(and often little tolerance) for clueless users. Sometimes you just have to choke back
the bile and lovingly correct those who have less understanding. Perhaps the unsubscribe
message should also contain something like The email messages you've received as a
subscriber to this mailing list are *not spam*. Messages from new users are all approved
by the list moderator until that moderator is convinced that the subscriber is not a
spammer. If you reported a message from this list as spam to your email provider we'll
unsubscribe you as soon as we find out about it. If you reported a message as spam
accidentally and don't want to be unsubscribed from this mailing list, click *here*.

Best regards,

Mike
--
Mike Starr WriteStarr Information Services
Technical Writer -Online Help Developer - WordPress Websites
Graphic Designer - Desktop Publisher - Custom Microsoft Word templates
(262) 694-1028 - m...@writestarr.com - http://www.writestarr.com
President, Working Writers of Wisconsin http://www.workingwriters.org/
--
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] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-19 Thread William Yardley

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 thing, and also to
protect (to some extent) their users' privacy. I think the point of the
FBL is more to alert you to problems on your network, than to assist you
in listwashing. Yes, people will click the report spam link by
accident occasionally, but probably not often enough to get you flagged
as a spam source if your lists are genuinely legitimate, and use a
closed-loop confirmation process.

I haven't been on an AOL FBL for a long time, but does the munging in
question remove the queue-ID and message-ID? Otherwise, it should be
very simple to find the subscriber by looking at your own logs.

But honestly, AOL is not the 500 lb gorilla they once were, so I
wouldn't lose a lot of sleep over it.

w

--
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] AOL redacts user addresses even with VERP and full personalization enabled

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 report spam link by
 accident occasionally

No, more often than not these reports come in bunches, initiated by the
same user.  The report spam button was obviously pressed with intent.

 , but probably not often enough to get you flagged
 as a spam source if your lists are genuinely legitimate, and use a
 closed-loop confirmation process.

This is probably true.

 But honestly, AOL is not the 500 lb gorilla they once were, so I
 wouldn't lose a lot of sleep over it.

This is also probably true, fortunately, and in fact the importance of
AOL (or lack thereof) probably doesn't warrant the time we've put in
discussing their misbegotten policies :)

-- 
Lindsay Haisley   | Fighting against human creativity is like 
FMP Computer Services |   trying to eradicate dandelions
512-259-1190  |
http://www.fmp.com|   -- Pamela Jones

--
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] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-19 Thread Dave (FitEyes)

On Tue, Jun 19, 2012 at 6:51 PM, William Yardley
mail...@veggiechinese.netwrote:

 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 thing, and also to
 protect (to some extent) their users' privacy. I think the point of the
 FBL is more to alert you to problems on your network, than to assist you
 in listwashing. Yes, people will click the report spam link by
 accident occasionally, but probably not often enough to get you flagged
 as a spam source if your lists are genuinely legitimate, and use a
 closed-loop confirmation process.


Is this true? We had one AOL member flag almost 50 of our list's messages
as spam today. This person joined us in December 2011. He/she joined via
the website and confirmed via email, but then he didn't actively post to
the list and we didn't hear a single thing from him/her until today --
then, wham, almost 50 abuse reports from this one person today.

We unsubscribed the person today.

Do today's 50 abuse reports really have insufficient power to damage our
reputation?

Could this person continue to mark large numbers of our lists messages as
spam without it affecting our reputation or our ability to deliver to AOL
users who want to receive our messages? Before we figured out how to
identify and remove such people, they would just continue to mark our
messages as spam every single day. That won't hurt our reputation over time?



I haven't been on an AOL FBL for a long time, but does the munging in
 question remove the queue-ID and message-ID? Otherwise, it should be
 very simple to find the subscriber by looking at your own logs.



That's what we are doing now. But it is only possible if you VERP every
message and have accessible logs. There was earlier discussion about the
fact that these abuse reports can relate to very old messages and those
logs may have been archived or removed.
--
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] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-19 Thread Russell Clemings

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 or a custom
remove link in the body of the email to help you identify the original
recipient of the message.

http://postmaster.aol.com/Postmaster.FeedbackLoop.php

rac
--
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] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-19 Thread Dave (FitEyes)

On Tue, Jun 19, 2012 at 8:17 PM, Russell Clemings rclemi...@gmail.comwrote:

 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 or a custom
 remove link in the body of the email to help you identify the original
 recipient of the message.

 http://postmaster.aol.com/Postmaster.FeedbackLoop.php


Way to embarrass all of us who didn't take the time to actually read the
TOS! ;-)

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 others have proposed.

Thanks!
--
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] AOL redacts user addresses even with VERP and full personalization enabled

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 others have proposed.
 
Well if this is so, are they still redacting the VERP recipient
addresses?

-- 
Lindsay Haisley   |  We are all broken toasters, but we still
FMP Computer Services |manage to make toast
512-259-1190  |
http://www.fmp.com|- Cheryl Dehut


--
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] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-19 Thread Dave (FitEyes)

On Tue, Jun 19, 2012 at 8:55 PM, Lindsay Haisley fmouse-mail...@fmp.comwrote:

 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 others have proposed.
 
 Well if this is so, are they still redacting the VERP recipient
 addresses?


Yes.
--
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] AOL redacts user addresses even with VERP and full personalization enabled

On Tue, 2012-06-19 at 21:07 -0400, Dave (FitEyes) wrote:
 
 
 On Tue, Jun 19, 2012 at 8:55 PM, Lindsay Haisley fmouse-mail...@fmp.com 
 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 others have proposed.

 Well if this is so, are they still redacting the VERP
 recipient
 addresses?
 
 Yes.
 
Reading in http://postmaster.aol.com/Postmaster.FeedbackLoop.php+ it
seems that [AOL suggests] using opaque identifiers for the email
recipient or a custom remove link in the body of the email to help you
identify the original recipient of the message.

I would assume that an AES-encrypted email address in Resent-Message-ID
or in the VERP address, or even a hashed recipient address in a custom
header such as X-Subdata, all of which have been discussed here, would
meet the criterion of being an opaque identifier.  Does this sound
logical?

Of these, an encrypted or hashed recip address in the VERP envelope
header seems the most logical, since it seems that we don't have to go
stealth with this one.  Any chance of requesting this in Mailman 3?

Looking at a recent Email Feedback Report it looks as if the list name
is also pretty well redacted, except in the message footer, the format
of which is up to individual list administrators, so maybe the list name
or address should be included in this or another encrypted header as
well.

-- 
Lindsay Haisley   |  The voice of dissent was arrested before
FMP Computer Services | the president cleared his throat to
512-259-1190  |speak of freedom
http://www.fmp.com|
  |-- Chris Chandler

--
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] AOL redacts user addresses even with VERP and full personalization enabled

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 said everything he wants to say about this subject
:-), you could send mail to mailman-developers, but I think this idea
is already pretty well-baked, and maybe you even have a patch you
could attach to the issue?
--
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] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-18 Thread Stephen J. Turnbull

Lindsay Haisley writes:

  So what would be the implications of hacking an extra header into
  outgoing posts on lists for which personalization is enabled, say
  X-Subdata, with said header containing a hash of the subscriber
  address to which the post is directed?

I would use Resent-Message-ID, unless the content of posts is such
that you can get away with munging Message-ID itself.  That is a
standardized header that Mailman uses anyway.  I would also use a
reversible encryption rather than a hash.  (Not so much because it's
reversible, but rather because it's undetectable except insofar as
it's different from standard Mailman.)

  This would, in theory, mostly satisfy AOL's privacy concern

I really don't think so.  It might satisfy *your* privacy concerns,
but their privacy concern is absolute.  (I doubt that their basic
motive is to protect their customers' privacy, especially given Brad's
statements, but I see no reason not to take them at their word that
*any* attempt to identify customers is a violation of their feedback
loop user agreement.)

That's not to say you shouldn't do it, but if they catch on, they'll
start redacting those headers, too, and quite possibly boot you from
their feedback loop.

As Brad points out, they simply don't care if their members get the
mail that they want.  Or at least, they don't care about that anywhere
near as much as they care that their members don't get mail that they
don't want!

  Hacking the message ID out of mail logs to identify the subscriber seems
  somewhat chancier and more difficult, since mail logs roll over and
  eventually disappear from the system.

If you say so, but *that is under your control*.  I'd much rather make
the effort to make my logs dependable, than depend on any cooperation
from AOL.
--
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] AOL redacts user addresses even with VERP and full personalization enabled

On Mon, 2012-06-18 at 17:03 +0900, Stephen J. Turnbull wrote:
 Lindsay Haisley writes:
 
   So what would be the implications of hacking an extra header into
   outgoing posts on lists for which personalization is enabled, say
   X-Subdata, with said header containing a hash of the subscriber
   address to which the post is directed?
 
 I would use Resent-Message-ID, unless the content of posts is such
 that you can get away with munging Message-ID itself.

Good suggestion.  I assume that Mailman never inserts
Resent-Message-ID into posts, is that correct?  I'd rather not mess
with Message-ID which provides a traceable path to the original
sender.

 I would also use a
 reversible encryption rather than a hash.  (Not so much because it's
 reversible, but rather because it's undetectable except insofar as
 it's different from standard Mailman.)

Suggestions, Stephen?  Why would, say, hashlib.md5(recip).hexdigest() be
any more or less detectable than a reversible encryption?

   This would, in theory, mostly satisfy AOL's privacy concern
 
 I really don't think so.  It might satisfy *your* privacy concerns,
 but their privacy concern is absolute.

I don't give a rat's behinder about privacy on this issue, only that _I_
be able to identify the complaining recipient, based on having the
subscriber lists available, and that AOL and their minions _not_ be able
to do so.

 That's not to say you shouldn't do it, but if they catch on, they'll
 start redacting those headers, too, and quite possibly boot you from
 their feedback loop.

They've been letting VERPed subscriber addresses through their rather
scattershot redaction process for years.  I've been parsing them out of
the Sender header for about as long and automatically unsubscribing
these addresses from Mailman lists.  I could easily ignore them and stay
under AOL's radar, but I consider it a service to my customers to help
them keep their lists free of subscribers who don't want the traffic, no
matter how clueless they may be.

Doing this as a custom hack helps.  If this were implemented as a
Mailman standard option then word might indeed get back to them about
it.  Using Resent-Message-ID as a header name is a clever idea.

 As Brad points out, they simply don't care if their members get the
 mail that they want.  Or at least, they don't care about that anywhere
 near as much as they care that their members don't get mail that they
 don't want!

IMHO, AOL's days on this planet are numbered.  They'll go the way of
Compuserve :)

   Hacking the message ID out of mail logs to identify the subscriber seems
   somewhat chancier and more difficult, since mail logs roll over and
   eventually disappear from the system.
 
 If you say so, but *that is under your control*.  I'd much rather make
 the effort to make my logs dependable, than depend on any cooperation
 from AOL.

I've seen Email Feedback Reports come in on posts that went out six
months prior.  Parsing Message IDs out of this many MBs of back mail
logs, most of them compressed, would be hugely expensive of processing
time.  I don't depend on cooperation from AOL, just stupidity, which
seems to be pretty dependable :)  On the other hand, the process of
dealing with these reports only happens a few times a month, at most.  

-- 
Lindsay Haisley   | Real programmers use butterflies
FMP Computer Services |
512-259-1190  |   - xkcd
http://www.fmp.com|

--
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] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-18 Thread Tanstaafl


On 2012-06-18 12:22 PM, Lindsay Haisley fmouse-mail...@fmp.com wrote:

Doing this as a custom hack helps.  If this were implemented as a
Mailman standard option then word might indeed get back to them about
it.  Using Resent-Message-ID as a header name is a clever idea.


I'd also argue that since this is not AOL specific but is a generic way 
for a mail system admin to control his own server, and AOL cannot 
dictate what you add to your own headers on your own messages, why not 
make it part of mailman official, with appropriate warnings about some 
brain-dead (probably unenforcable and possibly even illegal) limitations 
by certain clueless providers?

--
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] AOL redacts user addresses even with VERP and full personalization enabled

On Mon, 2012-06-18 at 10:01 -0700, Brad Knowles wrote:
  IMHO, AOL's days on this planet are numbered.  They'll go the way of
  Compuserve :)
 
 You mean that they'll get bought -- by AOL?  ;-)
 
The irony is not lost :)  The snake eats itself tail-first until it
disappears.

They'll probably get bought by Google!  Didn't TW dump them recently?

-- 
Lindsay Haisley   |  We are all broken toasters, but we still
FMP Computer Services |manage to make toast
512-259-1190  |
http://www.fmp.com|- Cheryl Dehut

--
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] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-18 Thread Stephen J. Turnbull

Lindsay Haisley writes:

  Good suggestion.  I assume that Mailman never inserts
  Resent-Message-ID into posts, is that correct?

Currently it doesn't, it seems, but there have been proposals to make
it do so (related to DKIM IIRC).  However, if and when it does, it
wouldn't hurt to add your obfuscated user id to it.

  I'd rather not mess with Message-ID which provides a traceable
  path to the original sender.

Right.  My comment about content was for the case where the list
owner is the only (or main) original sender.

  Why would, say, hashlib.md5(recip).hexdigest() be any more or less
  detectable than a reversible encryption?

Because once the idea becomes public, anybody can check the nonesense
strings in your headers to see if any of them hash to the user's id.
That's a lot more difficult if you use encryption based on a secret
key.

  IMHO, AOL's days on this planet are numbered.  They'll go the way of
  Compuserve :)

Yeah, I hope so.  Unfortunately, where I live, NiftyServe still exists
and its customers still put raw Shift JIS in their headers
occasionally.  I'm not going to bet on AOL's timely demise.

  I've seen Email Feedback Reports come in on posts that went out six
  months prior.  Parsing Message IDs out of this many MBs of back mail
  logs, most of them compressed, would be hugely expensive of processing
  time.

Seriously?  How many feedback reports do you get per second?  Yes, it
would be a little costly, but presumably they give something like a
date, you can narrow it down to a few MB I would guess.

--
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] AOL redacts user addresses even with VERP and full personalization enabled

On Tue, 2012-06-19 at 02:11 +0900, Stephen J. Turnbull wrote:
 Lindsay Haisley writes:
   Why would, say, hashlib.md5(recip).hexdigest() be any more or less
   detectable than a reversible encryption?
 
 Because once the idea becomes public, anybody can check the nonesense
 strings in your headers to see if any of them hash to the user's id.
 That's a lot more difficult if you use encryption based on a secret
 key.

Very true, and a good point.  A little research turned up
http://www.codekoala.com/blog/2009/aes-encryption-python-using-pycrypto/
which is a good discussion of using AES encryption in Python.  The
Crypto module seems to be standard issue with Python - no special
libraries required.

   IMHO, AOL's days on this planet are numbered.  They'll go the way of
   Compuserve :)
 
 Yeah, I hope so.  Unfortunately, where I live, NiftyServe still exists
 and its customers still put raw Shift JIS in their headers
 occasionally.  I'm not going to bet on AOL's timely demise.

It took a major meteor hit to wipe out the dinosaurs!

   I've seen Email Feedback Reports come in on posts that went out six
   months prior.  Parsing Message IDs out of this many MBs of back mail
   logs, most of them compressed, would be hugely expensive of processing
   time.
 
 Seriously?  How many feedback reports do you get per second?  Yes, it
 would be a little costly, but presumably they give something like a
 date, you can narrow it down to a few MB I would guess.

Wlll ...  The average number of feedback reports / second received
on my servers is pretty managable, actually ;)  I prefer the idea of
using Resent-Message-ID and and AES encryption on the recipient address
rather than mucking with log files.  It would be nice to put this into
the Mailman structure in such a way that I could retrieve, or access the
secret key, or at least perform encryption and decryption from a
withlist script.

-- 
Lindsay Haisley   | The difference between a duck is because
FMP Computer Services |one leg is both the same
512-259-1190  | - Anonymous
http://www.fmp.com|

--
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] AOL redacts user addresses even with VERP and full personalization enabled

On Mon, 2012-06-18 at 13:04 -0400, Tanstaafl wrote:
 On 2012-06-18 12:22 PM, Lindsay Haisley fmouse-mail...@fmp.com wrote:
  Doing this as a custom hack helps.  If this were implemented as a
  Mailman standard option then word might indeed get back to them about
  it.  Using Resent-Message-ID as a header name is a clever idea.
 
 I'd also argue that since this is not AOL specific but is a generic way 
 for a mail system admin to control his own server, and AOL cannot 
 dictate what you add to your own headers on your own messages, why not 
 make it part of mailman official, with appropriate warnings about some 
 brain-dead (probably unenforcable and possibly even illegal) limitations 
 by certain clueless providers?

I agree.  Stephen Turnbull points out that using reversible encryption
with a secret key would be more secure from the point of view of
restricting 3rd party knowledge of the unencrypted/unhashed data.  A
secret key could be kept per-list or per-site.  The ability to securely
track recipient information (or any information) across a list
distribution, or across a non-delivery bounce might be very useful.

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.

-- 
Lindsay Haisley   |  Humor will get you through times of no humor
FMP Computer Services |  better than no humor will get you through
512-259-1190  | times of humor.
http://www.fmp.com|- Butch Hancock

--
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] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-18 Thread David

On Mon, Jun 18, 2012 at 2:44 PM, Lindsay Haisley fmouse-mail...@fmp.comwrote:

 On Mon, 2012-06-18 at 13:04 -0400, Tanstaafl wrote:
  On 2012-06-18 12:22 PM, Lindsay Haisley fmouse-mail...@fmp.com wrote:
   Doing this as a custom hack helps.  If this were implemented as a
   Mailman standard option then word might indeed get back to them about
   it.  Using Resent-Message-ID as a header name is a clever idea.
 
  I'd also argue that since this is not AOL specific but is a generic way
  for a mail system admin to control his own server, and AOL cannot
  dictate what you add to your own headers on your own messages, why not
  make it part of mailman official, with appropriate warnings about some
  brain-dead (probably unenforcable and possibly even illegal) limitations
  by certain clueless providers?

 I agree.  Stephen Turnbull points out that using reversible encryption
 with a secret key would be more secure from the point of view of
 restricting 3rd party knowledge of the unencrypted/unhashed data.  A
 secret key could be kept per-list or per-site.  The ability to securely
 track recipient information (or any information) across a list
 distribution, or across a non-delivery bounce might be very useful.

 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.


This whole thread is a good and interesting discussion. Anything along
these lines sounds like a great suggestion  to me.

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 encrypted
implementation). It is a service to the individual (and to the entire list
membership and even the Internet as a whole, I think).

Originally, this seemed appropriate as a personal project. But the more I
think about this, the more clear it seems that a feature that allows a list
admin to stop sending emails to members who no longer want that email is a
very good feature to include in Mailman. It can help ensure that Mailman is
used in a way that causes the least amount of grief for everyone across the
Internet, right?
--
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] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-18 Thread Larry Stone


On Sun, 17 Jun 2012, Brad Knowles wrote:

In fact, when you sign up for the AOL Feedback Loop (as I did years ago 
for the lists hosted at python.org), the instructions explicitly state 
that you may not use any information they give you to determine who the 
affected user is -- they're simply telling you that you have a problem 
that you need to fix on your end to keep spam from being generated in 
the first place, and it is not relevant which AOL user is complaining.


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 message to me is therefore part of the 
violation of my terms. So whose terms ends up governing when they're in 
conflict?


Personally, I'm not going to worry about it. I'll use them as best I can 
to unsubscribe and server ban the offending subscriber. As I said, that 
AOL user has violated my terms and I am entitled to deal with that 
violation. If AOL were to ever call me on it, I'll worry about that then.


-- Larry Stone
   lston...@stonejongleux.com
--
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] AOL redacts user addresses even with VERP and full personalization enabled

On Mon, 2012-06-18 at 12:05 -0700, Brad Knowles wrote:
 Uh, trust me -- you really don't want to get into the discussion of
 creating new SMTP protocol enhancements.  I was on the DRUMS WG.  You
 really, really don't want to go there.
 
VERP is not an SMTP protocol, but a MTA property supported by many
modern MTAs such as Courier.  It relies on the fact that MTAs which
support it treat user-somed...@example.com as an email address extension
of u...@example.com.

Pardon me if I'm missing something here.

-- 
Lindsay Haisley   | Never expect the people who caused a problem
FMP Computer Services |  to solve it. - Albert Einstein
512-259-1190  |
http://www.fmp.com|

--
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] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-18 Thread Brad Knowles

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 message to me is therefore part of the violation of 
 my terms. So whose terms ends up governing when they're in conflict?

When you sign up for the feedback loop, you do so under the TOS of the feedback 
loop.  If their user violates your TOS by reporting your list traffic as spam, 
that doesn't change the TOS of the feedback loop that you signed up for.

Two lefts make a U-turn, not a right.  ;-)

 Personally, I'm not going to worry about it. I'll use them as best I can to 
 unsubscribe and server ban the offending subscriber. As I said, that AOL user 
 has violated my terms and I am entitled to deal with that violation. If AOL 
 were to ever call me on it, I'll worry about that then.

On that subject, I agree with you.

--
Brad Knowles b...@shub-internet.org
LinkedIn Profile: http://tinyurl.com/y8kpxu

--
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] AOL redacts user addresses even with VERP and full personalization enabled

2012-06-18 Thread Thomas Hochstein

Lindsay Haisley schrieb:

 So what would be the implications of hacking an extra header into
 outgoing posts on lists for which personalization is enabled, say
 X-Subdata, with said header containing a hash of the subscriber
 address to which the post is directed?

AOL ist actually recommending something like that (or adding the user
name somewhere in a way not looking like a mail addeess) - which makes
the whole thing even more absurd.

-thh
--
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] AOL redacts user addresses even with VERP and full personalization enabled

On Mon, 2012-06-18 at 14:59 -0400, David wrote:
 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
 encrypted implementation). It is a service to the individual (and to
 the entire list membership and even the Internet as a whole, I think).

Dave, you're spot-on in this assessment, and this is the way I run my
business.  Unfortunately, the Internet is no longer the kinder, gentler
network it was 15, or even 10 years ago.  In terms of an effective and
progressive attitude toward customer service and satisfaction, AOL's
position is 180 degrees counterintuitive and makes NO sense whatsoever.
It only makes sense in terms of butt-covering!  In that context, it's
totally logical.  AOL has for years, perhaps always, been infamous for
the lousy quality of their email service.

FWIW, pursuant to Stephen's comments re. using encryption rather than
hashing for passing recipient addresses in headers, I've attached a
short Python script which puts short strings of data, such as an email
address, into an AES cipher.  This could be folded into the Mailman
handlers and AES_SECRET_KEY could be put into mm_cfg.py.  Hacks to
SMTPDirect.py to incorporate an encrypted cipher of the recipient
address could make use if it.  I believe all the Python modules it uses
are standard issue with the distribution.

-- 
Lindsay Haisley   | SUPPORT NETWORK NEUTRALITY
FMP Computer Services | --
512-259-1190  | Boycott Yahoo, RoadRunner, AOL
http://www.fmp.com| and Verison
--
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] AOL redacts user addresses even with VERP and full personalization enabled