Phil Pennock wrote: > On 2010-06-14 at 12:09 +0100, Ian Eiloart wrote: >> --On 11 June 2010 22:37:09 -0700 Phil Pennock <[email protected]> >> wrote: >>> DKIM contains two ways of forming the message body, for signing >>> purposes, and optionally lets you only sign the first 'l' bytes of the >>> body. So you could theoretically use l=0 but at this time I can't >>> conceive of a scenario where that would be wise. >> It might allow the signature to survive the addition of a mailing list sig. > > So for that, you'd sign l=<message-len>, rather than l=0. > > It would fail for mailing-list sigs inside MIME parts, or where a new > container MIME part was added to support the sig. Or any sort of MIME, > where the original MIME termination would fail. > > I'd still be worried about a spammer finding a way to abuse a lax MIME > parser and add a new HTML part which uses an iframe and manages to > obscure the original content. > > I think that if you run a mailing-list manager which modifies content at > all, whether it's a message footer or Subject: manipulation,
... not to forget body modification ... (administrivia, quoting style/limits, embedded OP info, embedded RFC banners, encoding and html conversions...) > then you > should be looking to strip DKIM-Signature: from mails as part of > processing the mails. Amen. > 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'd suggest remove as the better general course. On what is now a 'broadcast' message, there is in effect new ownership/responsibility. A compliant MLM is not 'transparent' in the same sense a relaying MTA might be, but is *generating* a broadcast message with mandatory additions as a result of being 'triggered' to do so by a posting of generally the same content - but never quite identical. Subscribe/Unsubscribe additions alone - the very least of mods - mandate that if there IS to be a DK/DKIM thumbprint - it should be generated anew by the MLM/MTA for *their* transmitting domain, not that of the original poster. > There's no obligation on MLM maintainers or admins to use DKIM > themselves, just to strip it. No objection to vetting it on the posts submitted TO the MLM, but afterwards, yes, strip, optionally replace. An MLM that cannot or will not put its hand up and vouch for whatever it broadcasts as 'been vetted, and contact our listadmin, not the OP' is not a particularly welcome creature. > > Senders who advertise policies that mails from their domain will always > be signed will find that their domain can't be reliably used for sending > to a mailing-list. Au Contraire. TO the MLM intermediary, certainly as reliable as to any other MTA. FROM that MLM afterwards should be (must be) altered by at least the sub/unsub and such, so even if the OP's ID is presented as an MUA-visible source and Reply-To, his serving MTA is going to see the indentity of the MLM's MTA from whence the connection arrived. If it expects to backtrace and vet the OP's sig as if it were a forwarded or relayed message it will trip. An MLM is not-so-subtly different from a pure relay. Strip and replace, or just strip, but NFW a now known-forcibly-broken DK/DKIM should be onpassed intact. It served its purpose when the message arrived at the MLM's door. > That puts the cost and burden squarely back on the > people using DKIM, instead of it being an externality. This is fair, > and I say this as a DKIM proponent. > > -Phil > Agree that. As a DKIM detractor. But WTH - if it is going to be in the pool, let's encourage it to use the loo first... ;-) Bill -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
