On Wed, Mar 17, 2004 at 07:23:32AM -0800, Hallam-Baker, Phillip wrote:
Basically the scheme returns an A record in response to a lookup. So
in order for example.com to announce that it is accredited by the class3
service of verisign the SPF or CallerID record would contain the tripple:
"accreditation" "class3.verisign.com""DNS-A"
I.e. this is an accreditation property, the accreditor service is at
class3.verisign.com, the protocol is a DNS A record lookup.
Some folk inside VeriSign suggested that we use the convention that
an unlisted domain just returns domain does not exist.
You mean when querying the accreditation service?
How would this interact with Verisign's publishing of wildcard
records (e.g. if the accreditation service goes out of business and
its domain name is revoked)?
This goal of indirect identification of accreditation services seems
like a positive thing. Has there been any attempt to analyze the
additional overhead?
Also, as with SPF et al there is the question of feedback from the
recipient: e.g. one might want to have the ability for the recipient
to publish information about what that recipient requires of a
sender. Some unified scheme might be useful, like:
( Sender domain must publish SPF OR DMP
AND Sender must be accredited by any two of {abc, def, ghi, xyz}
AND Sender IP must publish MTAMark)
OR ( Sender must accept address verification probe )
but that's probably a whole nother effort.
A couple of random remarks from a very cursory reading:
There is no difficulty in ensuring that accreditation providers are
accountable to email recipients. An accreditation authority that
provides incorrect accreditation will soon be ignored.
Pretty bold assertion :-)
It hasn't held true with some DNSBL services. Among other reasons is
the wide variety of definitions of "incorrect," as well as extremely
polar opinions about listing criteria, remedies, responsibility, et al.
1.3 Practices Considerations
As a trusted third party the actions of an Accreditation Authority
are raise numerous legal issues.
syntax problem there.
3.2 Sender Recipient A Record
...
Bits 4-7
These bits are reserved. Relying parties MUST ignore
Red flag: better would be "these bits are reserved and must be set
to zero." If you don't guarantee they are zero from the outset,
it's hard to make sure you can use them in the future.
3.3 Other Sender Recipient Records
Additional information MAY be provided by means of other DNS
records, for example TXT or NAPTR records.
Do you really anticipate using NAPTR?
mm
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg