sqlgrey-users

[Sqlgrey-users] SQLgrey 1.8.0-rc1

[Michal L. <ml...@lo...>]

Hi all,

While setting up a new mail server today and realised that the most 
recent SQLgrey has only ever existed in GIT and was never released as a 
package. We also agreed some time ago that it's time for a new stable 
release.

Ladies and Gentlemen ... here comes... SQLgrey 1.8.0-rc1 !

The main update from 1.7.6 is a completely reworked IPv6 handling - now 
it should actually work as good as IPv4, including whitelists, etc.

For now it's an RC (release candidate) but I'm not aware of any 
problems, it should be as production ready as 1.7.6.

Download from SourceForge:
http://downloads.sourceforge.net/project/sqlgrey/sqlgrey-1.8%20%28stable%29/sqlgrey-1.8.0-rc1.tar.gz

Michal

Re: [Sqlgrey-users] SQLgrey 1.8.0-rc1

[Kyle L. <la...@uc...>]

Michal Ludvig wrote:
> While setting up a new mail server today and realised that the most 
> recent SQLgrey has only ever existed in GIT and was never released as a 
> package. We also agreed some time ago that it's time for a new stable 
> release.

What about including some of the modifications posted here:

	http://article.gmane.org/gmane.mail.postfix.sqlgrey/1033

...in particular, the bits relating to logging? Those strike me as
cross-platform improvements, and are 100% required to get sqlgrey
functioning on Solaris.

Are the bits related to SPF functionality desirable? That sounds
like a keen feature, even if I'm not a fan of how the dependency
list grows exponentially when you require Mail::SPF::Query.

There are a lot of other small things I'm working against to get
sqlgrey working on Solaris, and after working through enough of
them, it's starting to get frustrating. It would be nice if these
problems were solved with a basic autoconf setup, but it's not the
same class of show-stopper. In particular, it would be nice if
further GNU-isms are not assumed (for example, invoking sed -i in
the Makefile) without some method of first asserting whether the
local system supports such an option.

I've attached a patch to sqlgrey that contains the modifcations to
the previously-posted logging behavior against the 1.8.0-rc1 release.

--Kyle

Re: [Sqlgrey-users] SQLgrey 1.8.0-rc1

[Michal L. <ml...@lo...>]

Hi Kyle,

On 01/23/2010 08:44 AM, Kyle Lanclos wrote:
> What about including some of the modifications posted here:
> 
> 	http://article.gmane.org/gmane.mail.postfix.sqlgrey/1033

I wasn't aware of these...

> ...in particular, the bits relating to logging? Those strike me as
> cross-platform improvements, and are 100% required to get sqlgrey
> functioning on Solaris.

Is this compatible with other Unix/Linux brands?

> Are the bits related to SPF functionality desirable? That sounds
> like a keen feature, even if I'm not a fan of how the dependency
> list grows exponentially when you require Mail::SPF::Query.

I'm sure SPF awareness would be nice to have. Ideally make it an
optional feature with an optional dependency. Have a look at my smtp-cli
script (http://smtp-cli.logix.cz) that has an optional mode for
composing messages from the command line arguments. If the required
modules are not found the feature is not available:

## MIME::Lite dependency is optional
my $mime_lite = eval { require MIME::Lite; 1; };
if (not $mime_lite) {
        warn("!!! MIME::Lite -- optional module not found\n");
}

Later on in the script it checks for $mime_lite before going down the
path where the module is needed.

> There are a lot of other small things I'm working against to get
> sqlgrey working on Solaris, and after working through enough of
> them, it's starting to get frustrating. It would be nice if these
> problems were solved with a basic autoconf setup, but it's not the
> same class of show-stopper.

I'm keen to accept patches that fix your problems, provided they won't
break sqlgrey for non-Solaris users.

> In particular, it would be nice if
> further GNU-isms are not assumed (for example, invoking sed -i in
> the Makefile) 

Oops, my bad. Will fix that.

> I've attached a patch to sqlgrey that contains the modifcations to
> the previously-posted logging behavior against the 1.8.0-rc1 release.

Thanks. I will have a look at it.

Michal

Re: [Sqlgrey-users] SQLgrey 1.8.0-rc1

[Lionel B. <lio...@bo...>]

Michal Ludvig a écrit, le 01/28/2010 04:55 AM :
> [...]
> I'm sure SPF awareness would be nice to have.

SPF support is a recurrent topic. I'm surprised it comes again and
again. There are 2 reasons why I don't think including it is a good thing :
- I'm not sure there are efficient SPAM-fighting behaviours we can
implement based on SPF records that wouldn't be possible by configuring
Postfix with a separate SPF policy service,
- SQLgrey treats incoming mails sequentially. It can do so because it
only uses very-low latency queries, querying SPF records is orders of
magnitude slower. For people with more than a few mails/minute,
SQLgrey+SPF will become a bottleneck.

Lionel

Re: [Sqlgrey-users] SQLgrey 1.8.0-rc1

[Winfried N. <win...@ne...>]

Hi,

> I'm sure SPF awareness would be nice to have.
> [...]
>> SPF support is a recurrent topic. I'm surprised it comes again and
>> again. There are 2 reasons why I don't think including it is a good
thing:
>> [...]
>>
I totally agree with Lionel. Things such as SPF should not be included
into SQLgrey. SQLgrey is a greylisting daemon and following the KISS
principles it shouldn't do anything else than this.

Besides of this, if we wanna provide SPF support, we also need to make
sure that SRS is supported as well. As SPF "breaks" the email
forwarding,
this might be a big issue for some SQLgrey users. Also there are some
studies on the net, that the only users which really rely on SPF are
SPAMers.


Winni

Re: [Sqlgrey-users] SQLgrey 1.8.0-rc1

[Karl O. P. <ko...@me...>]

On 01/31/2010 08:31:25 AM, Lionel Bouton wrote:
> Michal Ludvig a écrit, le 01/28/2010 04:55 AM :
> > [...]
> > I'm sure SPF awareness would be nice to have.
> 
> SPF support is a recurrent topic. I'm surprised it comes again and
> again. There are 2 reasons why I don't think including it is a good
> thing :

And what role would it play in greylisting?   (Which is the
only thing sqlgrey should be doing.)  I can't see the presence
or absence of an SPF record being anything I'd want to
trigger turning greylisting on or off.


Karl <ko...@me...>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Re: [Sqlgrey-users] SQLgrey 1.8.0-rc1

[Kyle L. <la...@uc...>]

Karl Pinc wrote:
> And what role would [SPF records] play in greylisting?

Where it would be helpful is in identifying diverse ranges of IP addresses
that may represent a valid source for a given e-mail address, in the case
of MTAs that do not re-send messages from the same IP address.

I'm thinking of gmail when I say that.

I agree wholeheartedly, with the notion that synchronous DNS lookups are
likely too expensive to include as part of SQLgrey, or other similar
greylisting implementations.

It would be cleaner to have some kind of out-of-band, asynchronous mechanism
(a cronjob) that would assert that a range of addresses represents, for the
purposes of greylisting, a single source; currently, the out-of-band mechanism
only allows for whitelisting. I think that using SPF records in this fashion
would be preferable, in principle, to arbitrarily whitelisting.

The trouble would be: how do you programmatically deterine which SPF records
to query? Perhaps the asynchronous job could query the database for likely
candidates, and similarly maintain a database of results. Only update records
once a day for existing entries, that kind of thing.

I'm thinking it would be a significant amount of work for a relatively modest
return.

--Kyle