[Kolab-devel] TO all anti-spam enthusiasts

[Alain Spineux]

On Dec 14, 2007 9:06 AM, Fabio Pietrosanti <lists at infosecurity.ch> wrote:
> Gunnar Wrobel wrote:
> > I fully subscribe to that view and also believe that we need to be
> > very, very careful about changing postfix configurations. The proposed
> > changes will of course get discussed but I believe the last thing
> > anybody of us wants is to have legitimate messages being blocked.
> >
>

Hi Fabio,
first remember I thing your experience is very beneficial for all :-)

Anyway, for some users, dropping a legitimate mail is more problematic
than receiving Spam.
Unfortunately when you drop an email that way you can be sure it was Spam.
You are reporting some statistics about emails traffic decrease, but you don't
provide any statistics about false negative! Yes I know this is more difficult.
But implementing some Spam catcher (false addresses you publish on the
internet to
catch Spam and only Spam) will help to have _real_ statistic about
Spam and not only
general (including legitimate) mails.

To resume my advice.

Ok for anti-Spam features, but under the control of the administrators and only
with its agreement and self-choice (I mean not the default).

These feature are very easy to configure from the Webadmin interface,
using the kolab's template
engine. And has I proposed long before these feature can be aesily
configured per domain instead of
per server.
A least it can be described into a wiki!

Regards.


> I experienced a strong reduction of spam by implementing most postfix
> features, even static one.
>
> This because *most* spammer are using misconfigured software, are using
> infected pc from adsl/cable connection and doesn't respect the "tipical"
> configuration of an MTA.
>
> We work on errors of spammer and on correctness of system administrated
> real email systems (the effort put by system administrator to have stuff
> working).
>
> It's true that "dynamic" measures works well against spam, but if you
> make a body_checks that look for:
> v1agra
> vi4gr4
> c1al1s
>
> you will drop 2-3% of spam and will not have issue with users.
>
> If you include checking of MX of sender, you will drop another 2-3% and
> so on.
>
> So antispamming is not an exact science, there's no single magic
> solution but only implementing most techniques one over each other it's
> possible to "reduce" the spam.
>
> Again, regarding dynamic filtering, imho greylisting for example is not
> acceptable for most users because of the delay it introduce.
>
> I was asked by my customers to remove it and to implement something
> that, if an email is blocked, the sender is immediately notified so he
> will know it.
>
> The best approach to antispam that i found is to "prevent" access to the
> email system to "illegal" emails.
> So having most of the checks that prevent the entry of an email messages
> into the postfix smtpd message flow.
> This is my ideal policy.
>
> Then, other dynamic post-processing made bayesian rules of spamassassin
> for example, help in reducing again the spam that pass the 'frontend'
> filters.
>
> It's even a matter of how much you want to be aggressive respect to the
> rest of the other email systems (like for the 550 errors).
>
> There are some "antispam check" that are acceptable for most, some for
> few persons.
>
> For example i do not accept email from the following hosts:
>
> /^dsl.*\..*/i 553 AUTO_DSL We aren't accept direct connection not from
> dedicated SMTP servers. Please use your internet provider SMTP Server.
> /.*\.dsl\..*/i 553 AUTO_DSL2 We aren't accept direct connection not from
> dedicated SMTP servers. Please use your internet provider SMTP Server.
> /[a|x]dsl.*\..*\..*/i 553 AUTO_[A|X]DSL We aren't accept direct
> connection not from dedicated SMTP servers. Please use your internet
> provider SMTP Server.
> /client.*\..*\..*/i 553 AUTO_CLIENT We aren't accept direct connection
> not from dedicated SMTP servers. Please use your internet provider SMTP
> Server.
> /cable.*\..*\..*/i 553 AUTO_CABLE We aren't accept direct connection not
> from dedicated SMTP servers. Please use your internet provider SMTP Server.
> /pool\..*/i 553 AUTO_POOL We aren't accept direct connection not from
> dedicated SMTP servers. Please use your internet provider SMTP Server.
> /.*dial(\.|-).*\..*\..*/i 553 AUTO_DIAL We aren't accept direct
> connection not from dedicated SMTP servers. Please use your internet
> provider SMTP Server.
> /ppp.*\..*/i 553 AUTO_PPP We aren't accept direct connection not from
> dedicated SMTP servers. Please use your internet provider SMTP Server.
> /dslam.*\..*\..*/i 553 AUTO_DSLAM We aren't accept direct connection not
> from dedicated SMTP servers. Please use your internet provider SMTP Server.
> /dslb.*\..*\..*/i 553 AUTO_DSLB We aren't accept direct connection not
> from dedicated SMTP servers. Please use your internet provider SMTP Server.
> /node.*\..*\..*/i 553 AUTO_NODE We aren't accept direct connection not
> from dedicated SMTP servers. Please use your internet provider SMTP Server.
> /.*\.dynamicIP\..*/i 553 AUTO_DYNAMIC We aren't accept direct connection
> not from dedicated SMTP servers. Please use your internet provider SMTP
> Server.
>
> But this is not a generically acceptable policy even if is highly
> effective against infected pc sending spam and doesn't even caused 1
> single issue to my users.
>
> So imho we should carefully add all the checks that could be useful and
> then provide to the system administrator the opportunity, knowing what
> he is doing, to enable or disabled the most aggressive antispam features.
>
> Regards,
>
> Fabio
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
Alain Spineux
aspineux gmail com
May the sources be with you