#16 Access SSP policy from application

v2.0.2
closed-accepted
5
2007-08-10
2007-08-08
Andy Fiddaman
No

dkim_policy() used to return a dkim_policy_t which I found useful in my application for logging and diagnostics.

The way it is in 2.x makes more sense in that it is a black box function that returns an indication of success and does the policy determination internally but is there any possibility of making the retrieved policy available to applications again?

Either as an additional PBR parameter or have it stored in the dkim context and retrieved by a new function after dkim_policy()? For diagnostic purposes it would also be very useful to know the test number that made the final decision (as per ietf-dkim-ssp-00 4.4 currently)..

status = dkim_policy(ref, &test, &susp);
policy = dkim_policy_result(ref, &stage);

Something like the attached patch (against 2.1.0beta1)

Thanks for considering this, if this functionality can be integrated it minimises the additional patching I need to do.

Discussion

1 2 > >> (Page 1 of 2)
  • Andy Fiddaman
    Andy Fiddaman
    2007-08-08

    Patch

     
    Attachments
    • assigned_to: nobody --> sm-msk
     
  • Logged In: YES
    user_id=1048957
    Originator: NO

    I haven't looked at the patch yet, but just to comment:

    I've got no problem restoring your access to the dkim_policy_t that represents the sender's policy.

    I'm a little iffy about the "test number" though since the spec could change quite a bit or other parallel proposals could be implemented which don't have such numbers. I'm more inclined to have some way of representing what was found, i.e. a series of mnemonics or flag bits that indicate such things as "sender domain does not exist", "subdomains not allowed", etc. Would that work for you?

     
  • Logged In: YES
    user_id=1048957
    Originator: NO

    First half of your request will be in the next beta release. Awaiting your reply to my comments about the second.

     
    • summary: Access SSP policy from application. --> Access SSP policy from application
     
  • Andy Fiddaman
    Andy Fiddaman
    2007-08-08

    Logged In: YES
    user_id=1757498
    Originator: YES

    I think 'iffy' is exactly the right word to describe how I feel about it as well but I would really like to be able to see why the suspicious flag ended up the way it did. I did try to overcome my reservations by rationalising that the code implements a specific draft specification and if the specification changes then the code is also likely to, so it isn't too bad having the test numbers hard coded. However I agree it feels far from elegant.

    Something like you suggest using bitwise flags would work too, effectively it would be the same concept but just abstract from test numbers.

    At the moment I'm using this information to add additional validation information to a new header, something like

    X-DKIM-SSP-Analysis: Policy in test mode;
    see http://www.ietf.org/internet-drafts/draft-ietf-dkim-ssp-00.txt
    section 4.4 step 6

    Step 6 is the main one that's really confusing my customers - if you set your policy to testing mode then an unsigned message validates regardless of what you set as the policy. By being able to see that it was step 6 that triggered it, I can add something additional in the comment of the Authentication-Results header as well and that helps my customers to actually test their policy. Without this extra information they can't differentiate between no policy and a policy in test mode.

    I've currently got a function which translates steps to short reasons, if using bit-flags or other mnemonics can allow me to do the same then that would be perfect, thanks.

    char *
    dk_sspstage_descr(int stage)
    {
    switch (stage)
    {
    case 0:
    return "Algorithm not run";
    case 1:
    return "Valid signature found";
    case 2:
    return "???";
    case 3:
    return "Non-existent sender domain";
    case 4:
    return "No parent domain";
    case 5:
    return "Parent policy found";
    case 6:
    return "Policy in test mode";
    case 7:
    return "Policy is unknown";
    case 8:
    return "Policy 'all' and valid signature";
    case 9:
    return "Final stage";
    default:
    return "???";
    }
    return "???";
    }

     
  • Logged In: YES
    user_id=1048957
    Originator: NO

    OK, I'll try to do something like that in time for 2.1.0, otherwise it'll be in 2.2.0 and we can work on a patch for you to use in the interim.

     
  • Proposed patch #1

     
    Attachments
  • Logged In: YES
    user_id=1048957
    Originator: NO

    Attaching a patch which adds what we discussed earlier.
    I haven't really tested it yet but I should have time
    tomorrow. If we can verify it works in the next day or so
    I can make it part of 2.1.0 which I'm planning to release
    Friday.

    The patch doesn't include a few of the HTML files for
    documentation but the release version will.

    File Added: PATCH

     
  • Andy Fiddaman
    Andy Fiddaman
    2007-08-09

    Logged In: YES
    user_id=1757498
    Originator: YES

    That patch looks very nice and does exactly what I need. I'll apply it and do some testing and let you know how I get on, thanks!

     
1 2 > >> (Page 1 of 2)