spf-discuss
[Top] [All Lists]

Re: accreditation modifier

2004-03-10 03:39:33
On Wed, Mar 10, 2004 at 05:03:38AM -0500, Meng Weng Wong wrote:
| 
| 1) accredited sender domains should be able to add accreditation
|    modifiers easily.

example.com TXT "v=spf1 mx -all accredit=%{d}.accreditor.net"

| 2) accreditation agencies should be able to easily publish vouch
|    information, in a standard format if possible

example.com.accreditor.net A 127.0.0.2

| 3) reputation services eg. SpamAssassin should be able to easily verify
|    an asserted accreditation and resolve its semantics to a score or an
|    absolute whitelist.

Receiver code such as SpamAssassin could add code that does:

my %recognized_accreditors = ( "%{d}.accreditor.net" => -10,
                               "%{d}.verisign.com"   => -10,
                               ...,
                             );

if (spf_pass($domain)) {

  foreach my $modifier (asserted_accreditation($domain)) {

    next if not exists $recognized_accreditors{$modifier};

    if (accreditor_vouches_for_domain($domain, $modifier)) {

       $score += $recognized_accreditors{$modifier};

                                 * * *

Now we should discuss semantics.

|           
|       1.2 Accreditation Statements 
|           
|          At present a large number of different parties act as Accreditation 
|          Authorities with respect to sending of email. Blacklists attempt to 
|          identify bad faith actors while whitelists look to identify good 
|          faith actors. Whitelist accreditations may involve a simple promise 
|          not to spam or a promise that is backed up by some form of penalty 
|          such as the forfeiture of a bond or the publication of negative 
|          reputation data. 
|           
|          Despite the wide variety in the types of data Accreditation 
|          Authorities provide the inferences that anti-spam filtering 
|          techniques attempt to draw are the same, is a particular item of 
|          email likely or unlikely to be spam. For this reason we leave the 
|          details of the accreditation mechanism to the Accreditation 
|          Authority. 
|           
|          An accreditation authority MAY publish any form of accreditation 
|          statement they choose. The following types of statement are likely 
to 
|          be of greatest utility. 
|        
|       Identity Accreditation 
|        
|          The email sender has provided a real world identity and a physical 
|          address at which legal process can be served and this information 
has 
|          been authenticated by means of some trustworthy process. 
|        
|       Undertaking Accreditation 
|        
|          In addition to meeting the identity accreditation requirements, the 
|          email sender has undertaken to comply with a specified email sending 
|          policy. 
|        
|       Reputation Accreditation 
|        
|          In addition to meeting the undertaking accreditation requirements, 
|          the email sender has been determined to be in compliance with those 
|          requirements 
|        

The best known accreditation scheme today is Bonded Sender.

It gives an example of undertaking accreditations:

  https://www.bondedsender.com/standards.jsp

If these undertakings are met, a sender can apply for listing in the
DNSWL sa.bonbdedsender.org.

But accreditation schemes have two scaling problems.

First, http://www.bondedsender.org/ has to provide a new accreditation
lookup rule for each MTA, SpamAssassin, etc.  If accreditation moves
into SPF instead, we can factor out the lookup rules and lower the
barrier to entry for accreditation providers, which is a good thing.

Second, every time a mail sender changes outbound MTA IP addresses, they
have to tell Bonded Sender; this is an administrative cost that is also
eliminated by SPF.

ISIPP's IADB is the first accreditation service that I know of that
publishes domain names as well as IP addresses; it is an RHSWL that
actually means something.

  http://www.isipp.com/iadb_query_sign_up1.php

Right now people are using fairly ad-hoc accreditation formats.  I think
there is value in standardizing on a common format.  Phillip has made a
good start in this direction.

I agree with the need for an Accreditation Authority Description TXT
Record which serves as a machine-readable version of the IADB page.

|       1.3 Publication of Accreditation Statements 
|           
|          Accreditation statements are published by means of an extension of 
|          the existing mechanism used for publication of anti-spam blacklists 
|          via DNS. 
|           
|          An accreditation statement is published by means of the DNS A 
record. 
|          To avoid collisions with other uses of the DNS addresses in the 
|          127.0.x.x loopback address range are used. 
|           
|          [TBS] 
|        
|       1.4 Accreditation Authority Meta Data 
|           
|          The domain prefix specified for an accreditation service MAY contain 
|          a record that describes the use of the particular accreditation 
|          service with the key _accredit. 
|           
|       1.5 Interpretation of Accreditation Statements 
|           
|          Email recipients MAY interpret Accreditation Statements in any 
|          fashion they choose, including regarding an Accreditation Statement 
|          as a negative indicator. 
|           
|          The reputation of the Accreditation Authority MUST be considered 
|          suspect until proven reliable. 
|        
|       2. DNS Publication of Accreditation Statements 
|        
|       2.1 Accreditation Authority Description TXT Record 
|           
|              type:{ identity | undertaking | reputation } 
|                 The type of accreditation provided as described in the 
|                 introduction. 
|               
|              open:<boolean> 
|                 If true the accreditation service is open and MAY be 
consulted 
|                 to obtain information even if the sender does not list the 
|                 service as an accreditor. 
|               
|              protocol: {dns-a | dns-txt | other } 
|                 The protocol by which the accreditation may be retrieved. The 
|                 keyword dns-a specifies that the accreditation record is 
|                 encoded as a DNS A record. The keyword dns-txt specifies that 
|                 the accreditation record is encoded as a DNS TXT record. 
|               
|              length:<integer> 
|                 The number of bits in the record value that have 
significance.  
|               
|              scale: {log2 | log10 | linear | none} 
|                 The scale to be applied when comparing the corresponding 
|                 record values. 
|        
|       2.2 Sender Recipient A Record 
|           
|          The least significant 16 bits of the A record are interpreted as 
|          directed by the description TXT record. 
|        
|       2.3 Sender Recipient TXT Record 
|           
|          Option here to add in more descriptive information. 
|        


<Prev in Thread] Current Thread [Next in Thread>