-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Douglas Otis
Sent: Monday, September 27, 2010 4:19 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Authorizing List Domains
I don't really want to conduct an experiment that includes myriad
optional policy specifications without some operational data to suggest
they stand a chance of adoption. Simpler is better.
Agreed, but not having a defense against trivial exploitation of an
authorization is not better. When a defensive requirement proves
unused, it can be removed without impact. Since this information sets
authorization requirements, adding the information at a later date
would not be compatible with existing implementations.
That seems antithetical to the idea that this is all experimental work,
explicitly not on the standards track.
Perhaps we can work on the bare essentials independent of the notation
used.
Types of authentication that might be used for existing third-party
services-
1) DKIM
2) TLS
3) SPF
4) EHLO/ADR
I wasn't aware we were scoping something intended to be universally used. My
focus has been strictly on DKIM. Other than TLS, we're not talking about
particularly strong authentication systems here so I'm not sure we should spend
the cycles to be that accommodating. However, as I said before, decoupling
ATPS from ADSP is a trivial matter if that turns out to be the right way to go.
Since any client can say anything it wants for an EHLO parameter, why should it
be considered a type of authentication?
Additional header field requirements ensure message sorting or
presentation. The header field requirement is to offer simple tactics
against most phishing exploits:
a) Sender
b) List-ID
Why would one base any kind of security mechanism on a trivially spoofed header
field?
The most visible name to recipients is the domain
found in the From header, whether used as a basis for sorting, or when
displayed in addition to that of the friendly name.
Then why create semantics around other fields?
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev