Messaging Server, MTA Preferred Practices, and Question on DKIM

Reader rolf had this to say about my draft doc titled Messaging Server: MTA Preferred Practices:
I'm very pleased to see this document. It has a clear structure and is easy to read.

If time permits I'll post a more descriptive review. One of the first things that I noticed is that SPF is mentioned, but DKIM is not. From a marketing perspective it is a good idea to mention SPF, but from a technical point of view it's more important to mention DKIM, and the way it can be used in such a configuration.

To respond to this comment, we brought up the topic of DKIM up with an MTA engineer. In brief, the answer is that how you perform DKIM checks has no bearing on how you implement your AS/AV solution with respect to the MTA. On the other hand, your implementation of AV/AS services in front of the MTA definitely impacts SPF, because of its dependency on IP address information.

Additionally, we have omitted describing DKIM in this paper because it raises no unique issues of its own in regards to deployment design that aren't already there for other reasons.

Note: DKIM is a signature-based mechanism. The signature validation is done based on information provided through a header. As such, the system can perform DKIM checks whether or not you place an AS/AV appliance in front of the MTA. (An AV/AS appliance may alter message content in such a way as to break the signature, but that is highly unlikely).

Update, 12/13/07:

We understand that DKIM is something a lot of people want to know more about and we'll undoubtedly have additional materials discussing DKIM in the future - especially once the SSP part of DKIM is finished.

Comments:

Regarding DKIM there are, in my view, two arguments to deploy an DKIM verifier in front of an AV/AS solution (as seen from the Internet), i.e. Internet - MTA - AV/AS - internal mail service. These arguments are:

1 many anti-spam solutions including anti-spam appliances provide the option to prepend or append a tag to the Subject of a message, e.g. a tag like [SPAM] or something similar. Modifying the subject line in most situations break the DKIM header signature.
2 the other reason is, that an AV/AS solution can take the outcome of the DKIM signature validation as input to the spam-scoring process. If the AV/AS solution is in front of the MTA, the outcome of the DKIM validation/verification process cannot be used by the AV/AS solution.

/rolf

Posted by Rolf E. Sonneveld on October 08, 2009 at 04:23 AM MDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Reporting about Unified Communications Suite Documentation, including news, Comms 101, documentation updates, and tips and tricks.

Search

Archives
« July 2015
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
       
Today