headers
Terry Earley | 17 Jun 2012 04:14

AOL redacts user addresses even with VERP and full personalization enabled

We are getting pretty frustrated with AOL. Their feedback report redacts
addresses, so we enabled VERP and full personalization so the "envelope"
can send us the actual address. No good:

Return-Path: <all-bounces+redacted=aol.com <at> discuss.fiteyes.com>

To: redacted <at> aol.com
Errors-To: all-bounces+redacted=aol.com <at> discuss.fiteyes.com
Sender: all-bounces+redacted=aol.com <at> discuss.fiteyes.com

Terry
fiteyes.com
------------------------------------------------------
Mailman-Users mailing list Mailman-Users <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Lindsay Haisley | 17 Jun 2012 06:58
Favicon

Re: AOL redacts user addresses even with VERP and full personalization enabled

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.  The only explanations
that come to mind are very sinister ones, but given the way things are
going these days, it may indeed be that AOL is truly trying to break the
Internet mail system so that they and their ilk can try to rebuild it
according to their own (for profit) model.

As of April 4, I was still receiving AOL's Email Feedback Reports with
the sender and return-path addresses improperly redacted in included
subject emails so that I could parse out the complaining subscriber.
e.g.:

Return-Path: <redacted-bounces+johndoe=aol.com <at> lists.local-list.com>

These reports are fairly rare these days, and I haven't received any of
them from AOL since then, although I'm subscribed to their reports for
both of my servers.  If AOL is now fully redacting subscriber
information then indeed perhaps the only way to identify the complaining
subscriber is by tracing the Message ID through the mail log files.
Another alternative might be to add a header to outgoing messages to
include the subscriber address as a hash in an X-something header.
Assuming the management of AOL complaining subscribers via their Email
Feedback Reports is automated at the list server (as it is here) it
should be relatively fast and simple to extract the salt chars from the
hash and run a crypt on each subscriber address to see if it matches.

Is there anyone with the Mailman project with sufficiently informed
inside contacts at AOL who could find out exactly what's going on with
AOL (and Earthlink, which I believe uses the same system) and why
(Continue reading)

Permalink | Reply |
headers
Brad Knowles | 17 Jun 2012 15:34
Favicon
Gravatar

Re: AOL redacts user addresses even with VERP and full personalization enabled

On Jun 16, 2012, at 9:58 PM, 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.

I can tell you the reasons that management gave at the time I was working there -- it was all about the privacy
of their user.  They said that they wanted to protect the privacy of the person who was complaining.

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.

Of course, this completely ignores the problem of the AOL user who hits the "This is spam" button without
knowing that they did it, or accidentally includes one of your messages when they hit that button on a whole
selection of that they want to complain about.

I've even seen people hit the "This is spam" button on individual personal messages that they got from a
member of their own family who was of the opposite political party and who was talking about politics. 
Imagine your crazy Uncle Joe ranting and raving about some political party member they like/dislike and
about whom you feel the opposite, and instead of asking them to stop or just deleting the message, you hit
the button that tells AOL that this person spammed you.

And yes, AOL knows full well just how stupid their users are.  But the customer is always right.  They stuck
their spear into the soil, and now the shakier the ground that they stand on, the more violently they must
hold onto the position that they have committed themselves to.  To do otherwise would mean that they were
admitting that they were wrong, which would make them culpable in court.

So, you and I and everyone else on the planet has to suffer because of their stupid policies.
(Continue reading)

Permalink | Reply |
headers
Lindsay Haisley | 17 Jun 2012 16:27
Favicon

Re: AOL redacts user addresses even with VERP and full personalization enabled

On Sun, 2012-06-17 at 06:34 -0700, Brad Knowles wrote:
> I can tell you the reasons that management gave at the time I was
> working there -- it was all about the privacy of their user.  They
> said that they wanted to protect the privacy of the person who was
> complaining.
> 
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?

This would, in theory, mostly satisfy AOL's privacy concern since a hash
is a one-way encryption and no one could determine the address unless
they already had access to the name in the form of the subscriber list
so that a hash comparison could be made.

I'm not asking for a feature from the devs since I can hack this myself,
just perhaps some insight into the implications for a list host that
handles no more than half a dozen small mailing lists, each with 1000
subscribers or less.

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.  All this stuff is scripted here,
and works unattended to unsubscribe complaining subscribers, so the
overhead is in programming, with a minimal amount in execution time.	

--

-- 
Lindsay Haisley       | "Real programmers use butterflies"
FMP Computer Services |
(Continue reading)

Permalink | Reply |
headers
Brad Knowles | 18 Jun 2012 05:40
Favicon
Gravatar

Re: AOL redacts user addresses even with VERP and full personalization enabled

On Jun 17, 2012, at 7:27 AM, Lindsay Haisley wrote:

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

You could do this, but the question is whether or not that header would survive through to the complaint you
get via their feedback loop.  I doubt that it would, but there's only one way to know for sure.

> I'm not asking for a feature from the devs since I can hack this myself,
> just perhaps some insight into the implications for a list host that
> handles no more than half a dozen small mailing lists, each with 1000
> subscribers or less.

It would be simple enough to write a milter that would work with postfix and sendmail to implement such a
feature, and I strongly suspect that someone else has probably already done this.  You just need to find it
and install it.

--
Brad Knowles <brad <at> shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

------------------------------------------------------
Mailman-Users mailing list Mailman-Users <at> 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/gmmu-mailman-users%40m.gmane.org
(Continue reading)

Permalink | Reply |
headers
Lindsay Haisley | 18 Jun 2012 05:47
Favicon

Re: AOL redacts user addresses even with VERP and full personalization enabled

On Sun, 2012-06-17 at 20:40 -0700, Brad Knowles wrote:
> You could do this, but the question is whether or not that header
> would survive through to the complaint you get via their feedback
> loop.  I doubt that it would, but there's only one way to know for
> sure.
> 
My observation has been that the "offending" message returned by AOL's 
feedback system contains all headers in the original message, with a
rather scattershot number of tokens "redacted".

I hacked the code and submitted a patch separately for review, if anyone
wants to review it.

--

-- 
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 <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Stephen J. Turnbull | 18 Jun 2012 10:03
Picon
Favicon

Re: AOL redacts user addresses even with VERP and full personalization enabled

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
(Continue reading)

Permalink | Reply |
headers
Lindsay Haisley | 18 Jun 2012 18:22
Favicon

Re: 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_
(Continue reading)

Permalink | Reply |
headers
Tanstaafl | 18 Jun 2012 19:04

Re: AOL redacts user addresses even with VERP and full personalization enabled

On 2012-06-18 12:22 PM, Lindsay Haisley <fmouse-mailman <at> 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 <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Lindsay Haisley | 18 Jun 2012 20:44
Favicon

Re: 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-mailman <at> 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
(Continue reading)

Permalink | Reply |
headers
David | 18 Jun 2012 20:59

Re: AOL redacts user addresses even with VERP and full personalization enabled

On Mon, Jun 18, 2012 at 2:44 PM, Lindsay Haisley <fmouse-mailman <at> fmp.com>wrote:

> On Mon, 2012-06-18 at 13:04 -0400, Tanstaafl wrote:
> > On 2012-06-18 12:22 PM, Lindsay Haisley <fmouse-mailman <at> 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.
(Continue reading)

Permalink | Reply |
headers
Lindsay Haisley | 19 Jun 2012 00:58
Favicon

Re: 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
(Continue reading)

Permalink | Reply |
headers
Lindsay Haisley | 19 Jun 2012 01:20
Favicon

Re: AOL redacts user addresses even with VERP and full personalization enabled

On Mon, 2012-06-18 at 17:58 -0500, Lindsay Haisley wrote:
> 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.

It looks as if the attachment got stripped.  Here's the script, based on
information at
http://www.codekoala.com/blog/2009/aes-encryption-python-using-pycrypto/

class AEScrypt:
	from Crypto.Cipher import AES
	from Crypto.Util import randpool
	import base64

	block_size = 16
	key_size = 32
	mode = AES.MODE_CBC
	
	def genkey(self):
		key_bytes = self.randpool.RandomPool(512).get_bytes(self.key_size)
		key_string = self.base64.urlsafe_b64encode(str(key_bytes))
		return key_string		

	def encrypt(self, plain_text, key_string):
		pad = self.block_size - len(plain_text) % self.block_size
		data = plain_text + pad * chr(pad)
		iv_bytes = self.randpool.RandomPool(512).get_bytes(self.block_size)
		encrypted_bytes = iv_bytes + self.AES.new(self.base64.urlsafe_b64decode(key_string), 
				self.mode, iv_bytes).encrypt(data)
(Continue reading)

Permalink | Reply |
headers
Stephen J. Turnbull | 19 Jun 2012 10:17
Picon
Favicon

Re: 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
(Continue reading)

Permalink | Reply |
headers
Lindsay Haisley | 19 Jun 2012 20:40
Favicon

Re: 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
(Continue reading)

Permalink | Reply |
headers
David | 19 Jun 2012 21:05

Re: AOL redacts user addresses even with VERP and full personalization enabled

On Tue, Jun 19, 2012 at 4:17 AM, Stephen J. Turnbull <stephen <at> xemacs.org>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
>  > 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.
(Continue reading)

Permalink | Reply |
headers
Lindsay Haisley | 19 Jun 2012 21:20
Favicon

Re: 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 <at> 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/gmmu-mailman-users%40m.gmane.org
(Continue reading)

Permalink | Reply |
headers
Stephen J. Turnbull | 19 Jun 2012 22:04
Picon
Favicon

Re: 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 <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Mike Starr | 19 Jun 2012 21:48
Favicon
Gravatar

Re: AOL redacts user addresses even with VERP and full personalization enabled

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   -  mike <at> writestarr.com   -  http://www.writestarr.com
President, Working Writers of Wisconsin http://www.workingwriters.org/
(Continue reading)

Permalink | Reply |
headers
Lindsay Haisley | 19 Jun 2012 23:23
Favicon

Re: 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 <maryjane <at> 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
(Continue reading)

Permalink | Reply |
headers
Mike Starr | 20 Jun 2012 21:41
Favicon
Gravatar

Re: AOL redacts user addresses even with VERP and full personalization enabled

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   -  mike <at> 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 <maryjane <at> fortuitus.net>
> wrote:
>          unsubscribe
>
> Hmph.  You can't get out that easy.
>
(Continue reading)

Permalink | Reply |
headers
Stephen J. Turnbull | 21 Jun 2012 08:50
Picon
Favicon

Re: AOL redacts user addresses even with VERP and full personalization enabled

Lindsay Haisley writes:

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

But no goats?!  Isn't that a bit risky?

Cf. https://bitbucket.org/xemacs/xemacs/src/b4715fcbe001/etc/InstallGuide

------------------------------------------------------
Mailman-Users mailing list Mailman-Users <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Lindsay Haisley | 21 Jun 2012 16:00
Favicon

Re: AOL redacts user addresses even with VERP and full personalization enabled

On Thu, 2012-06-21 at 15:50 +0900, Stephen J. Turnbull wrote:
> Lindsay Haisley writes:
> 
>  > 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:
> 
> But no goats?!  Isn't that a bit risky?

No cows, either, or ducks.  This is SCIENCE, Stephen, not agronomics.

> Cf. https://bitbucket.org/xemacs/xemacs/src/b4715fcbe001/etc/InstallGuide

> Then spit into the computer's ventilation slots.  This will complete different
> circuits inside the computer, causing its motherboard and cards to function in
> ways that the engineers never intended, thereby making your system compatible
> with our libraries.
> 

I like this part.  What engineers don't understand is that the vital
force inside all electronic devices is smoke.  All the little
jiggery-pokery whatsamadiddle parts work fine until they break open and
the smoke escapes.

--

-- 
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    |
(Continue reading)

Permalink | Reply |
headers
Brad Knowles | 18 Jun 2012 21:05
Favicon
Gravatar

Re: AOL redacts user addresses even with VERP and full personalization enabled

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.

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.

--
Brad Knowles <brad <at> shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

------------------------------------------------------
Mailman-Users mailing list Mailman-Users <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Lindsay Haisley | 18 Jun 2012 21:32
Favicon

Re: 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-somedata <at> example.com as an email address extension
of user <at> 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 <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Brad Knowles | 18 Jun 2012 22:29
Favicon
Gravatar

Re: AOL redacts user addresses even with VERP and full personalization enabled

On Jun 18, 2012, at 12:32 PM, Lindsay Haisley wrote:

> 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-somedata <at> example.com as an email address extension
> of user <at> example.com.

Okay, not technically a part of the SMTP protocol, that much I grant.

But there is already enough complexity in getting people to support just plain basic VERP.  We don't need to
go making the situation more complex than it already is, at least not as it applies to any "standard" implementation.

At least, not yet.  Gimme a working implementation that has been demonstrated to avoid tripping all sorts of
alarms and falling foul of other standard techniques (e.g., greylisting), and then maybe we can revisit
the concept of actually recommending a functional change based on our real-world experience.

--
Brad Knowles <brad <at> shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

------------------------------------------------------
Mailman-Users mailing list Mailman-Users <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Stephen J. Turnbull | 19 Jun 2012 10:25
Picon
Favicon

Re: 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 <at> python.org
http://mail.python.org/mailman/listinfo/mailman-users
(Continue reading)

Permalink | Reply |
headers
Lindsay Haisley | 19 Jun 2012 16:59
Favicon

Re: 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> <at> 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
(Continue reading)

Permalink | Reply |
headers
Stephen J. Turnbull | 19 Jun 2012 20:30
Picon
Favicon

Re: 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.
(Continue reading)

Permalink | Reply |
headers
Geoff Shang | 19 Jun 2012 20:34

Re: AOL redacts user addresses even with VERP and full personalization enabled

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 <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Stephen J. Turnbull | 19 Jun 2012 21:21
Picon
Favicon

Re: 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 <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Lindsay Haisley | 19 Jun 2012 21:07
Favicon

Re: 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.
(Continue reading)

Permalink | Reply |
headers
Stephen J. Turnbull | 19 Jun 2012 21:56
Picon
Favicon

Re: 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 <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Brad Knowles | 18 Jun 2012 19:01
Favicon
Gravatar

Re: AOL redacts user addresses even with VERP and full personalization enabled

On Jun 18, 2012, at 9:22 AM, Lindsay Haisley 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?  ;-)

--
Brad Knowles <brad <at> shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

------------------------------------------------------
Mailman-Users mailing list Mailman-Users <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Lindsay Haisley | 18 Jun 2012 19:07
Favicon

Re: 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 <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Kirke Johnson | 19 Jun 2012 16:11
Favicon

Re: AOL redacts user addresses even with VERP and full personalization enabled

I love a recursive solution.....  ;-}

Kirke Johnson                               Internet: kjohnson <at> 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-mailman <at> fmp.com>wrote:

> The irony is not lost :)  The snake eats itself tail-first until it
> disappears.
>
------------------------------------------------------
Mailman-Users mailing list Mailman-Users <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Stephen J. Turnbull | 18 Jun 2012 19:11
Picon
Favicon

Re: AOL redacts user addresses even with VERP and full personalization enabled

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.
(Continue reading)

Permalink | Reply |
headers
Lindsay Haisley | 18 Jun 2012 20:10
Favicon

Re: 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.
>
(Continue reading)

Permalink | Reply |
headers
Thomas Hochstein | 17 Jun 2012 22:19
Picon

Re: AOL redacts user addresses even with VERP and full personalization enabled

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 <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Larry Stone | 18 Jun 2012 21:06

Re: AOL redacts user addresses even with VERP and full personalization enabled

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
    lstone19 <at> stonejongleux.com
------------------------------------------------------
Mailman-Users mailing list Mailman-Users <at> 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/gmmu-mailman-users%40m.gmane.org
(Continue reading)

Permalink | Reply |
headers
Brad Knowles | 18 Jun 2012 22:23
Favicon
Gravatar

Re: AOL redacts user addresses even with VERP and full personalization enabled

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 <brad <at> shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

------------------------------------------------------
Mailman-Users mailing list Mailman-Users <at> 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/gmmu-mailman-users%40m.gmane.org
(Continue reading)

Permalink | Reply |
headers
Lindsay Haisley | 19 Jun 2012 19:52
Favicon

Re: 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
(Continue reading)

Permalink | Reply |
headers
Brad Knowles | 19 Jun 2012 20:13
Favicon
Gravatar

Re: AOL redacts user addresses even with VERP and full personalization enabled

On Jun 19, 2012, at 10:52 AM, Lindsay Haisley wrote:

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

Yes.  ;-)

Seriously, I think the TOS specifically prohibits you from taking any action based on the address of the
recipient who filed the complaint.  Which matters to the point that you care about abiding by their TOS and
what they can do to you if they discover that you have violated their TOS.

To their credit, AOL has always had plenty of money for good lawyers, and they've certainly gone through
plenty of contracts, etc... over the years.  So, it makes sense that they would actually be aware of such
distinctions and word their TOS appropriately.

--
Brad Knowles <brad <at> shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

------------------------------------------------------
Mailman-Users mailing list Mailman-Users <at> 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/gmmu-mailman-users%40m.gmane.org
(Continue reading)

Permalink | Reply |
headers
William Yardley | 20 Jun 2012 00:51
Favicon

Re: AOL redacts user addresses even with VERP and full personalization enabled

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 <at> 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/gmmu-mailman-users%40m.gmane.org
(Continue reading)

Permalink | Reply |
headers
Lindsay Haisley | 20 Jun 2012 01:36
Favicon

Re: 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          |
(Continue reading)

Permalink | Reply |
headers
Dave (FitEyes | 20 Jun 2012 01:56

Re: AOL redacts user addresses even with VERP and full personalization enabled

On Tue, Jun 19, 2012 at 6:51 PM, William Yardley
<mailman <at> veggiechinese.net>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 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
(Continue reading)

Permalink | Reply |
headers
Lindsay Haisley | 17 Jun 2012 06:57
Favicon

Re: AOL redacts user addresses even with VERP and full personalization enabled

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.  The only explanations
that come to mind are very sinister ones, but given the way things are
going these days, it may indeed be that AOL is truly trying to break the
Internet mail system so that they and their ilk can try to rebuild it
according to their own (for profit) model.

As of April 4, I was still receiving AOL's Email Feedback Reports with
the sender and return-path addresses improperly redacted in included
subject emails so that I could parse out the complaining subscriber.
e.g.:

Return-Path: <redacted-bounces+johndoe=aol.com <at> lists.local-list.com>

These reports are fairly rare these days, and I haven't received any of
them from AOL since then, although I'm subscribed to their reports for
both of my servers.  If AOL is now fully redacting subscriber
information then indeed perhaps the only way to identify the complaining
subscriber is by tracing the Message ID through the mail log files.
Another alternative might be to add a header to outgoing messages to
include the subscriber address as a hash in an X-something header.
Assuming the management of AOL complaining subscribers via their Email
Feedback Reports is automated at the list server (as it is here) it
should be relatively fast and simple to extract the salt chars from the
hash and run a crypt on each subscriber address to see if it matches.

Is there anyone with the Mailman project with sufficiently informed
inside contacts at AOL who could find out exactly what's going on with
AOL (and Earthlink, which I believe uses the same system) and why
(Continue reading)

Permalink | Reply |
headers
Russell Clemings | 20 Jun 2012 02:17
Picon

Re: AOL redacts user addresses even with VERP and full personalization enabled

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 <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Brad Knowles | 20 Jun 2012 02:28
Favicon
Gravatar

Re: AOL redacts user addresses even with VERP and full personalization enabled

On Jun 19, 2012, at 5: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 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

I haven't read the page in question in the last few years, but assuming what you've quoted is accurate then
this would be a "recent development" in the life of the AOL FBL as I know it.

--
Brad Knowles <brad <at> shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

------------------------------------------------------
Mailman-Users mailing list Mailman-Users <at> 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/gmmu-mailman-users%40m.gmane.org
(Continue reading)

Permalink | Reply |
headers
Dave (FitEyes | 20 Jun 2012 02:42

Re: AOL redacts user addresses even with VERP and full personalization enabled

On Tue, Jun 19, 2012 at 8:17 PM, Russell Clemings <rclemings <at> gmail.com>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 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 <at> 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
(Continue reading)

Permalink | Reply |
headers
Lindsay Haisley | 20 Jun 2012 02:55
Favicon

Re: 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 <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Dave (FitEyes | 20 Jun 2012 03:07

Re: AOL redacts user addresses even with VERP and full personalization enabled

On Tue, Jun 19, 2012 at 8:55 PM, Lindsay Haisley <fmouse-mailman <at> fmp.com>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 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 <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Lindsay Haisley | 20 Jun 2012 05:58
Favicon

Re: 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-mailman <at> 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
(Continue reading)

Permalink | Reply |
headers
Stephen J. Turnbull | 20 Jun 2012 07:39
Picon
Favicon

Re: 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 <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Lindsay Haisley | 20 Jun 2012 08:11
Favicon

Re: 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
(Continue reading)

Permalink | Reply |
headers
Stephen J. Turnbull | 20 Jun 2012 08:42
Picon
Favicon

Re: AOL redacts user addresses even with VERP and full personalization enabled

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 <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Lindsay Haisley | 20 Jun 2012 02:54
Favicon

Re: 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 <at> 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/gmmu-mailman-users%40m.gmane.org
Permalink | Reply |
headers
Russell Clemings | 21 Jun 2012 03:23
Picon

Re: AOL redacts user addresses even with VERP and full personalization enabled

>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 <fmouse <at> fmp.com>
> To: mailman-users <at> 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"
(Continue reading)

Permalink | Reply |
headers
Lindsay Haisley | 21 Jun 2012 03:52
Favicon

Re: 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,
(Continue reading)

Permalink | Reply |

Gmane