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.

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.

No, they're much too short-sighted for that. And they're not smart enough for that, either.

You should not assume sinister (but intelligent) motives when plain corporate stupidity will suffice.

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 they're doing this?

All my contacts are outdated. Everyone I knew who worked there has long since moved on. But that doesn't change the reasons that were given at the time, nor the reasons why they continue to follow the same stupid policies.

It might be worth noting that one of the several lists I host will not accept subscriptions from AOL addresses because of their problem policies. What with gmail accounts being free and easy to get, AOL is simply cutting themselves out of the loop in the long run with their policies. No loss there!

I'm not surprised. AOL doesn't care about those small percentages of loss for that one product. That's trivial compared to the value of the company as a whole if they were to admit that they were wrong with a result of getting their ass dragged into many more court cases.

I know the guy who was the SRE for Gmail, and on the technical side they still have some people who care and have a clue. I do feel that Google is the Next Great Evil in this world, but that doesn't change the facts of the technical implementation of their mail system relative to AOL. Of course, that's not saying much….

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

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

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 |

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 |

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

On 2012-06-18 12:22 PM, Lindsay Haisley <fmouse-mailman@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?

On Mon, Jun 18, 2012 at 2:44 PM, Lindsay Haisley <fmouse-mailman@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@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?

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)
	return self.base64.urlsafe_b64encode(str(encrypted_bytes))

def decrypt(self, cypher_text, key_string):
	key_bytes = self.base64.urlsafe_b64decode(key_string)
	encrypted_bytes = self.base64.urlsafe_b64decode(cypher_text)
	iv_bytes = encrypted_bytes[:self.block_size]
	encrypted_bytes = encrypted_bytes[self.block_size:]
	plain_text = self.AES.new(key_bytes, self.mode, iv_bytes).decrypt(encrypted_bytes)
	pad = ord(plain_text[-1])
	return plain_text[:-pad]

-- Lindsay Haisley | "In an open world, who needs
FMP Computer Services | Windows or Gates" 512-259-1190 | http://www.fmp.com |

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

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 |

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@writestarr.com - http://www.writestarr.com President, Working Writers of Wisconsin http://www.workingwriters.org/

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

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 |

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

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

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

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!

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.

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.

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

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

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

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