• If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Announcement

Collapse
No announcement yet.

Configuring domainkey and DKIM signing

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Configuring domainkey and DKIM signing

    I came across two different articles at -
    https://www.axigen.com/documentation...nkeys-p1410026
    https://www.axigen.com/documentation...-dkim-p3277108

    which give a short set of notes on how to configure Axigen to sign emails sent by the server with domainkeys and for dkim but unfortunately I do not fully grok these instructions, in particular for when Axigen is hosting virtual hosts.

    In the first article, which focuses only on domainkeys, the instructions say to configure the conditions to match any email message,

    In the second article, the instructions say to configure the conditions explicitly for a sender domain and to check that the connection is authenticated.

    The reason I am confused is because I am hosting a number of virtual domains and I am not sure whether I can just leave the conditions set to match any email message, or whether I need to configure the signing (and create certificates and enter multiple DNS TXT records with the public key for each domain) explicitly for each of the virtual domains I am supporting.

    Another question I have concerns adding the condition to require that the connection be authenticated. If I add that condition, then the ability to match any email message goes away. So if I leave the condition set so that any email message is matched, does that mean that it must also have been authenticated? Or not?

    Thanks in advance for helping me to get this configured properly... Marc..

  • #2
    Hello Marc,

    Signing the messages have sense only in case you are doing this with a certificate specific for the sender's domain.

    Now, when you are hosting only one domain then you could use a simple condition like 'all messages'.

    If you are more domains you have 2 options:
    • using the same certificate and selector on all domains >> than you could continue to use the simple condition from above
      • this means that all your hosted domains should have the same DNS records related to this feature
      • more easy to configure / maintain
    • if each domain have its own certificate and selector (preferable but not mandatory) >> you have to create one rule for each domain you like to sign introducing a condition like 'if sender domain is'
      • the only advantage, besides looking more professional, is that this method is allowing you to made changes for a specific domain
    Choosing if the signing of the message is also conditioned by the authentication status is up to the admin of the server as it is preferable to sign only the messages that are sent by authenticated users (if I am in your position I'll enforce this rule).

    HTH,
    Ioan

    Comment


    • #3
      Hi again Loan, I decided to give your second suggestion a try, to have each domain work with its own certificate and selector and I have ran into 2 issues, the first one I solved but will give you feedback on because it makes no sense to me and the second issue is a showstopper that I don't know how to solve and perhaps I am doing something wrong so need some more guidance.

      The first issue - following the instructions at https://www.axigen.com/documentation...-dkim-p3277108 it says to

      chmod 400 dkim.*.pem

      which seems right, but when I tried to send signed emails, I kept getting a permissions error. After a lot of experimenting with the permissions and ownership I finally discovered that doing the following works!

      chmod 600 dkim.*.pem

      Why having to give write permission for the owner (axigen) of these certificate files, makes Axigen work, is beyond my ability to grok, maybe you have some insight?

      Now for the second issue. I created separate certificates, DNS entries, conditions and actions as described, for each of my virtual domains. Upon testing however, only the domain defined in the Acceptance/Routing rule at the top priority works. Each of my domains has it's own unique DNS selector and this is where things appear to be going wrong. When Axigen signs emails sent using any lower priority Acceptance/Routing rule, it is always setting the email header with the selector defined by the highest priority Acceptance/Routing rule! It does not appear to be using the selector based on the condition defined by the "Sender IS" value in each of the Acceptance/Routing rules.

      I tested this theory by simply changing the priority order of my Acceptance/Routing rules and sure enough the new highest priority rule for the virtual domain that I defined the rule for would start working and the one that was previously working would fail. That tells me the certificates are fine. And I verified all this by going to a test site at http://www.appmaildev.com/en/dkim where I could see that the DNS selector is being always set to the one defined for the highest priority Acceptance/Routing rule.

      I hope my explanation is clear enough for you to understand, it is a very difficult concept to communicate. Hope you can once again help guide me towards a happy solution, as always, thanks in advance...

      Marc...

      P.S. A small suggestion, it would be really helpful if the WebAdmin tool could expose the full file/directory path to all the various files that are set up and used in the configuration settings. I manage a lot of different servers and it is difficult to remember/discover where some of the actual configuration and logs files are located. Many of the settings for file names are using hidden default locations, especially in fields that simply want a file name entered. And bringing up the file browser associated with selection does not expose the default locations either. I find it very helpful to examine the contents of configuration files in order to better grok things, comparing differences, or watching changes such as doing a tail -f on a log file...

      Comment


      • #4
        Hello Marc,

        Please share your smtpFilters.script in order to understand better your current configuration.

        Best regards,
        Ioan

        Comment


        • #5
          Hi Loan - Sure, I have attached a simplified and obfuscated version that I am using to evaluate Axigen for where I work. If you want to see real domain names, so as to probe and look at the DNS records, for example, I could send you a slightly different version that I am using on my own personal server at home, that I have been using to also learn about and test Axigen out with. Both version display the same symptoms. In either case I don't want to expose my domain names to the internet community at large just yet...
          HTHs Marc...
          P.S. Well I cannot get the Upload Attachments tool on this forum's webpage to work, keeps complaining saying "Invalid File smtpFilters.script" after I select/click on the file. I will just copy/paste it below -
          event onConnect {
          set (allowedCountries_0, " ");
          set (bannedCountries_0, "");
          set (isGeoIPBanned_0, "%isGeoIPBanned%");
          set (GeoIPResult_0, "%GeoIPResult%");
          call (WA_Acceptance_basic_banner);
          }
          event onEhlo {
          call (WA_Greylisting);
          call (WA_Acceptance_basic);
          call (wizard_generated_relay);
          }
          event onMailFrom {
          call (checkSPF);
          call (WA_AntiSpam_SPF_Fail);
          call (WA_AntiSpam_SPF_Err);
          call (WA_AntiSpam_SPF_None);
          call (Exceptions_Greylisting);
          call (Exceptions_SPF);
          }
          event onRcptTo {
          }
          event onHeadersReceived {
          }
          event onBodyChunk {
          }
          event onDataReceived {
          call (Check_DomainKeys_and_DKIM);
          }
          event onRelay {
          }
          event onDeliveryFailure {
          }
          event onTemporaryDeliveryFailure {
          }
          event onProcessing {
          call (DomainSign-firstdomain_com);
          call (DomainSign-seconddomain_us_com);
          }
          method WA_Acceptance_basic_banner {
          }
          method WA_GeoIP {
          if (
          anyOf (
          isCase (isGeoIPBanned_0, "no")
          )
          ) {
          }
          }
          method WA_Greylisting {
          set (activateGreylisting, "yes");
          }
          method WA_Acceptance_basic {
          set (maxDataSize, "10240");
          set (maxReceivedHeaders, "30");
          set (maxRcptCount, "1000");
          set (waitProcessingTimeout, "10");
          set (allowStartTLS, "yes");
          set (allow8bitMime, "yes");
          set (allowBinaryData, "yes");
          set (allowPipelining, "yes");
          set (localDelivery, "all");
          }
          method WA_AntiSpam_SPF_OnEhlo_Fail {
          if (
          anyOf (
          isCase (SPFResult, "fail")
          )
          ) {
          set (smtpAction, "reject");
          set (smtpExplanation, "SPF check failed for <%ehloHost%> with result <%SPFResult%>: <%SPFExplanation%>");
          }
          }
          method WA_AntiSpam_SPF_OnEhlo_Err {
          if (
          anyOf (
          isCase (SPFResult, "temperror"),
          isCase (SPFResult, "permerror")
          )
          ) {
          }
          }
          method WA_AntiSpam_SPF_OnEhlo_None {
          if (
          anyOf (
          isCase (SPFResult, "none")
          )
          ) {
          }
          }
          method wizard_generated_relay {
          if (
          anyOf (
          ipRange (remoteSmtpIp, "192.168.10.100/255.255.255.0"),
          ipRange (remoteSmtpIp, "127.0.0.1/255.0.0.0")
          )
          ) {
          set (remoteDelivery, "all");
          }
          }
          method WA_AntiSpam_SPF_Fail {
          if (
          anyOf (
          isCase (SPFResult, "fail")
          )
          ) {
          set (smtpAction, "reject");
          set (smtpExplanation, "SPF check failed for <%ehloHost%> with result <%SPFResult%>: <%SPFExplanation%>");
          }
          }
          method WA_AntiSpam_SPF_Err {
          if (
          anyOf (
          isCase (SPFResult, "temperror"),
          isCase (SPFResult, "permerror")
          )
          ) {
          set (smtpAction, "reject");
          set (smtpExplanation, "SPF check failed for <%ehloHost%> with result <%SPFResult%>: <%SPFExplanation%>");
          }
          }
          method WA_AntiSpam_SPF_None {
          if (
          anyOf (
          isCase (SPFResult, "none")
          )
          ) {
          set (smtpAction, "reject");
          set (smtpExplanation, "SPF check for <%ehloHost%> returned no results");
          }
          }
          method WA_DNS_Checks_RDNS {
          if (
          anyOf (
          isCase (ReverseDNSResult, "neutral"),
          isCase (ReverseDNSResult, "fail")
          )
          ) {
          set (smtpAction, "reject");
          set (smtpExplanation, "Reverse DNS check failed for <%ehloHost%> connected from <%remoteSmtpIp%>");
          }
          }
          method WA_DNS_Checks_MX {
          if (
          anyOf (
          isCase (SenderMXCheckResult, "fail")
          )
          ) {
          set (smtpAction, "reject");
          set (smtpExplanation, "Sender domain <%mailFromDomain%> has no DNS MX entry");
          }
          }
          method Exceptions_Greylisting {
          if (
          anyOf (
          ipRange (remoteSmtpIP, "127.0.0.1-127.0.0.1"),
          isCase (mailFromDomain, "gmail.com"),
          isCase (mailFromDomain, "yahoo.com")
          )
          ) {
          set (activateGreylisting, "no");
          }
          }
          method Exceptions_SPF {
          if (
          anyOf (
          isCase (mailFromDomain, "domain1.tld"),
          isCase (mailFromDomain, "domain2.tld")
          )
          ) {
          set (smtpAction, "accept");
          set (smtpExplanation, "Accepted due to requested SPF exception");
          }
          }
          method Check_DomainKeys_and_DKIM {
          call (checkDomainKeys);
          call (checkDKIM);
          }
          method DomainSign-firstdomain_com {
          if (
          anyOf (
          isCase (mailFromDomain, "firstdomain.com"),
          not (
          is (authUser, "")
          )
          )
          ) {
          set (DKSignerKey, "dkim._privkey.firstdomain.com.pem");
          set (DKSignerSelector, "2017");
          call (signDomainKeys);
          set (DKIMSignerKey, "dkim._privkey.firstdomain.com.pem");
          set (DKIMSignerSelector, "2017");
          call (signDKIM);
          }
          }
          method DomainSign-seconddomain_us_com {
          if (
          anyOf (
          isCase (mailFromDomain, "seconddomain.us.com"),
          not (
          is (authUser, "")
          )
          )
          ) {
          set (DKSignerSelector, "2016");
          set (DKIMSignerSelector, "2016");
          set (DKSignerKey, "dkim.privkey.seconddomain.us.com.pem");
          set (DKIMSignerKey, "dkim.privkey.seconddomain.us.com.pem");
          call (signDomainKeys);
          call (signDKIM);
          }
          }

          Comment


          • #6
            Hello Marc,

            It seems you have not used "ALL of the conditions below" (as mentioned in the instructions you have followed) but the default "ANY of the conditions below" and this fact is explaining the reported behavior.

            Could you recheck your signing rules?

            BR,
            Ioan

            Comment


            • #7
              Thanks Loan, that did it! But whooie, that is a bit subtle and a very easy mistake to make... IMHO... It will be good to leave this thread around so others can find it and follow in my footsteps! I will keep testing (gotta make sure DMARC is fully working as well, but I don't see why it wouldn't) and get back to you if I encounter any more problems. I think I have enough info/experience to make a recommendation at work and hopefully the management will pick Axigen and buy it... But there are a couple other servers the team is looking at and I suspect Postfix will be the biggest contender... Regardless I will keep using Axigen on my home personal server I think, I like the webmail feature a lot, but they seem somewhat tepid about it at work...

              Thanks again so much, you have been wonderful at helping me along... Marc..

              Comment


              • #8
                Hello Marc,

                I'm glad to hear that all seams fine.

                Regarding DMARC I have to add that it is not currently supported in Axigen but it should be easily integrated via the Axigen Milter interface (for example using OpenDMARC).

                HTH,
                Ioan

                Comment


                • #9
                  Loan, I am going to continue this thread with a question that I think is within the realm of what the topic of this thread is about. Can you (or anyone else) explain to me what are the exact consequences of the Action rules for "Check DKIM" and "Check Domain Key"? These get assigned to the "On Data Received" event which is close to the last set of events processed in my Acceptance/Routing rules so I presume the consequences of their actions will override any of the previous events's actions. Does these check ignore emails that are not signed with a DKIM or Domain Key, or do they consider such emails as failures and terminate processing them?

                  On a bit deeper level, it appears that emails I receive from some (but not all) mail lists are failing to get processed and I am trying to track down why. This may be one area that I want to pursue and so I am trying to grok what these checks do and how they impact email processing. I looked for but was unable to find any comprehensive documentation about these Action rules other than a simple "cookbook" set of instructions for setting them... https://www.axigen.com/documentation...-dkim-p3277108

                  Marc...

                  Comment


                  • #10
                    Hello Marc,

                    The mentioned actions have the effect of setting special headers like: X-AXIGEN-DK-Result and DomainKey-Status, respectively X-AXIGEN-DKIM-Result and DKIM-Status.

                    Based on these headers you could take any further actions.

                    For example WebMail interface is using them to display a small icon after the sender address.

                    HTH,
                    ​Ioan

                    Comment


                    • #11
                      Hi, I am trying to integrate OpenDMARC via Axigen Milter Interface. The filter connects perfectly to Axigen but to my great disappointment there is no Authentication-Results header can be found in the incoming messages after filtering. In the SMTP-IN log I can see only 'accept' response from the [MILTER] and no 'add_header' or something like that. But if I use opendmarc in test mode with test message and verbose logging through the terminal command line I can see the insert header directive in logs. Is it necessary to configure some dmarc.afsl protocol file for example to make the filter work properly?

                      Comment


                      • #12
                        Hello,

                        Please increase SMTP Incoming service log level to Protocol Communication and share here the Axigen SMTP-IN log lines related to one incoming message. Also please share your smtpFilters.script (default location is in /var/opt/axigen/log/filters).

                        Also, what about OpenDMARC logs?

                        BR,
                        Ioan


                        Comment


                        • #13
                          Hello,

                          Requested files are attached.
                          What about OpenDMARC logs I can see only standard output there like

                          opendmarc[21450]: 2240271: SPF(mailfrom): account@gmail.com pass
                          opendmarc[21450]: 2240271: gmail.com pass

                          Looking forward for your help.

                          Best regards,
                          Art
                          Attached Files

                          Comment


                          • #14
                            Hello Art,

                            OK - let's enable the OpenDMARC SoftwareHeader option
                            Code:
                            SoftwareHeader true
                            in order to validate if the DMARC-Filter header will be added to the processed message.

                            As mentioned before, please provide us a the Axigen SMTP-IN logs for a new incoming message after the above option was enabled.

                            In the same time please start on your Axigen server a tcpdump capture (like below) in order to let us check what milter commands are exactly sending OpenDMARC.
                            Code:
                            tcpdump -i any -s 0 -w /var/log/openDMARC.pcap port 8893
                            Looking forward for your data (both log and pcap files).

                            BR,
                            Ioan

                            Comment


                            • #15
                              Hello,

                              I have performed all the operations. Requested files are attached.

                              smtpin_log_new.txt
                              openDMARC.pcap.txt

                              Best regards, Art

                              Comment

                              Working...
                              X