# Some security related questions

**URL:** <https://community.ciphermail.com/t/some-security-related-questions/71>\
**Category:** Gateway\
**Created:** [December 3, 2009, 8:17am UTC](https://community.ciphermail.com/t/some-security-related-questions/71 "2009-12-03T08:17:16Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![martijn](https://dub1.discourse-cdn.com/flex017/user_avatar/community.ciphermail.com/martijn/32/127_2.png) [@martijn](https://community.ciphermail.com/u/martijn)\
**Post date:** [December 3, 2009, 8:17am UTC](https://community.ciphermail.com/t/some-security-related-questions/71/1 "2009-12-03T08:17:16Z")

</div>

lst\_hoe02(a)kwsoft.de wrote:

> > 1) Let Postfix remove the from header. Postfix will add the envelope  
> > sender as the from header (as discussed on Postfix mailing list)
> 
> This is only useful if Djigzo should be limited to be used with Postfix.
> 
> > 2) Create a mailet that checks whether the envelope sender is equal to  
> > the from and if not bounce the message
> 
> This would be the most "secured" possibility. Not sure how this would  
> interact with BATV and the like.
> 
> > 3) Create a mailet that makes the from header equal to the envelope  
> > sender.
> 
> Could this be configurable to choose between 2. and 3. maybe even in the  
> web-interface...

I prefer solution 3 because you can tell Postfix that it should not  
accept the message when envelope sender is not equal to the SASL  
authenticated user. With solution 3 Djigzo then makes sure that the from  
is equal to the envelope sender.  
A problem with both solutions is that the check should only be done when  
the user has authenticated via SASL (and when you enable the option of  
course). You can add a SASL Authenticated header to the Received header  
but I don't know how reliable checking for this is.

> This is something from Jetty installed by default (see  
> /etc/jetty6/jetty.xml) and i'm not sure if it is save to disable...

I will check this

Kind regards,

Martijn

> **···**
>
> --  
> Djigzo open source email encryption

---

<div class="post-metadata">

**Author:** ![lst\_hoe021](https://avatars.discourse-cdn.com/v4/letter/l/58956e/32.png) [@lst\_hoe021](https://community.ciphermail.com/u/lst_hoe021)\
**Post date:** [December 3, 2009, 9:07am UTC](https://community.ciphermail.com/t/some-security-related-questions/71/2 "2009-12-03T09:07:00Z")

</div>

Zitat von Martijn Brinkers \<martijn(a)djigzo.com\>:

> lst\_hoe02(a)kwsoft.de wrote:
> 
> > > 1) Let Postfix remove the from header. Postfix will add the envelope  
> > > sender as the from header (as discussed on Postfix mailing list)
> > 
> > This is only useful if Djigzo should be limited to be used with Postfix.
> > 
> > > 2) Create a mailet that checks whether the envelope sender is equal to  
> > > the from and if not bounce the message
> > 
> > This would be the most "secured" possibility. Not sure how this would  
> > interact with BATV and the like.
> > 
> > > 3) Create a mailet that makes the from header equal to the envelope  
> > > sender.
> > 
> > Could this be configurable to choose between 2. and 3. maybe even in the  
> > web-interface...
> 
> I prefer solution 3 because you can tell Postfix that it should not  
> accept the message when envelope sender is not equal to the SASL  
> authenticated user. With solution 3 Djigzo then makes sure that the from  
> is equal to the envelope sender.  
> A problem with both solutions is that the check should only be done when  
> the user has authenticated via SASL (and when you enable the option of  
> course). You can add a SASL Authenticated header to the Received header  
> but I don't know how reliable checking for this is.

I would not say it should only be done with SASL. We should clearly  
state in the documentation that the input mailadresses must be  
validated to prevent fraud, but this should not be limited to  
SASL-AUTH in any way. A simple turn-on/tun-off option for solution 3.  
would be my favourite.  
The rest is up to the administration.

Regards

Andreas