[Mailman-Users] slightly OT: on not becoming a spam source

Jonathan Dill jonathan at nerds.net
Fri May 30 23:00:40 CEST 2008

On May 30, 2008, at 11:00 AM, David Newman wrote:

> On 5/30/08 4:35 AM, Larry Stone wrote:
>> On 5/29/08 11:37 PM, Jim Popovitch at yahoo at jimpop.com wrote:
>>> On Fri, May 30, 2008 at 12:18 AM, David Newman <dnewman at networktest.com 
>>> >
>>> wrote:
>>>> Hmmm. I must be missing something, as the system is still  
>>>> associating each
>>>> Message-ID with all 250 list subscribers.
>>> VERP has nothing to do with Message-ID, and everything to do with
>>> Return-Path and Sender:   ;-)
>> With VERP and personalization, the Return-Path, instead of being
>> "listname-bounces at sendingdomain" becomes
>> "listname-bounces+recipient=destdomain at sendingdomain".
>> I think you said you're using Postfix in which case you need
>> "recipient_delimiter = +" in your main.cf so it knows about the  
>> plus signs
>> in the return paths.
> ACK. Yes, that's in main.cf.
>> When you then get the AOL TOS e-mail, you can figure out who the list
>> recipient was as while AOL redacts the AOL recipient, they don't  
>> touch the
>> Return-Path.
> I wish this were true, but it appears AOL gets to the Return-Path too:
> Return-Path: <redacted-bounces+redacted=aol.com at somedomain.com>
> So neither Return-ID nor Message-ID identifies who's complaining.
> But...this might be something. The next message header contains an  
> ESMTP ID that corresponds with exactly one AOL user in maillog:
> Received: from rly-mh07.mx.aol.com (rly-mh07.mail.aol.com  
> []) by air-mh02.mail.aol.com (v121.4) with ESMTP id  
> MAILINMH024-be4483f8d3acf; Fri, 30 May 2008 01:14:45 -0400
> Received: from mail.somedomain.com (mail.somedomain.com  
> [666.666.666.666]) by rly-mh07.mx.aol.com (v121.5) with ESMTP id  
> MAILRELAYINMH074-be4483f8d3acf; Fri, 30 May 2008 01:14:35 -0400
> Received: from localhost (localhost [])
> 	by mail.somedomain.com (Postfix) with ESMTP id B55685B31C0
> 	for <redacted>; Thu, 29 May 2008 22:14:34 -0000 (UTC)
> root at mail:log# grep -i B55685B31C0 /var/log/maillog
> May 29 22:14:34 mail postfix/smtpd[25785]: B55685B31C0:  
> client=localhost[]
> May 29 22:14:34 mail postfix/cleanup[21262]: B55685B31C0: message- 
> id=<C464D8CB.705B%listposter at someotherdomain.net>
> May 29 22:14:34 mail postfix/qmgr[23040]: B55685B31C0: from=<members-bounces+aoluser=aol.com at somedomain.com 
> >, size=13344, nrcpt=1 (queue active)
> Given the above, is "aoluser at aol.com" the subscriber that's  
> complaining? Or is it just a coincidence that that AOL user got  
> listed first?

Ostensibly, AOL does this to prevent listwashing, but it's not exactly  
helpful.  I think AOL strips out a lot of the message headers in the  
TOS reports, so you don't get all of the Received headers and message- 
ids.  How I dealt with it is that I made a custom footer in the VERP  
configuration that says something like:

This e-mail was delivered to foobar at aol.com

I suppose that it would be better if you could somehow stick that in  
to a hash that only you could decipher, especially if AOL decides at  
some point to strip all e-mail addresses out of the messages, but it's  
better than nothing.

That shows up in the TOS messages, I stuff them all into a mailbox and  
then have a script that grabs the addresses from the footer and  
unsubscribes those addresses.

I also got some good advice I think from someone on this list to put a  
"gentle reminder" at the top of each message with the unsub links etc  
right there.  It says something like "You are receiving this message  
because you subscribed to the blah blah newsletter on the example.com  

Also, maybe you are already doing this, but a gentle reminder for you  
that may help with these AOL reports, you should absolutely require  
people to confirm their subscription and not just add them to the  
mailing list, even if they provided their e-mail address some other  
way for example filled out a comment card at an event.  If people  
can't be bothered to confirm their subscription, then they can't be  
bothered to follow the instructions to unsubscribe either and will  
just click the "Report Spam" button when they no longer wish to  
receive the newsletter.  Things used to be different, but now days  
failing to confirm subscriptions can get you blacklisted, and even  
your website taken offline.  That actually happened to someone who  
ignored my insistence that they should require confirmations, arguing  
that it would be "too difficult" for their newsletter subscribers.

> many thanks
> dn
> ------------------------------------------------------
> Mailman-Users mailing list
> Mailman-Users at python.org
> http://mail.python.org/mailman/listinfo/mailman-users
> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
> Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe: http://mail.python.org/mailman/options/mailman-users/jonathan%40nerds.net
> Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&amp;file=faq01.027.htp

More information about the Mailman-Users mailing list