This comment:

> First request is to update the reference - we purchased Bonded Sender from
> Bonded Sender to Sender Score Certified. A suggested edit would be:

Should have said:

First request is to update the reference - we purchased Bonded Sender from
Ironpor and renamed Bonded Sender to Sender Score Certified.  A suggested edit
would be:

assuming RCVD_IN_SSC_TRUSTED_COI has the same confirmed-opt-in criteria as
HABEAS_ACCREDITED_COI, then -8.0 sounds fair -- it matches the other rule's score.

I'm not 100% sure about changing the names of the existing rules to
RCVD_IN_SSC_* though, since people may have local customisations (score changes
etc.) hmm.

(In reply to comment #2)
> assuming RCVD_IN_SSC_TRUSTED_COI has the same confirmed-opt-in criteria as
> HABEAS_ACCREDITED_COI, then -8.0 sounds fair -- it matches the other rule's score.
> 

Yes, the criteria seem to match.  Our standard:

http://www.senderscorecertified.com/standards_plus.html

Consent

V. Participating Senders must ensure that consent with appropriate
disclosure exists prior to sending Commercial or Promotional Email
Messages.

   1. The only acceptable form of consent is Double Opt-In (sometimes
referred to as 'Confirmed Opt-In'). The Recipient must affirmatively
request to add his/her email address to a mailing list. The Recipient
must receive a confirmation email and the Recipient must confirms
his/her request by replying or visiting a provided URL.

-----------------------------------

Also, it seems that in our case, the scoring may have to be additive.
Currently an IP address that meets our COI standards is published in
both zones, the plus.bondedsender.org zone for COI IP addresses, and the
query.bondedsender.org zone for all qualifying member IP addresses.  The
query.bondedsender.org zone is the same as the two you query, sa-trusted
and sa-other.bondedsender.org.

So would it be proper to simply add an additional -3.7 for a positive on
plus.bondedsender.org to the -4.3 default on a positive
sa-trusted.bondedsender.org check?  

Not sure what you want to do on the sa-other if that IP is a COI IP or not.

> I'm not 100% sure about changing the names of the existing rules to
> RCVD_IN_SSC_* though, since people may have local customisations (score changes
> etc.) hmm.

(In reply to comment #2)
> assuming RCVD_IN_SSC_TRUSTED_COI has the same confirmed-opt-in criteria as
> HABEAS_ACCREDITED_COI, then -8.0 sounds fair -- it matches the other rule's score.
> 
> I'm not 100% sure about changing the names of the existing rules to
> RCVD_IN_SSC_* though, since people may have local customisations (score changes
> etc.) hmm.


Good point.  It is actually the same reason we've not changed the zone
names on our side.  I suppose there is no precedent in SA then for
renaming a rule?  

Moving items off the 3.2.1 queue to 3.2.2 to facilitate a quick release.
If you can get this in Review status right away feel free to move it back

3.2.3 was released without these fixed, moving to 3.2.3

hey Tom, just getting around to this. :(

(In reply to comment #3)
> Also, it seems that in our case, the scoring may have to be additive.
> Currently an IP address that meets our COI standards is published in
> both zones, the plus.bondedsender.org zone for COI IP addresses, and the
> query.bondedsender.org zone for all qualifying member IP addresses.  The
> query.bondedsender.org zone is the same as the two you query, sa-trusted
> and sa-other.bondedsender.org.
> 
> So would it be proper to simply add an additional -3.7 for a positive on
> plus.bondedsender.org to the -4.3 default on a positive
> sa-trusted.bondedsender.org check?  

ok, that works, and makes sense.

> Not sure what you want to do on the sa-other if that IP is a COI IP or not.

Best to ignore it entirely, and make the COI lookup similar to BSP_TRUSTED;
it only applies to the external-to-internal "firsttrusted" handover. (Any
Received headers after that point are trivially forged, which is why BSP_OTHER
has such a miniscule score; it's purely informational.)

> > I'm not 100% sure about changing the names of the existing rules to
> > RCVD_IN_SSC_* though, since people may have local customisations (score changes
> > etc.) hmm.
> 
> Good point.  It is actually the same reason we've not changed the zone
> names on our side.  I suppose there is no precedent in SA then for
> renaming a rule?  

There is, but it's exceptionally painful, esp for users, so we avoid it if at
all possible.  Changing rule description strings, on the other hand, is easy.

More questions:

- are there test IP addresses in plus.bondedsender.org.?   I can't seem
  to find any.

- also, is there tech documentation on that zone (query using TXT/A lookups,
  result formats, etc.)?

Created attachment 4095 [details]
work in progress

this isn't ready; I think I have the wrong zone.  but it's partially there...

(In reply to comment #6)
> hey Tom, just getting around to this. :(
> 
> (In reply to comment #3)
> > Also, it seems that in our case, the scoring may have to be additive.
> > Currently an IP address that meets our COI standards is published in
> > both zones, the plus.bondedsender.org zone for COI IP addresses, and the
> > query.bondedsender.org zone for all qualifying member IP addresses.  The
> > query.bondedsender.org zone is the same as the two you query, sa-trusted
> > and sa-other.bondedsender.org.
> > 
> > So would it be proper to simply add an additional -3.7 for a positive on
> > plus.bondedsender.org to the -4.3 default on a positive
> > sa-trusted.bondedsender.org check?  
> 
> ok, that works, and makes sense.

Great.  One down.  :)

> 
> > Not sure what you want to do on the sa-other if that IP is a COI IP or not.
> 
> Best to ignore it entirely, and make the COI lookup similar to BSP_TRUSTED;
> it only applies to the external-to-internal "firsttrusted" handover. (Any
> Received headers after that point are trivially forged, which is why BSP_OTHER
> has such a miniscule score; it's purely informational.)

This makes sense too.  Two down.

> 
> > > I'm not 100% sure about changing the names of the existing rules to
> > > RCVD_IN_SSC_* though, since people may have local customisations (score
changes
> > > etc.) hmm.
> > 
> > Good point.  It is actually the same reason we've not changed the zone
> > names on our side.  I suppose there is no precedent in SA then for
> > renaming a rule?  
> 
> There is, but it's exceptionally painful, esp for users, so we avoid it if at
> all possible.  Changing rule description strings, on the other hand, is easy.

That all makes sense.  I've reviewed the attachement here:

http://issues.apache.org/SpamAssassin/attachment.cgi?id=4095

and this all looks great as is.

> More questions:
> 
> - are there test IP addresses in plus.bondedsender.org.?   I can't seem
>   to find any.

127.0.0.2 wasn't in the plus zone so I've added it and you should be able to
test.  Sorry about that.

> 
> - also, is there tech documentation on that zone (query using TXT/A lookups,
>   result formats, etc.)?
>

There is some though it probably needs updating.  If you have any input on
instructions for SA 3.2 that would be great.  Let me know questions either way:

http://www.senderscorecertified.org/senderscorecertified/technical.php

Let me know how else I can help.  When do you think 3.2.4 and 3.3 will be released?

Thanks!

Tom

sounds good.  when I get a chance I'll update this and get it into a
check-in-able state...

> Let me know how else I can help.  When do you think 3.2.4 and 3.3 will be
released?

3.3, going by past history, will probably be in about a year; 3.2.4, a couple of
months, I'd guess.

ok, patch 4095 actually works fine, as you noted.  it's ready to be put into
3.2.x, given votes.

I've applied it to 3.3.0:

: jm 51...; svn commit -m "bug 5476: update Bonded Sender (now Sender Score
Certified) rules, and add a rule for their strictly-confirmed-opt-in-required
zone" rules/20_dnsbl_tests.cf rules/50_scores.cf
Sending        rules/20_dnsbl_tests.cf
Sending        rules/50_scores.cf
Transmitting file data ..
Committed revision 574932.

actually, I forgot; rules are C-T-R.  I'll apply the patch (and generate a rules
update)

applied to 3.2.x:

Sending        rules/20_dnsbl_tests.cf
Sending        rules/50_scores.cf
Transmitting file data ..
Committed revision 581301.

and to 3.2.x updates:

Sending        b3_2_0_updates/20_dnsbl_tests.cf
Sending        b3_2_0_updates/50_scores.cf
Transmitting file data ..
Committed revision 581306.

then, update built as per http://wiki.apache.org/spamassassin/ManualRuleUpdates .