« previous 1 2 3 4 5 6 7 next »

Practice

The DKIM standard is now more than six months old, yet only a few admins have taught their servers the method, even though it can even be integrated in a mail system that is armed to the teeth with anti spam and anti virus filters – given the right planning.

A DKIM signature in an email doesn't do any harm, but the technology's spam-prevention effect improves with the number of domains that send out signed emails. Postmasters who want to teach their mail servers how to sign and verify incoming and outgoing emails according to RFC 4871 must first ensure that their own mail server can't be exploited to send out spam. The blessing of an injected fake email with a sender's signature would have fatal consequences for this sender's reputation. The recipient could no longer use this signature for filtering, and the signature would be redundant. Once the server holds water, the admin needs to plan where on the mail transport path a message is to be processed. This is the only way to ensure both that DKIM doesn't mess up established procedures and that the existing processes don't interfere with DKIM.

Only once the planning is complete does the postmaster generate the keys and integrate them into the SMTP and DNS services. This allows the system to add DKIM signatures and recognise DKIM signatures in emails. To use the signature information for filtering out spam and phishing emails, the postmaster finally has to adjust the system's content filters.

Please sign here

DKIM can be integrated into the Postfix mail system in various places. A typical mail server consists of several components covering the individual aspects of the email transport path. The task of an SMTP server – in this article it will be Postfix – is to accept emails from the internet; a mailing list program like mailman distributes messages to subscribers, and a content inspection engine (here, amavisd-new) controls the verification of messages through filters like SpamAssassin, separating the good from the bad.

In principle, the accepting server can already check the signature during its SMTP session with the sender and before accepting the email (position 1 in the top right illustration). The signature can alternatively also be checked in the content filter once the email has entered the system (position 2). In the first version, the sending server delivers the email to the DKIM enabled server and waits for confirmation within the SMTP session. The receiving server checks the signature – quite in keeping with the RFC – before returning a reply and issuing an error message in case the verification failed. The advantage of this method is that the sending server finds out immediately and can advise its sender accordingly. Otherwise the transport responsibility is handed over to the receiving mail server, and the sending server can remove the message from its queue.

The disadvantage of this solution is that in practice an early verification can only rarely be implemented robustly. By the time a busy server has decided whether to accept a message, the other server may long have terminated the SMTP session. The verifier first needs to retrieve the public key from a DNS far out there on the internet. Secondly, the cryptography calculations take up quite a bit of CPU time. Depending on the receiving server's load, this could take up enough time for the sending server to time out and the session to be terminated. Although there will generally be another attempt later, verification might once again take too long. The message may eventually fail and be returned to the sender.

It is, therefore, better to verify the signature later, especially if no solid information about system resources and about the own mail system's behaviour under load is available. In this case, the server accepts the email and the subsequent chain of filters processes it once there are no more impatient sender servers to deal with. Once accepted, however, a message has to be delivered to the user by the server.

« previous 1 2 3 4 5 6 7 next »