Bill, thank you for this excellent explanation, and for the kind words! For those of you who don't know us, or me, I came out of MAPS; I was in-house counsel for MAPS during the first rash of lawsuits against MAPS brought by spammers. To say that I am rabidly anti-spam would be an understatement.
ISIPP, and our SuretyMail service, were founded by me a year and a bit after I left MAPS. As such, our priority has always been, and remains, first and foremost, to the *receivers* - ISPs, spam filters, and any receiver who is using our data/zones. It is true that the senders are our paying customers, however by design the amount of monies we receive from any given customer is small enough that the pleasure of whacking a spammer far outweighs any downside of giving a paying customer the boot if they are not doing The Right Thing. Plus, we have a very extensive background check that we put a potential customer (sender) through before we will certify them. We reject plenty of applicants. > However, the different responses from IADB are VERY nuanced and the two > strongest rules you listed (RCVD_IN_IADB_OPTIN and RCVD_IN_IADB_VOUCHED) are > essentially "good intentions" markers. > Due to unfortunate terminology choices by ISIPP and a willingness to engage > in nuance and estimate intentions, those aren't really as worthwhile as they > might seem. Hey Bill - can you please elaborate on the terminology choices which you see as unfortunate? We are *always* open to input. Where we say "opt-in" we mean exactly that - single opt-in; if someone didn't ask for the email not only would we call that "opt-out", but we would not certify that sender's email. And if one of our senders is sending spam where they claim that all of their mailings are 100% opt-in (at least) we want to know, because...whack! Seriously, we are always open to feedback, and if a change in terminology is warranted we have no problem doing that (we also are happy to create a custom zone based on whatever the receiver wants for those who would like zones with highly specific profiles of the IPs therein - some receivers do that because they can't take advantage of the granularity of the data in our zones (although that is not the case for SA...in fact our data response codes were *specifically* created for SA because SA *can* take advantage of that level of granularity)). Anne Anne P. Mitchell, Attorney at Law CEO/President, SuretyMail Email Reputation Certification and Inbox Delivery Assistance http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Attorney at Law / Legislative Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Author: The Email Deliverability Handbook Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Member, California Bar Cyberspace Law Committee Member, Colorado Cybersecurity Consortium Member, Board of Directors, Asilomar Microcomputer Workshop Member, Advisory Board, Cause for Awareness Member, Elevations Credit Union Member Council Former Chair, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Available for consultations by special arrangement. amitch...@isipp.com | @AnnePMitchell Facebook/AnnePMitchell | LinkedIn/in/annemitchell
