[ietf-dkim] Re: ISSUE 1521 -- Limit the application of
MH Michael Hammer (5304)
MHammer at ag.com
Thu Jan 24 11:05:54 PST 2008
Ok, now I'm confused......
Does -1 mean remove the text or does -1 mean oppose the proposal. My
intent is to oppose the proposal to remove text.
>From: ietf-dkim-bounces at mipassoc.org
>[mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of MH
>Michael Hammer (5304)
>Sent: Thursday, January 24, 2008 1:56 PM
>To: dcrocker at bbiw.net; ietf-dkim
>Subject: RE: [ietf-dkim] Re: ISSUE 1521 -- Limit the
>application of SSPtounsigned messages
>Apologies for top posting if it offends anyone.
>-1 I OPPOSE this proposal for the following reasons.
>The D in DKIM refers to Domain, not user. If it cannot be used
>to strongly protect the purported originating domain based on
>that domains stated assertions and policy, then DKIM-SSP is of
>Without requiring a check (not saying what action the receiver must
>take) of the From address, what we are saying is that bad guy
>signature on evil nasty email is just as worthwhile of a
>signature as that of the owner of the domain in the From address.
>Anyone care to argue that a signature from
>randomrotating.randomrotating_evil.ru is a sufficient and
>trustworthy signature for an email purporting to be from this
>list even though mipassic.org isn't DKIM signing? BTW, isn't
>ironic that an organization that is pushing DKIM isn't signing
>even with t=y?
>Requiring a check of From does not dictate the decision the
>receiver (MTA,MUA, person at keyboard, whatever) chooses to do
>with the results.
>The folks in favor of removing the text are concerned about
>what receivers will do based on such a check. Shouldn't that
>choice be left to the individual?
>This is almost like arguing that a sign saying "DANGER,
>Shallow Water - Do not Dive" should be removed because some
>people might want to ignore the sign and dive in headfirst anyways.
>Feel free to ignore the from DKIM signature in your personal
>implementation but please don't weaken the opportunity for the
>owner of a domain to make an assertion through DKIM-SSP and
>expect that people following the standard have at least
>checked their disclaimer. If a domain owner chooses not to
>make an assertion or chooses to make a weaker assertion, that
>is their perogative.
>>Summary of proposal:
>>> All text that causes SSP to be applied to an already-signed message
>>> needs to be removed.
>>I've reviewed the thread that took place on this topic. Here are
>> Total postings in thread: 46
>> Number of different people posting: 14
>> Apparent REJECT of proposal: 4
>> Apparent ACCEPT of proposal: 5
>>I would like to ask folks with an opinion about this proposal to post
>>an explicit note stating support or opposition. Some of the existing
>>posts were about substantive issues in the proposal, but did not
>>clearly indicate support or opposition.
>>Given that this issue goes to the core of a significant
>fraction of the
>>current specification's functionality and given that there is
>>an implied requirement for the functionality in the SSP requirements
>>RFC, I'll ask folks to do both a +1/-1 *and* to explain their reasons.
>>I also do not find a record in the archive of working group agreement
>>to add the features in question. So an assumption that the features
>>should be retained unless there is a rough consensus *against* is
>>problematic. Citing the SSP requirements RFC is comforting, but
>>questionable, absent any history of group discussion and clear rough
>>consensus about the matter.
>NOTE WELL: This list operates according to
More information about the ietf-dkim