Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#25 Ability to report failures

v0.4.1
closed
5
2007-05-31
2006-06-20
Dan Mahoney
No

Pretty basic -- the DK (and DKIM) specs allow for the
reporting of failed messages. Would this be the job of
DKIM, or some other milter?

Discussion

1 2 > >> (Page 1 of 2)
  • Logged In: YES
    user_id=1048957

    Are you referring to something other than the
    Authentication-Results: header that both filters already add
    when there's a result to be relayed?

     
    • milestone: --> v0.4.1
     
  • Dan Mahoney
    Dan Mahoney
    2006-06-20

    Logged In: YES
    user_id=1340332

    No, I meant sending a railure notification to the
    r=address@domain address specified in the DNS record, so
    that people who have SPF failed can know about it.

    -Dan

     
  • Logged In: YES
    user_id=1048957

    The filter has that already. The person running the filter
    just needs to enable that code (_FFR_REPORTINFO) and throw
    the switch at runtime (-R).

    You mention SPF though; did you mean to add this here, or
    under senderid-milter instead?

     
    • assigned_to: nobody --> sm-msk
    • status: open --> pending
     
  • Dan Mahoney
    Dan Mahoney
    2006-06-27

    Logged In: YES
    user_id=1340332

    Doh! Sorry, wires crossed on too many things. That should
    have been domainkeys failure, not SPF failure. AFAIK, SPF
    doesn't have a spec for this, although it would certainly be
    nice (as the info could be used to build blacklists).

    -Dan

     
  • Dan Mahoney
    Dan Mahoney
    2006-06-27

    • status: pending --> open
     
  • Logged In: YES
    user_id=1048957

    OK. So is the _FFR_REPORTINFO feature able to provide what
    you want, or were you looking for something else?

    Just to be clear, _FFR_REPORTINFO and -R on the command line
    enable code that will send verification failure reports back
    to the value found in the policy's "r=" tag. The report
    includes the original headers and the canonicalized form so
    that the sender can use "diff" or other tools to see how the
    message got munged in transit.

     
    • status: open --> pending
     
  • Logged In: YES
    user_id=1048957
    Originator: NO

    Inactive nearly nine months.

    Does _FFR_REPORTINFO do what you're after?

     
1 2 > >> (Page 1 of 2)