Autor: Jeremy Harris Data: Para: exim-users Assunto: Re: [exim] DKIM signing & max line length
On 04/08/16 10:21, Sander Smeenk wrote: > One of my users botched the system by sending (automated) messages that
> have a ~20KB XML-dump all on one long line. The message in my logs is
> nothing more than "DKIM: message could not be signed, and dkim_strict is
> set. Deferring message delivery." without any further indication to
> *WHY* the signing failed. Even running a delivery in -d+all mode doesn't
> really give any details to why the signing failed.
>
> So, Googling brought me to a thread from 2012 [1], this subscriber
> reports about the line length being an issue for DKIM and reports the
> differences in checks for parts of the Exim code.
>
> I tried to get some info on this. Aparently RFC2822 specifies a line in
> an email should not exceed 998 chars (+CRLF=1000). I haven't heard of
> any MTA enforcing this and it would seem a bit low to me.
The current configure.default in the source code enforces it.. but you
didn't give a version of Exim or say if you're using that configuration
unmodified.
As for being a bit low: it's well enough for text intended for reading
by humans. All other uses have means for wrapping data.
> Why are there three different(!) MAX-settings in the Exim code?
You haven't pointed them out... but the usual reasons: code aquired
by accretion over the years. In particular, the DKIM code was imported
from a library called "PDKIM".
> Why does Exim accept such mails in the first place?
Because it's up to the config to refuse them, and apparently yours
does not.
> Why exactly can't it DKIM sign such messages?
This will depend on the version of Exim; the DKIM code has been
massaged recently.
> (Do other MTAs handle these situations gracefuly?)
Pass
> Why isn't any of this line length stuff discussed in the Fine Manual[2]?
The writers are not omniscient. Suggestions for changes and additions
are welcome.
> How do other mail ops handle such cases with regard to DKIM signing?
Pass
> Also, instead of deferring delivery for such messages, wouldn't it be
> nicer to freeze them in the queue and notify postmasters?
Possibly (though the "notify" would be an issue).
The detection point spitting out that message is fairly remote from
the depths of the DKIM code where problems presumably arise; the worry
would be that some of those problems are (unlike this one) transient,
such that retry is appropriate. DNS lookup issues come to mind. We'd
need more complex status passed back for testing.
