[Sqlgrey-users] SQLgrey 1.8.0-rc1

[Michal Ludvig]

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

[Kyle Lanclos]

Post by Michal Ludvig
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

[Michal Ludvig]

Hi Kyle,

Post by Kyle Lanclos
http://article.gmane.org/gmane.mail.postfix.sqlgrey/1033

I wasn't aware of these...

Post by Kyle Lanclos
...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?

Post by Kyle Lanclos
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.

Post by Kyle Lanclos
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.

Post by Kyle Lanclos
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.

Post by Kyle Lanclos
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

[Lionel Bouton]

Post by Michal Ludvig
[...]
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

[danmail]

Regarding SPF.

Post by Lionel Bouton
- SQLgrey treats incoming mails sequentially. It can do so because it

This is a very good point.
Since sqlgrey uses multiplexing, not multi-threading, everything that
happens from the first data is read from postfix, until sqlgrey has
replied "yay" or "nay", will delay the processing of all other mail.

Since SPF is using DNS and since most SPF records you will look up will
be external (recursive), you not only have the lag of your local
nameserver, but are also affected on how fast the authoritative
nameserver (the external one) answers.

If i take some domainnames and point them to a firewalled host as name
server, it can take up to 5 seconds per lookup to fail (or timeout).
(linux default DNS timeout is 5 seconds).

Based on that, it should be fairly easy for an attacker to effectivly
shut down your mailservice, just by continuously sending mails from
domains which have slow, or even dead name servers.
Even if you lowered the DNS timeout to 1 second, all an attacker would
have to do to keep you down, is 1 connect per second.


- Dan
--
http://blog.hacker.dk/

[Karl O. Pinc]

Post by Lionel Bouton

Post by Michal Ludvig
[...]
I'm sure SPF awareness would be nice to have.

SPF support is a recurrent topic. I'm surprised it comes again and

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 <***@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

[Kyle Lanclos]

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

[Winfried Neessen]

Hi,

Post by Michal Ludvig
I'm sure SPF awareness would be nice to have.
[...]

Post by Lionel Bouton
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
[...]

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