Hi,
What is the best way to deal with feedback loop messages where the provider has redacted the email address of the party who filed the complaint?
Does Mailman have any built in methods on dealing with this issue?
At the moment we "force" a custom footer on all messages which includes the recipients email address, and the list they belong to, but recently a few ISPs have even been redacting data in that part of the message.
Thanks in advance!
Best Regards, Peter Knowles TPN Solutions
Email: pknowles@tpnsolutions.com Phone: 604-229-0715 Skype: tpnsupport Website: http://www.tpnsolutions.com
Peter Knowles writes:
What is the best way to deal with feedback loop messages where the provider has redacted the email address of the party who filed the complaint?
What do you want to do with this information? Just unsubscribe that user? I'd say pass the buck back to the provider.
First, you need to be sure that you have not passed any spam, and second that your mailman host DKIM signs all its mail. You must have a subscribe and confirm-by-email process. If all that is true, then you can make a reasonable case that the user really just wants to unsubscribe, and did subscribe themselves in the first place. Write to the postmaster at the provider (or whoever the contact is), and send them your unsubscribe link, and tell them to pass it on to the user.
If they won't do that, write a "more in sorrow than in anger" message to the list explaining that Beavis and Butthead ISP is about to ban your list due to spurious complaints, that they won't help their users unsubscribe and conceal the information required for the list admin to do it, and so you are setting all of their users to nomail. Then do it. You're not hurting anybody, because if you don't do this, the ISP will ban you and they're effectively off the list anyway.
This isn't 100% effective, because it's quite possible that the subscribed address is in a different domain, and is just forwarding to B&B.net.
If you're actually sending commercial email (solicited, of course!) and that would hit your bottom line, I'm sorry, but you're screwed. You just keep going and hope they don't ban you.
Does Mailman have any built in methods on dealing with this issue?
No. This is a people problem, and the broken brains are not at your site. There's no automatic fix.
At the moment we "force" a custom footer on all messages which includes the recipients email address, and the list they belong to, but recently a few ISPs have even been redacting data in that part of the message.
Since you have full personalization set on, each recipient is getting a different message, and therefore each message goes in a separate SMTP transaction, and will have a separate Received line (for receipt *from* Mailman) and a separate MTA queue number. Your MTA log should be able to tell you where it went.
If they're redacting the trace headers, well, again, there's nothing you can do.
Regards,
On Mon, 2014-08-18 at 12:33 +0900, Stephen J. Turnbull wrote:
Peter Knowles writes:
What is the best way to deal with feedback loop messages where the provider has redacted the email address of the party who filed the complaint?
What do you want to do with this information? Just unsubscribe that user? I'd say pass the buck back to the provider.
I've had to deal with this with AOL subscribers. I have scripts which try to pull the VERPed recipient address out of various headers in the feedback loop messages and unsubscribe the complaining subscriber, but the redaction algorithm is inconsistent, which makes it difficult. I ended up hacking the MM source to create an AES crypt of the subscriber and the list name and putting this into the (RFC-spec'd but seldom used) Resent-Message-ID header. The AES secret key is put into mm_cfg.py.
If you grok MM internals a bit and understand withlist and python, and don't mind importing the Python Crypto library I can send you the information on this hack, but I'd rather turn it over to the MM people for some sort of public posting so everyone can have a go at it, and I might not be the only person who could answer questions about it when people have them.
-- Lindsay Haisley | "Everything works if you let it" FMP Computer Services | 512-259-1190 | --- The Roadie http://www.fmp.com |
Lindsay Haisley writes:
If you grok MM internals a bit and understand withlist and python, and don't mind importing the Python Crypto library I can send you the information on this hack, but I'd rather turn it over to the MM people for some sort of public posting so everyone can have a go at it, and I might not be the only person who could answer questions about it when people have them.
I think having an easily available patch is a great idea, but I fear if it's part of the official distribution, the redactors will redact that, too.
On Sun, Aug 17, 2014 at 04:55:52PM -0700, Peter Knowles wrote:
What is the best way to deal with feedback loop messages where the provider has redacted the email address of the party who filed the complaint?
I haven't looked at a FBL message for a while, but most of the ones I've seen didn't munge all the queue IDs in the past, so even without personalization, you should be able to tell from the logs, at least if you set the SMTP concurrency low enough.
I think munging the headers is a sensible practice, as it makes it a little harder to listwash; the main idea of the FBL as I understand it is to give you an idea when there's some kind of gross abuse, not that you are required to unsubscribe anyone who complains about your mail.
w
I think munging the headers is a sensible practice, as it makes it a little harder to listwash; the main idea of the FBL as I understand it is to give you an idea when there's some kind of gross abuse, not that you are required to unsubscribe anyone who complains about your mail.
Munging FBLs is actually fairly stupid, since everyone knows that any sender can hide coded versions of the recipient address somewhere in the message, and most ESPs do.
The ISPs I've talked to have told me that their lawyers say they have to do it because the party getting the FBL might not be the same as the sender, or something.
As far as what recipients are supposed to do, they want the complaints to stop. They don't care how you do it.
R's, John
On Mon, 2014-08-18 at 18:22 +0000, John Levine wrote:
I think munging the headers is a sensible practice, as it makes it a little harder to listwash; the main idea of the FBL as I understand it is to give you an idea when there's some kind of gross abuse, not that you are required to unsubscribe anyone who complains about your mail.
Munging FBLs is actually fairly stupid, since everyone knows that any sender can hide coded versions of the recipient address somewhere in the message, and most ESPs do.
The ISPs I've talked to have told me that their lawyers say they have to do it because the party getting the FBL might not be the same as the sender, or something.
I have an automated system I built as a hack on MM to intercept FBL messages, identify the list, the subscriber, unsubscribe the subscriber from the list and send a notice to the list owner (thank you, withlist! ). I brought the subject up on the MM developers' list last year some time ago, and someone mentioned that they'd talked to AOL people who weren't particular about this, and weren't interested in removing all traces of the complaining subscriber address, just the obvious ones, and they had no problem if people wanted to include the information in an encrypted format. So I guess it's the same with them and the redaction is done to make the legal dept. happy. AFAIAC, any subscriber to any list that I host for anyone who's too clueless or lazy to use the prescribed methods for unsubscribing from a MM list, and just hits the "Report Spam" button, can't be dropped from the list fast enough!
My hack puts an AES encrypted concatenation of the subscriber address and the list name in the (RFC spec'd but seldom used) Resent-Message-ID header. The AES secret key is stored in mm_cfg.py.
-- Lindsay Haisley | "Everything works if you let it" FMP Computer Services | 512-259-1190 | --- The Roadie http://www.fmp.com |
Will Yardley writes:
I think munging the headers is a sensible practice, as it makes it a little harder to listwash; the main idea of the FBL as I understand it is to give you an idea when there's some kind of gross abuse,
That's what they say, but in many cases that's not what they do. In particular, when one of *their* users hits the spam button on a mail they requested which has the unsubscribe address in the footer, that's "gross abuse" by the subscriber. However, that's not the kind of gross abuse that a list or site admin can do anything about. Why is it being reported by the feedback loop? Can you be sure it's not a component of your host's reputation that could cause your list to be blocked at that destination?
not that you are required to unsubscribe anyone who complains about your mail.
What "required"? It's a common preference of list owners that gross abusers have their subscriptions terminated. And the threat is clear: the provider considers *their* user's misbehavior to be the fault of the *list*, otherwise there's no point in reporting "feedback".
YMMV, of course, but that's the way I and many other list admins see it. As a Mailman developer, I think that if there's a sane way to help deal with this, Mailman should provide it.
Regards,
participants (5)
-
John Levine -
Lindsay Haisley -
Peter Knowles -
Stephen J. Turnbull -
Will Yardley