[Djigzo users] Notify about a successfully complete for signcheck

lst_hoe02 at kwsoft.de lst_hoe02 at kwsoft.de
Thu Oct 27 11:19:32 CEST 2011

Zitat von Martijn Brinkers <martijn at djigzo.com>:

> 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...



More information about the Users mailing list