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

[Michel B. <mi...@bo...>]

Le Jeudi 30 Juin 2005 10:35, Michael Storz a =E9crit :
>
> I suppose you do not want to run a pure greylisting server, because tha=
t
> means to switch off the from_awl und domain_awl. Pure greylisting is do=
ne
> with connect and a simple whitelist for not well behaving MTAs. And thi=
s
> 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.

AWLs are just "greylisting with a memory". I don't agree that using AWLs =
isn't=20
"pure greylisting".

> [...] The way I am using SPF is to get entries faster in domain_awl tha=
n
> 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 [...]

The major objections that I see to integrating any kind of SPF check in=20
sqlgrey is that :

1/ SPF not having anything to do with greylisting, it isn't pure greylist=
ing=20
at all anymore.

2/ SPF being a complex algorithm, it necessitates a complex implementatio=
n in=20
SQLgrey, which is both heavy and bug-prone. And as the SPF standard might=
=20
evolve, it would need SQLgrey to follow its evolutions -- we're adding a =
lot=20
of foreseeable trouble there.
Furthermore there are other proposed standards competing with SPF, so if =
you=20
consider adding one, then you'll have to consider adding others, and this=
 is=20
endless.

3/ SPF cannot be done using only the information that Postfix provides to=
 the=20
SQLgrey policy server. SPF needs at least one, possibly several, DNS call=
s,=20
which will have a very noticeable negative impact on SQLgrey performance.=
 I=20
object to the idea that SQLgrey would need to perform any kind of network=
=20
request to be able to make a decision. One could say that DNS calls are f=
ast,=20
but it's not always the case. The remote DNS server you call can sometime=
s be=20
very slow, unreachable or unresponsive...

> The same is true for the rcpt_awl, we need for forwarded emails. We hav=
e a
> lot of employees, which separate their email addresses for business and
> private use. For their privat emails they use an address with a freemai=
l
> 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 oth=
er
> universities. When they moved, they set up a forward to an email addres=
s
> here.
>
> In both cases we want to accept such forwarded emails immediately witho=
ut
> 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 th=
e
> 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 email=
s
> coming this way will be accepted immediately. And this means greylistin=
g
> is strengthened again.

Regarding email forwarded from other universities, I believe the number o=
f=20
such universities isn't that high and doesn't grow that fast. You'd proba=
bly=20
be better adding the know MTAs of those universities to an existing manua=
l=20
whitelist, as you know those servers are true MTAs, well behaved.

Same could be done rather easily for the 4 or 5 major "free email provide=
rs=20
and forwarders" you're talking about. That makes what ? Hotmail, MSN, Yah=
oo,=20
a couple of biggest ISPs in your country, and you'd probably cover more t=
han=20
80% of your forwarding greylisting issues (if one believes the 80/20 law =
;-)

For the remaining 20%, it would concern mainly "private forwarded mail", =
and=20
in any case, the from_awl would take care that only the first mail from A=
 to=20
B thru "forwarder" would be greylisted. And if "forwarder" forwards a=20
noticeable amount of email from any given domain, it would end in domain_=
awl=20
for this domain anyway...

So I'm really not sure that your forwarding issue necessitates the added=20
complexity and performance cost that adding new tables to SQLgrey would=20
necessitate.

For example, rcpt_awl seems plain useless to me, as if you manually put a=
n=20
entry in rcpt_awl for a couple MTA_IP / recipient, then you mean that MTA=
_IP=20
is well behaved. If it's well behaved for "recipient", it's also well beh=
aved=20
for any other recipient, and MTA_IP can perfectly be added to the existin=
g=20
manual whitelists without the need of adding a supplementary table, isn't=
=20
it ?

Cheers.

--=20
Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E