Re: [exim] DKIM, Mailing-lists and signing lengths

Ian Eiloart wrote:
>
> --On 14 June 2010 11:59:30 -0700 Phil Pennock <exim-users@???>
> wrote:
>
>> I think that if you run a mailing-list manager which modifies content at
>> all, whether it's a message footer or Subject: manipulation, then you
>> should be looking to strip DKIM-Signature: from mails as part of
>> processing the mails. There's no need to embed any replacement
>> signatures or know anything more than "this is a checksum header, we're
>> breaking the checksum, strip the header out". It would probably be more
>> polite to rename it to Old-DKIM-Signature: rather than remove it. And
>> processing DomainKey-Signature: in the same way would be good.
>
> I think the recommended behaviour is to leave alone the original signature,
> and add your own. Given that mailing lists can break signatures, it's
> unwise to reject an email on the basis that it carries a broken signature.
>

Well there yah go ... the pragmatic world bites again. And rightly so.

But one of the reasons I've not been enamored of DKIM and predecessors from the
outset.

While 'on point' - my suggestion that MLM admins strip-now-probably-broken and
replace with known-good sigs would (AFAICS) at least reduce the need to give a
pass to broken DKIM, AND centralize the source AS the MLM, not sideswipe the
validity of the creds of every possible poster TO a given list ... means
'somewhat' fewer broken DKIM in the wild.

But back to less on-point history - the pragmatics of the overall environment:

- we've had PTR RR / rDNS checks and an expectation of HELO match to a FQDN ...

... from the dawn of smtp. Best we could do to equate to an IRC's nailed-up
CLR's and a specific TTY's 'WRU'.

We (the community) were overly generous as to the first two for far too long,
thereby nourishing the rise of zombot farms. That is being corrected, thankfully
- as well as ISP capture/redirect/outright block of destined-for port 25.

But we should not have waited to the point where the garbage constituted 80% or
so of all traffic.

We are STILL overly generous as to HELO = FQDN. Yet it would be - and has always
been - more reasonable to enforce that than not. It is not rocket science to
enter the extra DNS RR's to cover those one might legitimately use, nor for a
receiving MTA to vet them, even from walking a longish list.

But too few bother, reducing the practicality of one more old, tried and true tool.

Until enough admins get the original basics 'right' w/r meeting, then enforcing
strict(er) smtp compliance, IOW at least admit the need and embrace the very
*concept* of such ....

... any newer tools remain no more useful than air-freshener in a sewer.

Detectable. But not much use.

JM2CW

Bill Hacker