On Nov 28, 2006, at 4:48 AM, Charles Lindsey wrote:
On Mon, 27 Nov 2006 13:07:02 -0000, Stephen Farrell
<[EMAIL PROTECTED]> wrote:
Charles Lindsey wrote:
On Sat, 25 Nov 2006 06:25:27 -0000, Jim Fenton <[EMAIL PROTECTED]>
wrote:
It's not entirely forgotten; section 2.3 of draft-allman-dkim-
ssp-02 discusses multiple From addresses. We thought about
resolving the ambiguity by (1) arbitrarily picking the first
address in the From header field, (2) picking the address in the
Sender header field, or (3) querying SSP for all addresses in
the From header field, and combining them somehow. We picked
(1), ...
And there I think you picked the wrong one.
Fair enough that you disagree, but the main point though is that
the WG reached rough consensus.
I have seen sufficient comments from others to the effect that
the Sender needs to be looked at in many situations that this
matter probably ought to be reviewed (does that mean raising an
Issue?).
No. For base, Barry and I are using a scheme where re-opening a
decided issue (which is what you'd presumably like in this case)
requires N people supporting, for some informally defined, but
increasing, value of N ....
That is fair comment, but there seem to be an awful lot of people
still discussing the Role of Sender (and even List-ID and Return-
Path) as possible signing domains.
OK, this is a petition for reopening this Issue. That gives 1 vote,
but you will need lots more to take action. So I invite anyone else
who supports this view to reply with a +1. If there is insufficient
support, then I will shut up.
+1!
Selection of the From address is premised upon a bad assumption that
by only "authorizing" this header, spoofing an "author" of the
message can be prevented. This concept remains highly flawed for the
following reasons:
1) Only the display name may be visible.
2) The display name may appear as the actual email-address.
3) UTF-8 support makes human checking impossible.
4) Look-alike and cousin domains are not prevented.
5) Increases likelihood of multiple From email-address use.
6) Not likely able to incorporate EAI email-address versions.
7) Establishes credibility of phishing attempts by self "authorization".
8) Reduces email delivery integrity in many scenarios.
9) Requires excessive DNS overhead climbing label trees for every
unsigned message to satisfy a small percentage of domains that
will publish an "all From headers should be signed."
This narrow view overlooks a far more protective alternative that:
1) Thwarts look-alike and cousin domains spoofing.
2) Is compatible with any EAI scheme.
3) Will not increase credibility of phishing attempts.
4) Will increase email delivery integrity.
5) Will not require excessive DNS overhead.
6) Can be implemented by the recipient and email-address domain
owner independent of their providers.
7) Eliminates exchange of private keys with providers, zone
delegations to the provider, or negotiations with the provider the
selector locations for a series of CNAME records.
The alternative is protection by an annotation scheme checking two
basic items:
1) Is a signed email-address known by the recipient (i.e. in the
address-book)?
2) Is the signing domain designated by this email-address domain?
(Obvious only when same domain.)
When other headers are used to communicate with a recipient, then
which headers gets annotated can still be controlled by the domain of
the email-address ONLY when other headers are allowed to make
associations!
Setting flags regarding whether all such headers are signed can be
added. However, such flags should not be checked by most
recipients. A false expectation of blocking abuse by way of
"authorization" has been shown not to work, but this seems to be what
is behind most participants motivations. This limits their thinking
to only the use of the From header. Allowing associations to support
an annotation scheme has not been considered. The same association
scheme can also prevent white-listing abuse and ensure DSNs once this
approach is considered more carefully.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
