[Kolab-devel] [merge67] Introduce postfix helo checking

[Gunnar Wrobel]

Gelpi Andrea <liste at gelpi.it> writes:

> Fabio Pietrosanti wrote:
>> New submission from Fabio Pietrosanti <fp at khamsa.ch>:
>> 
>> # Introduce helo checking (otherwise disabled by default)
>> smtpd_require_helo = yes
>> smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, 
>> reject_invalid_hostname, reject_unknown_hostname, reject_non_fqdn_hostname
>> 
>> In this way a simple and useful antispam feature is added (without breaking anything)
>
> As I sayd before I tested it and found that reject_unknown_hostname is too 
> aggressive.

Same here.

The Kolab server is a system that is responsible for delivering mails
to quite many people and it is clear that we cannot introduce any
setting that lead to users being inaccessible and not receiving
mails. Even if these are just a few.

A system admin that is still new to mail servers will have a hard time
determining why certain mails get lost.

So the default for the server should be a policy that is very open
even if that means that too much spam gets through.

Of course it is very good if alternatives are being discussed and we
should probably make using such alternatives easier with the Kolab
server if people would like to lock there server down to a stronger
degree. With the levels of spam always on the rise this is an
understandable desire.

>
> There large and important farm that don't have their smtp listed in any dns.
>
> So I modified it to have the opportunity to insert a white list for that.

>
> This is my configuration:
>
> smtpd_helo_required = yes
> smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, 
> check_helo_access hash:/kolab/etc/postfix/helo_access,
>   reject_invalid_hostname, reject_unknown_hostname, reject_non_fqdn_hostname

This makes it obvious that such settings require more insight and also
more care from the sys admin than the current postfix settings.

And it also highlights that the policy at each site will differ
slightly. As mentioned above I believe the Kolab server should always
have an open policy. But maybe we are capable of making it easier to
modify and control the postfix settings so that the admins don't have
to experiment that much. There is a lot of knowlegde available from
the different Kolab server admins as is obvious from this discussion
and we should certainly try to make that available to others that
don't have a lot of experience with MTAs.

Cheers,

Gunnar

>
>
> -- 
> ing. Andrea Gelpi
> ***************************************************
> La Terra non la abbiamo ereditata dai nostri avi,
> ma la abbiamo presa in prestito dai nostri bambini.
> ***************************************************
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~