----- Original Message -----
From: "Andrew Newton" <andy(_at_)hxr(_dot_)us>
To: "Dave Crocker" <dcrocker(_at_)brandenburg(_dot_)com>
Cc: "Marshall Rose" <mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us>; "Ted
Hardie"
<hardie(_at_)qualcomm(_dot_)com>; "IETF MARID WG"
<ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Friday, June 25, 2004 9:35 PM
Subject: Re: consensus statement on record syntax and type
On Jun 25, 2004, at 7:35 PM, Dave Crocker wrote:
So I am not seeing how to incorporate one into the other. The fact
that you listed the alternative of merging suggests that you have
something substantive in mind.
We simply listed the possibilities. The prospect of taking some of the
concepts from CSV and placing them in SPF has already been discussed on
the list, though not in detail.
Currently our 2821 based Transaction Management System (TMS) has the
following specific order of testing:
- FILTER, Admin defined White/Black Accept/Reject Rules
- RBL, List of Reputation Lookup Sites.
- LMAP (SPF, CEP, DMP)
- CBV (Call Back Verifier)
MARID will replace LMAP which means SPF stays, DMP (currently undocumented)
will be deprecated and CEP pulled and replaced with the future MARID (SPF2)
Still fresh at reading CSV (combining it with DNA/CSA), from what I see,
the only new concept introduced is the "Accreditation" logic and also
possibly (need to read more) solving some level of the possible forwarding
issues in the LMAP methods. So as a new product feature customer offering,
I can see it fit as follows:
- FILTER, Admin defined White/Black Accept/Reject Rules
- CSV, Accreditation and CSA Lookup per spec
- RBL, List of Reputation Lookup Sites.
- MARID (SPF, SPF2, CSV-2)
- CBV (Call Back Verifier)
I should note RBL currently represents 80% of the total rejection, the best
method in the industry hence why it is so popular. So it would be hard to
replace/remove it as a TMS feature.
In any case, I have to read more, but one of the remaining issues would be
the forwarding issue with SPF/MARID. So possible concepts discussed in CSV
regarding Address-based Authentication may apply in validating the
"routed/forwarded" message (CSV-2 in MARID).
Also, on a related note, one part that will be a challenge for implemented
or support is the idea of a remote SPF domain record/policy defining the
sources used for reputation or accreditation lookups. If it is added it
will be done as an option (off). So I would be initially oppose to a SPF2
functional specification enforcing such a directive/mechanism.
[X] SPF support
[_] Honor Reputation Lookup
[?] Honor Accreditation Lookup
The main reason is because the sysop will want to apply such look ups across
the board, not based on what a specific MARID/SPF domain policy says. The
odds are very high, the above options would not be made available since RBL
is already in place.
If anything, Accreditation may be provided and ON by default if its done in
a way that allows the sysop to decide what trusted sites to lookup.
But overall, I would prefer to continue to have both separate from MARID.
This means I also see CVS having a partial role in a MARID based Transaction
Management System.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com