>
> On Thu, 1 Mar 2018, Sebastian Arcus wrote:
>
>> I know I have brought up this issue on this list before, and sorry for the
>> persistence, but having 7 different rules adding scores for the IADB
>> whitelist still seems either ridiculous, or outright suspect:
>>
>> -0.2 RCVD_IN_IADB_RDNS RBL: IADB: Sender has reverse DNS record
>> [199.127.240.84 listed in iadb.isipp.com]
>> -0.1 RCVD_IN_IADB_SPF RBL: IADB: Sender publishes SPF record
>> -0.1 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in
>> -0.0 RCVD_IN_IADB_SENDERID RBL: IADB: Sender publishes Sender ID record
>> -0.0 RCVD_IN_IADB_LISTED RBL: Participates in the IADB system
>> -0.1 RCVD_IN_IADB_DK RBL: IADB: Sender publishes Domain Keys record
>> -0.1 RCVD_IN_IADB_VOUCHED RBL: ISIPP IADB lists as vouched-for sender
>>
>>
>> It really raises some very uncomfortable questions regarding the
>> impartiality of SA and/or its anti-spam capabilities. And by the way, this
>> message is definitely unsolicited, and in now way we gave any sort of
>> permission or consent to this company or its "affiliates" to email us - so
>> the whole "All mailing list mail is opt-in" is nonsense.
>>
>> And why have "Sender has reverse DNS record" and "Sender publishes SPF
>> record" as separate IADB rules - when SA itself already checks for these?
>> Isn't this just a glaring way of pumping up SA scores for the IADB
>> subscribers?
>
> Don't assume malice right off the bat. More likely it is that IADB provides
> all those status codes and SA exposes a rule for each, with minimal scores,
> to allow local tuning if desired.
>
> Also, there is RCVD_IN_IADB_DOPTIN, so RCVD_IN_IADB_OPTIN may be "someone
> somehow gave us your name somewhere" (i.e. "single opt-in") rather than "we
> confirmed you actually want to receive our garbage" ("double opt-in").
>
> The scores appear hardcoded (50_scores.cf) vs. from masscheck (72_scores.cf)
> so they may be *very* stale.
The IADB codes were designed in conjunction with Craig Hughes, who at the time
was very involved with SA, for the specific purpose of allowing SA, and other
systems like SA, to take advantage of the very granular nature of the codes
for, as John observes, local (and very fine) tuning. It is not up to us to
tell receivers what email they should and should not choose to deliver - it is
up to us to give receivers as much *useful* information as possible. Some
receivers actually want to deliver single opt-in mail so long as they can
confirm enough other data points about the email and the sender themselves.
In fact, many of our data response codes were developed at the request of
receivers such as SA, Spamcop, and others.
One of the reasons that we receive the scores that we do is because we are a
trusted source of data (for which we are very proud) - because I came out of
MAPS (I was their in-house counsel), and any email person in our org comes from
the anti-spam side as well - we all view our first responsibility as being to
the receivers who use our data, not the senders who are certified with us.
Too, folks in the receiving industries know that we take abuse reports (we
don't receive many, but of course we do receive some) *very* seriously, and
have no problem firing a sender if they stray to the dark - or heck, even gray
or slightly soiled white - side. (It helps that we have no contract, and no
sender pays us very much, so it's very easy to fire them and there is no
financial incentive to keep any particular sender on. ;-) )
We make sure that our senders are - and stay - white hat. We are unique in
that way, and that was the promise when we worked with SA in the beginning, and
we have kept that promise.
Anyone applying for certification with us has to pass a stringent, exhaustive
background check in terms of their mailing practices, their email reputation,
etc..
Relatedly, and somewhat humourously, if you look at our codes, they include
codes such as:
127.3.100.2 Accepts unverified sign-ups such as through web page
127.3.100.3 Accepts unverified sign-ups, gives chance to opt out
Of *course* we would *never* certify anyone to whom those codes would apply,
but *they* don't know that - those codes are there as 'trick questions', if you
will. Anyone applying for certification who checks those boxes doesn't even
get in the door, let alone through our background check.
P.S. You will probably have noted in my .sig that I authored part of CAN-SPAM.
While CAN-SPAM is essentially a joke for the most part, I'm actually very
proud of the work I did on Section 6* - it's one of the few aspects of CAN-SPAM
with teeth - it's the vendor liability section, which actually means the "you
don't get to run an affiliate program and look the other way while you profit
from your affiliates spamming - we're looking at you Gevalia" section." (*For
those of you who are also law/policy wonks, text of Section 6 available upon
request. :-) )
My point is - I am, and we are, about as rabidly anti-spam as they come. And
that's why we have the scores that we do. Because we worked hard to earn that
trust, we are trustworthy, approachable, transparent and, most importantly, on
the right side of the fight.
Anne
Anne P. Mitchell,
Attorney at Law
CEO/President,
SuretyMail Email Reputation Certification
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
