Archive for May, 2018


05/23/2018 No comments

Domain Keys Identified Mail (DKIM) allows the senders of an email to associate a domain name with an email message.

  • A digital signature is added to a field in the message header (signing).
  • A signature is generated by the sending mail transfer agent (MTA) using an algorithm. The algorithm reviews the content and creates a unique string of characters (hash value).

When the signature is generated, a public key used to generate it stores at the listed domain. After recieveing the email, the reciepent’s MTA can verify the signature by checking the public key though DNS. It then uses the key to decrypt the hash value in the header and simultaneously recalculates the hash value for the mail message it received. If the two values match, then the email has not been altered. Confirms e-mail did originate from listed domain, and it has not been modified since being sent.


KIM-Signature a=rsa-sha1; q=dns;;;
s=jun2005.eng; c=relaxed/simple;
t=1117574938; x=1118006938;


  • b = the actual digital signature of the contents (headers and body) of the mail message
  • bh = the body hash
  • d = the signing domain
  • s = the selector
  • v = the version
  • a = the signing algorithm
  • c = the canonicalization algorithm(s) for header and body
  • q = the default query method
  • l = the length of the canonicalized part of the body that has been signed
  • t = the signature timestamp
  • x = the expire time
  • h = the list of signed header fields, repeated for fields that occur multiple times

We can see from this email that:

  • The digital signature is dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR.
    This signature is matched with the one stored at the sender’s domain.
  • The body hash is not listed.
  • The signing domain is com.
    This is the domain that sent (and signed) the message.
  • The selector is eng.
  • The version is not listed.
  • The signing algorithm is rsa-sha1.
    This is the algorith used to generate the signature.
  • The canonicalization algorithm(s) for header and body are relaxed/simple.
  • The default query method is DNS.
    This is the method used to look up the key on the signing domain.
  • The length of the canonicalized part of the body that has been signed is not listed.
    The signing domain can generate a key based on the entire body or only some portion of it. That portion would be listed here.
  • The signature timestamp is 1117574938.
    This is when it was signed.
  • The expire time is 1118006938.
    Because an already signed email can be reused to “fake” the signature, signatures are set to expire.
  • The list of signed header fields includes from:to:subject:date.
    This is the list of fields that have been “signed” to verify that they have not been modified.


  • pass= ‘The message was signed, the signature or signatures were acceptable, and the signature(s) passed verification tests.’
    This is the result you want to see. Everything worked perfectly.
  • fail= ‘The message was signed and the signature or signatures were acceptable, but they failed the verification test(s).’
    This means that the message had a signature, and the signature was formed correctly, but didn’t match the signature of the sending domain. This probably means the message was modified somewhere along the way.
  • none= ‘The message was not signed’
    This means that the message had no DKIM signature. This is not the same as failing.
  • policy= ‘The message was signed but the signature or signatures were not acceptable.’
    DKIM can be configured to be more or less stringent in what is an acceptable match. A “policy” error means that the message was signed and correctly formed, but didn’t meet the policy requirements of the recipient.
  • neutral= ‘The message was signed but the signature or signatures contained syntax errors or were not otherwise able to be processed.’
    The message was signed, but it was not formed correctly. This is possibly a configuration error on the sending domain side.
  • temperror= ‘The message could not be verified due to some error that is likely transient in nature, such as a temporary inability to retrieve a public key. A later attempt may produce a final result.’
    This error indicates that there was a short-term problem verifying the signature. Feel free to try again. Repeated problems with this may indicate a DNS or lookup failure on the sending domain.
  • permerror= ‘The message could not be verified due to some error that is unrecoverable, such as a required header field being absent. A later attempt is unlikely to produce a final result.’
    The signature (or some part of it) was missing from the recieved message, which caused a failure. This indicates that either the header was formed incorrectly or it was modified after being sent.



Categories: Uncategorized Tags:

Check if Powershell variables

05/09/2018 No comments

Check if variable has the right value and are not “null”.
Now how you can check that (check if $variablename has $null as value):

if (!$variablename) { Write-Host “variable is null” }

And here if you wanna check if $variablename has any value except $null:

if ($variablename) { Write-Host “variable is NOT null” }

Categories: Uncategorized Tags:

How to check out of office status in Exchange

How to check out of office status in Exchange
Get-MailboxAutoReplyConfiguration “username”

Replace the “username” phrase with the user mailbox name to get the result.
Among other properties, command returns additional information.

To get the automatic reply status for all mailboxes:

Get-Mailbox | Get-MailboxAutoReplyConfiguration

Filter and show only users with Out-Of-Office enabled:

Get-Mailbox | Get-MailboxAutoReplyConfiguration | Where-Object { $_.AutoReplyState –eq “scheduled” }

Disable the OOF message for the selected mailbox:

Set-MailboxAutoReplyConfiguration -Identity “user” -AutoReplyState Disabled

Categories: Uncategorized Tags:

Basic CRL checking with certutil

05/08/2018 No comments

If you have a certificate and want to verify its validity, perform the following command:
certutil -f –urlfetch -verify [FilenameOfCertificate]

The command output will tell you if the certificate is verifiable and is valid.
Any dwErrorStatus unequal 0 is a real error.

For more information on the status see CERT_TRUST_STATUS ( on MSDN.

If you have a HTTP or LDAP URL and want to look at the CRL, use the following command:

certutil -URL [URL]
certutil -URL

The URL can be a HTTP or LDAP URL. The nice thing with the –URL verb is that it shows a user interface where also the retrieval timeout can be set. Thus, it might be, that a CRL can be retrieved with an extended retrieval timeout while certutil -verify fails because it uses the default timeout. To also extend the retrieval timeout for the -verify verb, use the -t option like this:

certutil –t 30 -f –urlfetch -verify [FilenameOfCertificate]

Sometimes, you not only want to look at the CRL but also want to download the CRL as a file. In this case, use the -split option like this:
certutil –split -URL


certutil –split -URL ldap://myLDAPserver/CN=MyCA,CN=CRL,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=contoso,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint

The -split option creates a file named “BlobX_X_X.*” in your current working directory. If multiple CRLs are downloaded several Blob*.* files are created. As a global option, -split can also be used with other certutil verbs, for example:

certutil -f –split –urlfetch -verify [FilenameOfCertificate]

If the certificate is part of a multi-tier CA topology or delta CRLs are used, you will see a Blob*.* file for each CRL in the chain.
Once a CRL was downloaded, it is cached locally. To examine the URLs of CRLs that are in the local cache, perform the following command:

certutil –urlcache CRL

Categories: Uncategorized Tags: