Sections 2.3 and 3.4 of draft-ietf-dkim-deployment discuss mailing list
managers. They discuss the various forms of mailing lists and recommend
that some of the types definitely issue their own signatures. The
original version of these sections actually discussed the possibility of
deleting extant dim signatures, but that recommendation has not survived
to the current document.
Tony Hansen
[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
> So DKIM aware mailing lists should perhaps delete dkim signatures and
> issue their own? Your message in the example is not a message from
> [EMAIL PROTECTED] as he is a content contributor to the
> originator/author
> [EMAIL PROTECTED] Perhaps an effort to create an RFC
> track for DKIM aware mailing lists is a better tack than trying to
> shoehorn it into SSP.
> Thanks,
>
>
> Bill Oxley
> Messaging Engineer
> Cox Communications
> 404-847-6397
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Eliot Lear
> Sent: Monday, December 10, 2007 3:26 PM
> To: Michael Thomas
> Cc: [EMAIL PROTECTED]; [email protected]
> Subject: Re: [ietf-dkim] NEW ISSUE: Limit the application of SSP to
> unsignedmessages
>
> Mike,
>> Eliot Lear wrote:
>>> Dave's concern is over the
>>> definition of the message originator. If a reputation check of some
>>> form is done on a valid signature and found to be positive, I see no
>>> reason to continue the SSP process.
>>>
>> I certainly agree that if this isn't clear it should be made to be
> clear.
>> But what's unclear to me is that it has anything to do with the text
>> in the draft or whether it's some people's preconceived notions.
>
> Here are the relevant definitions:
>
> 2.3. Originator Address
>
> The "Originator Address" is the email address in the From header
> field of a message [RFC2822], or if and only if the From header field
> contains multiple addresses, the first address in the From header
> field.
>
>
> 2.8. Originator Signature
>
> An "Originator Signature" is any Valid Signature where the signing
> address (listed in the "i=" tag if present, otherwise its default
> value, consisting of the null address, representing an unknown user,
> followed by "@", followed by the value of the "d=" tag) matches the
> Originator Address. If the signing address does not include a local-
> part, then only the domains must match; otherwise, the two addresses
> must be identical.
>
> For purposes of our discussion, let us consider the case where I have
> received a message from [EMAIL PROTECTED] via a mailing list
> [EMAIL PROTECTED] that has somehow broken the Joe's DKIM
> signature, perhaps by appending some text at the bottom. The MTA for
> good-reputation.com has signed the message. Section 4.4 Step 1 does not
> directly state that I can use that signature as a valid signature. Let
> us assume that handling=deny and that dkim=all in this example. Because
> I do not have a valid originator signature I proceed to Step 2 and query
> for _ssp._domainkey.StrictSSP.COM.
>
> I believe this is undesirable. It would be better to have the check
> earlier, say in step 1, but I recognize this presents a problem with
> strict, because you never make an SSP query to determine if strict
> conditions apply. To solve this one could add a flag to the DKIM DNS
> record.
>
> Eliot
> _______________________________________________
> 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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
