Lets please keep the focus:
Section 6.1 and 7.4.1 describe a ADSP standard.
Section 6.5 describes a forwarding signing semantics that conflicts
with 6.1 and 7.4.1.
This is not a matter of one spec predating another. The deployment
guide attempt to merge the suite of DKIM technologies.
Under IETF protocol design methodology for sound engineering
integration, these sections needs to be codified and corrected to
assure we do not create network adoption interoperability problems.
--
Steve Atkins wrote:
> On Oct 14, 2009, at 2:32 AM, Charles Lindsey wrote:
>> If a valid signature is absent, then indeed the listadmin should
>> discard
>> it (maybe even with 'ALL'). But the case of most interest is when the
>> message arrives with a valid signature. In that case, the listadmin
>> should
>> do his best to forward it, but what does he do if the list policy is
>> to
>> munge? That is what we are discussing.
>>
>> So he adds Authentication-Results and signs it. At least then the
>> final
>> recipient can see that and decide to ignore the failure of the
>> original
>> signature ("DISCARDABLE" or not), assuming he trusts the listadmin.
>
> The whole point of "discardable" is that the final recipient should not
> see it in that case. It's for things like transactional mail, bank
> statements,
> that sort of thing - which should never go to mailing lists anyway as
> the sender believes it should be sent directly to the final recipient,
> or
> not at all.
>
> (If you disagree with my characterization of the sort of email that
> might
> use discardable that's fine, but lets be specific about the operational
> details, like what classes of email we're talking about. Discussing it
> solely in the abstract protects the discussion from common sense.)
>
> A more interesting case to consider is acm.org style forwarders,
> where the forwarder is, in many ways, the final destination, and where
> the address at the forwarder is "owned" by the final recipient, and
> where they will likely ask for transactional mail of the sort that
> senders might consider discardable be sent.
>
> Cheers,
> Steve
>
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
