On Wednesday, October 13 "John Glube" <jbglube(_at_)sympatico(_dot_)ca> wrote:
Now that the internet draft for spfv1 has been filed, I
believe it is appropriate to discuss what to do about spfv2
and sender-id.
.....
My thoughts on the architecture for the future, FWIW:
Observations:
-------------
1) PRA and mail-from are architecturally different: envelope vs. content.
2) Their record contents are likely to be different in significant numbers of
cases,
3) The MARID process had accepted this, proposing different records, identified
by different prefixes(spf2.0/mailfrom, spf2.0/pra)
4) Therefore the MARID direction was towards two separate DNS records for the
two tests.
Current situation:
----------------
1) Breakdown in trust among the three parties: IETF, M$, SPF+OpenSource
2) DNS experts offering 'easy route' to new RR records
3) Recipients will 'pick-and-choose' which tests they apply. Probably:
- M$ and affiliates - PRA only.
- Small & medium-sized sites and ISPs: MAIL-FROM only
- Large ISPs: both
Proposal
---------
A) Separate the two, architecturally-different test families into separate RFC
tracks with separate 'brands', i.e.
- Envelope / transport tests (mail-from, helo, CSV etc) on one track, branded
"SPF".
- Tests using message content information on a separate RFC track, branded
"Caller-ID" or whatever.
B) These separate tracks to have separate RR numbers.
C) Both tracks could try to 'share' a common record/protocol format -
draft-ietf-marid-protocol-01 and its successors - this sharing having
educational and implementation benefits.
D) The separate tracks could add their own track-specific mechanisms and
modifiers to their records by using incremental RFCs, without need for
co-operation / agreement between the two tracks.
E) If even that level of agreement was not possible, a complete 'divorce' of
record formats would not break anything.
Engineering Analysis
--------
i) It's usually a bad idea to cram too many different strands into one
development track - especially if they disrespect key architectural boundaries.
The direction being taken by MARID and SPF-United is clearly one of these 'bad
ideas',
ii) I don't believe we lose any functionality whatsoever by keeping the RFCs and
actual records separate,
iii) By separating the tracks we lose out on some optimisation opportunities -
but only for those receivers (big ISPs?) who intent to implement both sets of
tests,
iv) There is no substantive difference for those publishing records.
Conclusion
-----------
Split the two test suites into completely separate development / RFC tracks,
with different RR record numbers.
Try to share a common 'base' record/protocol format - and mark this down as the
'achievement' of MARID.
Chris Haynes