Bug 4182 - Add support for Accreditor Header field
Summary: Add support for Accreditor Header field
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (Eval Tests) (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: All All
: P5 enhancement
Target Milestone: 3.0.4
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on: 3998
Blocks:
  Show dependency tree
 
Reported: 2005-03-09 16:55 UTC by Carl S. Gutekunst
Modified: 2005-05-17 14:42 UTC (History)
1 user (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Add support for Accreditor: header field patch None Carl S. Gutekunst [HasCLA]
Revised: Add support for Accreditor: header field patch None Carl S. Gutekunst [HasCLA]
Show Obsolete (1) Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Carl S. Gutekunst 2005-03-09 16:55:04 UTC 
As described in Bug #3998, Habeas added support for a "reputation tag" in the
bounce address, so that a sender could name a third-party that would vouch for
their practices. After discussions with customers, partners, and the standards
community, we've decided to generalize this capability, both to make it easier
for senders to deploy and to better align with the CSV-DNA proposal.

Habeas will submit a patch that will add support for a new RFC-2822 header field
"Accreditor" whose semantics will be nearly identical to those of the previously
added "reputation tag." The patch will also clean up the comments and rules to
reflect the current terminology of the standards community.

This patch will not provide an implementation of CSV-DNA or the DNA
Accreditation Record. This patch instead provide a limited useful subset built
on the well understood DNSBL model, and provides a basis for compatibly adding
support for new accreditation capabilities in the future.
Comment 1 Carl S. Gutekunst 2005-03-16 16:00:59 UTC 
Created attachment 2706 [details]
Add support for Accreditor: header field

This patch extends support for asserting an "accreditation authority" to both
the bounce address and the header. In the bounce address, the accreditor is
asserted as a subdomain in the RHS, like so:

    listowner@a--authority.example.com

In the header, like so:

    Accreditor: authority

where "authority" must match the name of an accreditor in a
eval:check_rbl_accreditor() rule. The new header field also supports assertion
of multiple authorities, e.g.,

    Accreditor: Habeas, truste

The syntax also supports optional parameters for each accreditation authority,
but the current patch just ignores these.
Comment 2 Carl S. Gutekunst 2005-04-08 15:12:55 UTC 
Created attachment 2775 [details]
Revised: Add support for Accreditor: header field

This patch replaces the previous patch. It includes a trivial syntax change in
the parameters of the Accreditor field, with the terms now delimited by simple
whitespace instead of semi-colons. This is easier to parse and easier for human
beings to read.
Comment 3 Theo Van Dinter 2005-04-24 19:37:52 UTC 
this goes with bug 3998, so moving to 3.0.3 queue to match.
Comment 4 Theo Van Dinter 2005-04-26 14:25:01 UTC 
+1 for 3.0.3

I just noticed this wasn't committed to 3.1 yet.  Now it is, r164887
Comment 5 Michael Parker 2005-04-26 14:36:29 UTC 
-1 for 3.0.3, lets stick to bug fixes only.  3.1 is right around the corner.
Comment 6 Theo Van Dinter 2005-04-26 14:43:17 UTC 
Subject: Re:  Add support for Accreditor Header field

On Tue, Apr 26, 2005 at 02:36:29PM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> -1 for 3.0.3, lets stick to bug fixes only.  3.1 is right around the corner.

FWIW, this is a generalization patch which goes with 3998 which was
already voted in and committed.  While I agree the stable tree should
limit the number of enhancements to a very low number, I think we ought
to put this patch in since it more generalizes the 3998 patch which is
a good thing IMO.
Comment 7 Michael Parker 2005-04-27 13:58:42 UTC 
Move to 3.0.4 milestone.
Comment 8 Theo Van Dinter 2005-05-17 22:42:13 UTC 
copying the comment from 3998:

ok, I think we've come to the general conclusion that this code will have to wait for 3.1.  so closing the 
ticket.