Re: [Sqlgrey-users] warn_if_reject to populate the db

[Michael S. <Mic...@lr...>]

On Wed, 29 Jun 2005, Who Knows wrote:

> Okay, here is my $0.02. They DO NOT strengthen the greylisting process
> as they have
> nothing to do with greylisting. They are simply other methods for
> combatting SPAM.
>
> Any utility that attempts to be the omnicient "do all" ultimately fails.
> Therefore
> my vote is that SQLgrey should do what is does best... greylisting.
>
> Jim
>

I do not think there was a request to "enhance" sqlgrey to a "do all"
daemon. I agree with you every new feature must be related to greylisting.
I suppose you do not want to run a pure greylisting server, because that
means to switch off the from_awl und domain_awl. Pure greylisting is done
with connect and a simple whitelist for not well behaving MTAs. And this
list can be very short, as I have experienced in the meantime.

At the moment you use AWLs, you are not using pure greylisting anymore.
And I think you ARE using sqlgrey because of its excellent AWLs.

The goal of all future enhancements are twofold:

- they should put as many entries as possible in AWLs to reduce the delay
  of regular messages
- they should reduce the possibility that spam mails make use of entries
  in the whitelists

You must always see these two goals together, they cannot be separated.

Coming to SPF. If you want to use SPF to combat spam directly, then you
should use a program/policy server outside of sqlgrey. The way I am using
SPF is to get entries faster in domain_awl than using group_domain_level
alone. SPF is a hint, that the sending IP is authorized to send emails
with this originator. But it is only a hint. The MTA has still to prove it
is a well behaved MTA (at the moment we use 3 retries = 3 entries in
from_awl, whereas group_domain_level is set to 10). This kind of usage of
SPF is a way to strengthen greylisting/sqlgrey.

The same is true for the rcpt_awl, we need for forwarded emails. We have a
lot of employees, which separate their email addresses for business and
private use. For their privat emails they use an address with a freemail
provider. All emails arriving at the freemail provider are forwarded to
their business address, which is allowed in our university environment.
This way they have separated their addresses, but still have all emails
together in one mailbox, where they can be accessed immediately.

The other case is, a lot of employees of the universities come from other
universities. When they moved, they set up a forward to an email address
here.

In both cases we want to accept such forwarded emails immediately without
any delay. But with from_awl and domain_awl alone, it is not possible. The
sending MTA may have an entry in domain_awl, but normally only for the
domains it is responsible. But often the forwarded emails have an
originator with a different domain. Therefore every new originator will go
through greylisting, which makes no sense, because often we now that the
sending MTA is a well behaved MTA and we trust this MTA.

With rcpt_awl this is different. In this table we will include the ip
address of the MTA and the recipient address, but no information about the
originator. That means we need only one entry per forward and all emails
coming this way will be accepted immediately. And this means greylisting
is strengthened again.

I hope it is now clear what I meant with:

"If these additions will strengthen the greylisting process, then they
should be implemented."

Michael Storz
-------------------------------------------------
Leibniz-Rechenzentrum   !   <mailto:St...@lr...>
Barer Str. 21           !   Fax: +49 89 2809460
80333 Muenchen, Germany !   Tel: +49 89 289-28840