Loading ...
Sorry, an error occurred while loading the content.

qmail-dk issue

Expand Messages
  • John Simpson
    howdy- i just re-joined the list after a few years because i was asked for my opinion on the potential patch to qmail-dk.c described in this message:
    Message 1 of 2 , Aug 31, 2005
    View Source
    • 0 Attachment
      howdy-

      i just re-joined the list after a few years because i was asked for
      my opinion on the potential patch to qmail-dk.c described in this
      message:

      http://marc.theaimsgroup.com/?l=qmail&m=112401770032376

      while looking at the patch and the code it modifies, i think i may
      have found an issue with how the code is written.

      according to the documentation, and from walking the code, it looks
      to me like this is how it ends up working:

      if DKSIGN is set
      sign the message using the explicit key location
      else if DKVERIFY is set
      verify the message
      else
      sign the message using the default key location

      i'm like jeremy, i have no RELAYCLIENT machines- the users on my
      server all use AUTH, and the AUTH patch i'm using is one that i found
      several years ago and modified so that it checks the qmail-smtpd
      command line arguments, and will not advertise or accept the AUTH
      command unless the command line is correct AND the connection is
      secure (or it also sees an ALLOW_INSECURE_AUTH variable.)

      i had never thought of exporting RELAYCLIENT in the case of a
      successful AUTH, but the idea makes sense at first glance... i'll
      have to look into that. i wonder if there's any reason that a
      QMAILQUEUE program (simscan, qmail-scanner, etc.) would need to know
      the difference between a message accepted because of RELAYCLIENT and
      a message accepted because of AUTH... maybe for statistical reasons,
      or maybe the AUTH status would bypass certain phases of being
      checked... again, at first glance it looks like a good idea, but i'm
      not sold on it.

      anyway.

      i can also see a case where a given IP address may have RELAYCLIENT
      status but you would want to verify the message instead of trying to
      sign it. consider an ISP with a client who runs their own mail
      server, on a non-static-IP connection, and the client's mail server
      adds domainkeys signatures as it sends mail out.

      if the client's mail server hands a message to the ISP's mail server,
      the ISP might want their own mail server to verify their domainkeys
      signature before accepting the message- particularly if the client's
      domainkeys record states that any non-signed messages should be
      considered forgeries and dropped. but where the client is using a
      dynamic IP address, the ISP's mail server would ordinarily have the
      RELAYCLIENT variable attached to their IP so that they can relay...

      which would seem to mean that RELAYCLIENT may not always be a
      reliable indicator of whether to sign or verify a given message.
      granted, it's a rather contrived example, but i'm sure we've all had
      clients who wanted/needed stranger things.

      having qmail-smtpd explicitly set DKSIGN when a successful AUTH is
      done is not the best answer either- what should qmail-smtpd add for
      the value? what if the server operator wants to store the keys
      somewhere other than the default /etc/domainkeys/%/default files? i
      don't like the idea of compiling the details of my filesystem into
      the code- i like having the flexibility to change the locations if
      needed, or to specify different values in the tcprules file without a
      client's un-necessary AUTH command changing the value back to some
      global default.

      i think having the DKSIGN variable serve two purposes- specifying the
      location of the key files, as well as being a "sign or verify" flag-
      may not have been the best design decision. i think that if a server
      administator wants to store their keys in a non-standard location,
      they should be able to set that globally if they like, without it
      affecting the decision whether to sign or verify.

      i'm not sure what the "right" answer is- i wanted to throw this out
      there on the list and see how others, particularly russ, feel about
      this. maybe i'm missing something and i'm concerned about a problem
      which doesn't exist...

      another idea is this- how about a cdb file which associates sender
      email addresses (or domains) to specific key files? this would make
      it possible for different users within a given domain to have their
      own specific key files, if there's a need for that sort of thing (and
      obviously there must be, the domainkeys standard makes a provision
      for it.) this isn't just an idle suggestion- if there's an interest
      in it, i will write the patch to implement it.

      --------------------------------------------------
      | John M. Simpson - KG4ZOW - Programmer At Large |
      | http://www.jms1.net/ <jms1@...> |
      --------------------------------------------------
      | Mac OS X proves that it's easier to make UNIX |
      | pretty than it is to make Windows secure. |
      --------------------------------------------------
    • Richard Lyons
      ... What we did was to have our qmail-dk use environment variables to hold the key and selector; a database lookup using the 821.sender or 822.from is used to
      Message 2 of 2 , Sep 1, 2005
      View Source
      • 0 Attachment
        On Thu, 2005-09-01 at 02:28 -0400, John Simpson wrote:

        > another idea is this- how about a cdb file which associates sender
        > email addresses (or domains) to specific key files? this would make

        What we did was to have our qmail-dk use environment variables to
        hold the key and selector; a database lookup using the 821.sender
        or 822.from is used to set these variables (as well as others).
        This allows us to have default policies that are override-able
        on a fine grained basis.

        Rick.
      Your message has been successfully submitted and would be delivered to recipients shortly.