Todd Lyons wrote:
> On Wed, Oct 13, 2010 at 4:48 PM, Phil Pennock <exim-users@???> wrote:
>> On 2010-10-13 at 08:13 -0700, Todd Lyons wrote:
>>> In the IETF-DKIM mailing list, it came to light that an attacker could
>>> send a properly signed email with the attacker's domain, but prepend a
>>> second From: header that says it's from someone@???, and MUA's
>>> will show the second From. It doesn't screw up the signature because
>>> the original From: is what is used to verify the signature. At issue
>>> is that RFC 5532 requires that an email have only one From: header.
>> Thanks.
>> http://bugs.exim.org/show_bug.cgi?id=1030 filed, you shouldn't have had
>> to do this.
>
> Thanks Phil. As pointed out in the bug, I fat fingered the RFC id,
> it's actually RFC 5322 (I'm correcting it for mailing list archive
> purposes). I'll spend some time ruminating on the request for use
> cases in the bug description and add my 2 cents there when I feel I
> have something worthwhile.
>
W/r 'use cases'. A year or several ago I'd have said that there are still many
broken MUA and MTA, so a hard-reject might not be on.
Is that still the case?
Well... I have for donkey's years used the existing acl's for invalid syntax and
missing or malformed headers in 'warn' verbs with point-scores. Neither faux pas
earns enough points alone or even together to reject, nor necessarily even
enough to quarantine. Other things must (also) be amiss.
Having just greped over a year's worth of recent logs, I do find a reduction in
frequency, but also that:
Only 7% with 'invalid header syntax' are rejected (on other factors).
OTOH, 26% of those with 'Missing header lines' are rejected (on other factors).
CAVEAT: My small corner of the world may be totally atypical, both as to traffic
and conguence of these two errors.
Or not...
Pure conjecture at this point, but I'd suspect those with *extra* but forbidden
header lines, per the added 'From:' of the OP, would *presently* be de minimus.
... and might remain so, even as DKIM - and those who wish to defeat it - gains
traction.
Not that the ability to enforce the RFC is a bad idea.
But it should probably not be a hard-wired test, let alone a mandatory hard-fail.
JM2CW
Bill Hacker
