I have added a JIRA feature request (https://jira.djigzo.com/browse/GATEWAY-36). I don't think it will be included with 2.3.1 release since that has already been "feature freez'd". It will be included after the 2.3.1 release.
Kind regards, Martijn On 10/27/2011 11:19 AM, [email protected] wrote: >> > On 10/27/2011 09:25 AM, matthiasdort wrote: >>>>> >>>> I guess something like a "[Signed]" tag in the subject to show the >>>>> >>>> end >>>>> >>>> user (internal recipient) that the message was signed and could be >>>>> >>>> verified when hitting the Djigzo Gateway. >>>> >>> >>>> >>> >>>> >>> >>>> >>> Thank you Andreas, yes, this is exactly what i mean. >> > >> > This is not (yet?) supported. The main question is where are you using >> > the tag for? The reason I'm asking is that a tag line can lead to a >> > false sense of security. For example suppose an external sender sends a >> > non-signed message that contains the tag [Signed] in the subject? >> > You might argue that all incoming email should be scanned for such a tag >> > and have the tag be removed. Ok, then what about [ signed ]? Again you >> > might argue that the scanning should work on a regular expression and >> > should skip all spaces. Ok, then I come up with the following example, >> > {Signed}, or just Signed, or Signd. >> > Just as long as your end-users just use the tag as an indication that >> > the message *might* be signed, this should not be a problem. The problem >> > starts when end-users *assume* the message is signed and trusted because >> > the subject contains some kind of tag. >> > >> > The best way to detect whether a message is signed and is trusted is by >> > using an S/MIME capable email client. If however you are not using an >> > S/MIME capable email client or are stripping the S/MIME signatures this >> > won't help. The gateway will however add certain header fields which >> > indicate whether the email is signed and whether the signature was >> > trusted/valid etc. Appendix A of the "S/MIME setup guide" briefly >> > explains these headers. Since all X-Djigzo-* headers are removed from >> > any incoming email, those headers cannot be spoofed. The trouble however >> > with these headers is that it's hard for end-users to read and interpret. >> > >> > To conclude, I'm not saying that adding some kind of keyword/tag to the >> > subject should never be done. But, you should be careful on what it >> > means for your end-users when the subject contains a certain keyword/tag. >> > >> > What is currently missing is a mailet (a mailet is a small piece of >> > software that handles an email) that can add something to the current >> > subject of a message. I will add this to the todo list. If such a mailet >> > is available, you can add this functionality to the xml mail flow >> > specification and match when the email contains the keywords. This might >> > actually be done with Postfix as a workaround. > Actually most of the end users don't care or don't have a deep > understanding of the security implications anyway. It might be useful > to train the users that they can, to some extend rely on a Tag in the > subject to: > - be sure the sender is really the one claimed > - the message was not altered in transit > - they can send encrypted mail to that sender > > This can be spoofed as you said by similar looking Tags, but try to > trick the users is at least more difficult then. > >> > One last question, is there a reason you cannot use an S/MIME email >> > client to check the signatures? > There are two possibilities: > - We have for example an internal message system which is not S/MIME > aware and this might apply to other ticket or workflow based systems > as well > - The S/MIME handling should be limited to the gateway because the > internal certstores are not managed and might not have the CAs needed > or more than desired > > Furthermore this would be easier to support within organisations using > many different mailclients with many different UIs showing signed > messages in many different ways. > > But as you noticed it has also disadvantegs. The user should not learn > to blindly rely on a subject Tag. But in pratice most of them do not > see any difference between a subject Tag and a "signed" Icon in there > mailclient anyway :-( > > If it is not too much work, i'll vote for it... -- Djigzo open source email encryption _______________________________________________ Users mailing list [email protected] http://lists.djigzo.com/lists/listinfo/users
