On Wed, 2 Jun 2004, Meng Weng Wong wrote:
On Tue, Jun 01, 2004 at 04:46:51PM -0400, Stuart D. Gathman wrote:
|
| There is actually no need for any mechanism other than exists. The other
| mechanisms exist only as an optimization for common checks which can be
safely
| performed on the receiving MTA without consulting the sender domain.
The above is true if we limit sender authentication to
designated sender schemes. However, if we admit the
possibility of non-IP-based schemes eg. DomainKeys, PGP,
SMIME, Vanquish, PennyBlack, etc etc, the case for new
mechanisms makes more sense.
DomainKeys has its own marker indicating if domain is using it or not and how
much.
Are you proposing similar marker to be used as part of SPF and similar for
those systems where all email would come with PGP or S/MIME signed emails?
I do want to note that if you're considering extensions like this than XML
becomes quite usefull. In this case under "<ep>" there would be additional
elements like <dk policy=true>, etc.
What I'm concerned is that we'll overload single dns with various policies
which leads to large syntax when expressed in xml and we need to keep in
mind that dns is not designed for such use and need to try to keep record
elements as simple as possible. In such a case it might be better to
consider using alternative protocol (possibly based on BEEP but with
udp transport) to provide access to such larger policy system and use
dns only as a pointer to correct policy server. Such policy server can
also then be used to provide information for "sender" about which mail
authentication policies does recepient system support, to inform what
reputation services does recepient trust and which consent is considered
ok (i.e. like extended no-soliciting). I'm quite interested in working
on email-policy service like that but will object if we continue using
DNS for such complex policy framework.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net