Re: [Imap-protocol] DKIM signatures on this list

The only reason that I have  a DKIM signature on my emails is because my 
mail server, that has an outbound volume of roughly 20 messages a month, 
is marked as a "bulk mail sender" by the fine folks at gmail, and they 
insist that I add a dkim signature before they will accept any of my 
mail.  Rather than try to find some real human at google to communicate 
with about this, a task easier said than done, I chose to acquiesce to 
this requirement despite the fact that I think that 20 messages a month 
or so qualifies as "bulk" in no sane person's definition.  I do this 
primarily so I can send emails to my wife, which is occasionally 
necessary to meet the requirements of connubial bliss.

Beyond that, and beyond the procedures necessary to set it up, I have no 
knowledge of DKIM.  I have no idea why Mr Levine assumes that because I 
have a passing familiarity with RFC 3501 and RFC 2822 that I will 
necessarily have detailed knowledge of the contents of RFC 6376.  Upon 
reading his emails and reflecting on how such things work, I do 
understand that a lack of signature is semantically equivalent to an 
invalid signature, but I don't understand why there is an assumption 
that this knowledge should be intuitively obvious to the casual 
observer, even on a list such as this.

On 03/14/2015 09:25 AM, Barry Leiba wrote:
> The problem with your "you" thesis is that you're attributing things
> to the signature that are not meant by DKIM signatures.  There is no
> sensible comparison to be made between a purported signature by your
> boss that asserts that she authorized you to spend money... and what a
> DKIM signature asserts.  As John says, it's critical to fully
> understand what DKIM signatures do and don't do, and not to use them
> for things beyond what they're intended for.
>
> Barry
>
> On Fri, Mar 13, 2015 at 6:49 PM, Eduardo Chappa <[email protected]> wrote:
>> On Fri, 13 Mar 2015, John Levine wrote:
>>
>>>>> The point of a signature is to have a way of verification of the message
>>>>> as sent and received. If "you" received a message from your boss saying "I
>>>>> approve that you spend ten thousand dollars in the company party" and the
>>>>> signature of such message would not validate, that would certainly not be a
>>>>> situation where "you" would say "the correct thing to do is to ignore it."
>>>
>>> RFC 6376 is quite clear about what you do with an invalid DKIM signature
>>> -- you ignore it, as though the signature wasn't there at all.  We
>>> deliberately wrote it that way.
>>
>> The question is who is "you" in the sentence above. If you mean to say that
>> "you" is the client implementor, well, there is no much that can be done to
>> recover from such error. It is hard to try to recover, so "ignoring it" is
>> sensible.
>>
>> However, the comment that originated this conversation was not a comment
>> about the implementation of a RFC, it was about a user point of view, so
>> while the comment you made may be sensible to implementors, I do not see it
>> as such for users, and that is the context of what I saw.I read originally
>> was not meant to say (in my opinion) that the list was
>>
>>> It's fine to treat mail with valid signatures differently from mail
>>> without valid signatures, but it's not fine to treat mail with an invalid
>>> signature differently from mail with no signature.  That's why you shouldn't
>>> depend on lists to strip the signatures they break.
>>>
>>> I would have hoped that people interested enough in mail software to be on
>>> this list would go to the effort to read and understand the specs they
>>> implement.
>>
>> In generic terms I understand you. But the RFC is just that, and it is for
>> implementors, not for users. I do not think that you can tell me, as a user,
>> that it is "fine" when a signature does not validate, because I care to
>> receive what was sent and I do not have any algorithmic way to know what the
>> original message was. I know there is no much that can be done to fix it as
>> an implementor, so in that sense, I should ignore the failure, but that is
>> not what makes a user feels warm and fuzzy about the message they just
>> received and fails to validate.
>>
>> --
>> Eduardo
>>
>> _______________________________________________
>> Imap-protocol mailing list
>> [email protected]
>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
> _______________________________________________
> Imap-protocol mailing list
> [email protected]
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol