#39 Per-recipient configuration


A Debian user has submitted a suggestion that it should be possible to configure dkim-filter to permit switching on or off the BodyLengths feature and signing in general based on recipient address. The particular use case here is mailing lists: the BodyLengths case is intended for list servers that add footers, while the no-signing case is intended for those that modify the subject.

I know there are many more issues to discuss around the hows and whys of both features; I'm happy to refer the original requester here if further information is desired.


  • Anonymous - 2009-01-26

    Does the BODYLENGTH_DB FFR not suffice for this purpose?

  • Anonymous - 2009-01-26
    • milestone: --> v2.8.1
    • assigned_to: nobody --> sm-msk
    • status: open --> pending
  • Mike Markley

    Mike Markley - 2009-01-27

    You're right, it does satisfy a good portion of the request. I'll go ahead and enable that in the Debian package. In the meantime, though, I do know that the desire is to be able to do pattern matches, and I'm not sure the FFR does that. There's also the issue of choosing whether to sign at all based on recipient (which I'm less enamored of, as a site doing so effectively cannot publish an ADSP record stronger than dkim=unknown).

  • Mike Markley

    Mike Markley - 2009-01-27
    • status: pending --> open
  • Anonymous - 2009-02-09

    I think I'd need to hear a pretty compelling reason to enable selective signing; I agree, that's questionable. On the other hand, if it is known to break some ubiquitous software to send it a signed message, that's worth considering. Then again, ubiquitous yet supported software should probably be encouraged to adapt, because it's not like DKIM is a short-term temporary thing.

    You're right, the FFR wouldn't support a wildcard, although it can be trivially adapted to do specific substrings (e.g. try to match on user@domain and then on @domain, kind of like how i= works). Would that work?

    I think the DB version of this idea may have been introduced to add the feature such that configuration reloads were not necessary to provide an update, or so that unprivileged programs could provide updates the filter would use.

  • Anonymous - 2009-06-01
    • assigned_to: sm-msk --> nobody

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks