[Djigzo users] Notify about a successfully complete for signcheck

Martijn Brinkers martijn at djigzo.com
Thu Oct 27 11:37:01 CEST 2011


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, lst_hoe02 at kwsoft.de 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



More information about the Users mailing list