Djigzo uses the "From:" header of the mail to decide which sender
certificate to use. As the header is set by the MUA it is prone to
spoofing and therefore the decision which certificate to use may be
wrong. What is the reason to use the header in this case and not the
envelop sender (MAIL FROM) as it is the case for the recipient?
I saw your message on the Postfix mailing list about forcing the from
header to be the same as the SASL user
The envelope sender (the MAIL FROM) can be spoofed as easily as the From
header (the only difference is that Postfix allows you to match the
envelope sender to the sasl user). The reason for using the from header
is that the from represents the identity of the sender and the envelope
sender is the postman. The envelope sender is used when a message
bounces for example. For example Outlook express checks whether the from
header is equal to the email address in the certificate for signed
messages and if the email addresses do not match a big warning is shown.
Same with Thunderbird (A question mark is shown op top of a blue envelope)
Not long ago one of our users mistakenly believed that Djigzo was using
the enveloped sender instead of the from header and asked. Quote "..what
is involved in making Djigzo use the "From" header to select the signing
certificate instead of the envelope sender?"
There are probably tons of good reasons why using the envelope sender is
better than using the from header and visa-versa. I think using the from
header better reflects the identity of the sender.
There are multiple solutions (not all of them implemented yet) to your
1) Let Postfix remove the from header. Postfix will add the envelope
sender as the from header (as discussed on Postfix mailing list)
2) Create a mailet that checks whether the envelope sender is equal to
the from and if not bounce the message
3) Create a mailet that makes the from header equal to the envelope sender.
The database potentialy hold the private keys used for signing and
decryption and should therefore be secured as much as possible. In the
standard installation a default password is used and no obvious warning
is in the documentation that on should at least prevent remote access to
PostgreSQL. This is default for PostgreSQL in some cases but not in all.
If one change the password in hibernate.cfg.xml this file is
world-readable at least when installed by .deb files. Is it possible to
do the following change: Include a warning to protect access with the
Djigzo DB-user and maybe a option to use access control based on the OS
user which is "djigzo" anyway (local socket) so no handling with
passwords is required for the DB.
I'll check whether Postgres works with ident instead of login.
>>Include a warning to protect access with the
I will add a warning to the documentation.
Is there any documentation which ports are used and what they are used
for? We have the following ports after std. .deb install:
15012 (localhost) --> no problem
9000 (*) --> ??
10025 (*) --> James Mailinput
8443 (*) --> Web-Interface
8282 (*) --> ??
So two ports might be unused but open.
The posts used by Djigzo are
9000 communication between back-end and from-end
10025 The MPA port
8443 Web interface
15012 this is I think a port used by Java (this is dynamically chosen
and is not always the same port)
8282 I will check this
Djigzo open source email encryption