NYCPHP Meetup

[bzcoder]

Mark Armendariz wrote:
>
>> Received: from ne3.nyphp.com ([207.58.185.222]:48172)
>>     by cl38.gs02.gridserver.com with esmtps 
>> (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32)
>>     (Exim 4.63)
>>     (envelope-from <jobs-bounces at lists.nyphp.org>)
>>     id 1KT3E1-0004Vs-TV
>>     for bzcoder at bzcode.com; Tue, 12 Aug 2008 16:24:27 -0700
>>
>> To determine that despite this email coming to my private email box, 
>> it was sent to my public bzcoder throwaway address.
>>
>> BTW, this especially applies for commercial email as you don't want 
>> people to start hitting the "this is spam" button in frustration.
>
> This reminds me of a thought I had the other day.  Wouldn't it make 
> sense to add an "unsubscribe" field to the email spec, which would 
> allow spam blockers to start an "auto-unsubscribe" conversation with 
> the originating sender before explicitly marking it as spam?  Would 
> also allow a default "unsubscribe" button in all email clients.  I 
> hate to think of how many legitimate mailing lists have been marked as 
> spam as a simplified (and reliable) means to unsubscribe.


I've copied this over to the NYPHP list since it is not "job" related.

No, it would not make any sense at all to add such a field to the email 
spec.  Mainly because there already IS such a field. :-)

_See http://www.ietf.org/rfc/rfc2369.txt for the spec.

 From the spec, my preferred implementation is a take on

___

List-Unsubscribe: <http://www.host.com/list.cgi?cmd=unsub&lst=list>,
         <mailto:list-request at host.com?subject=unsubscribe>

However you should include some identifying information in both those 
fields to make life easy.

Ie add a "uid=someid&idverify=verifycode"

The idverify can be as simple as a crc hash of the email address, the 
basic idea here[and mind you, I speak from the commercial emailer 
perspective where every unsub is lost circulation which means less 
advertising revenue.] is to keep yahoo's from cycling through every 
charector combination for userids and unsubbing all your users!  By 
adding a verify code, you can ensure the id is for that address.  [Note: 
the simple solution is to make it
uid=recipent at host.com - ie make it their email address.  That works 
right up until some giant email provider decides to start stripping 
recipeint addresses from email "just in case" it is forwarded and 
replacing it with EMAIL.]

There is a company out there that makes a plug in for outlook that has a 
"get me off this list" button.  It checks the email message and using a 
number of string detection logics, including checking for this header, 
it will try to automatically unsubscribe you from a message.

Since my main ESP does not support this feature[grumble] I haven't done 
much testing, but I'm told that some of the major webmail providers also 
include an "unsubscribe" button when this field is present.  If given 
the option to hit "unsubscribe" or "report spam" users will tend towards 
unsub, which helps on deliberability to everyone else on that mail network.

Now, to bring this subject around marginally to PHP:
PHPList, the open source PHP newsletter management application is a bit 
of an odd duck.  If you send mail /directly/ it will generate the 2369 
fields for the headers.  However, if you send mail through PHPMailer, it 
does not.  It's an easy item to patch, so if some young PHP coder would 
like to submit a patch to them I'm guessing it would be appreciated.  I 
haven't done so myself because every time I go into that code, I start 
seeing a dozen things to fix/change and then get interrupted by paying work.