On Wed, 2009-07-01 at 12:00 +0200, Matus UHLAR - fantomas wrote:
> > On Wed, 2009-07-01 at 10:27 +0200, Matus UHLAR - fantomas wrote:
> >
> > > Note that rbl checks do not only control the IP you are receiving mail
> > > from,
> > > but also an IP others are receiving mail from. That means, rbl checks can
> > > help you catch spam others are (unintentionally) forwarding to you.
> > >
> > > I object against disabling RBL checks in SA ...
>
> On 01.07.09 09:40, rich...@buzzhost.co.uk wrote:
> > There is the forwarding argument - I agree, but it is not something that
> > affects us. I object to wasting resources and to have SA fire RBL query
> > roundtrips on every message it scans, when they have already been passed
> > by RBL checking at the SMTP level, seems like a pointless waste of time
> > and clock cycles.
>
> they often have not, since SA checks more headers than the last one.
> (and it may check more rbls than your MTA does at SMTP level).
>
> and the results from MTA checks should be cached already as it was mentioned
> already...
>
> > If sorbs bites the dust I'm sure as hell going to want to comment that
> > out someplace.
>
> - rbl_checks are more than just SORBS.
> - SORBS does not have any problems now and it should even not in the future
> (it may have outages but that's what mirrors are for, and sorbs does have
> mirrors)
>
> > I don't really want it sitting and waiting for an answer
> > from a non-operative list. Bless SA, it's great, but it's not the
> > quickest thing to run. Any unnecessary delay that can be removed
> > (provided the cost of doing so does not offset it) is a plus to me.
>
> well, skip network_checks at all. Note that they all (including rbls) are
> effective.
>
And there is the argument that anything other than the final IP can
easily be forged or inserted into the headers rendering a great many
costly DNS checks. Swings and roundabouts.
