Michael Thomas wrote:
> On 10/05/2010 01:36 PM, John Levine wrote:
>>> Still, though, it's a solution to deal with malformations to which
>>> MUAs are susceptible, and not strictly a DKIM problem.
>> Would it be a good idea to recommend in 4871bis that DKIM
>> implementations should not sign or verify invalid messages? I
>> cheerfully admit that I haven't thought out all the implications
>> thereof.
>
> I'd suggest that it would be better to take that up with
> rfc5822-bis since this is hardly a dkim-specific problem.
In my engineering opinion, it was a security hole that fell through
the cracks during the development of the RFC 4886 Threat Analysis.
If it was presented back then, we would be dealing with the semantics
as I propose to deal with it simply because we can't ignore it or
blame RFC 822/2822/5322 implementation or MUAs.
This is a DKIM issue and it needs to get addressed. Any system today
that displays:
signed by:
but displays a spoofed 2nd From can produce a major confidence problem
for DKIM.
I have a problem understanding the blow back to the security issue.
4871bis is active. Something needs to be added to 4871bist so that
implementations and operators are made aware of it, now and into the
future.
I highly recommend that the key editors embrace this and deal with it
or risk negative DKIM public relations if this gets into the media or
into the mind set of any hackers and potential DKIM exploiters. You
need to deal with it. Not ignore it or pass the buck to other layers
of email.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
[1] http://tools.ietf.org/html/rfc4686
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
