Hello.

Matus UHLAR - fantomas wrote in
 <yk8l8v1ijsrjo...@fantomas.sk>:
 |On 31.03.22 22:12, Steffen Nurpmeso wrote:
 |>I hope it is ok to forward this.
 |>I have developed and released a postfix protocol graylisting
 |>server that possibly could interest some people on this list.
 |>I have the hope it proves worth its MTA :-)
 |>
 |>The online manual ([2] below) should be enough (so note groff HTML
 |>conversion is bad; the ball is ~127KB, the optimized binary
 |>package is 44KB on a GNU libc Linux system).
 |
 |fyi, does this provide any functionality better than e.g. postscreen?

The next release (whenever it happens) will have the additional
manual sentence

  Graylisting defers message acceptance a configurable number of
  times via a standardized SMTP response (see RFC 5321,
  access(5)), which does not prevent message delivery from SMTP
  M(ail) T(ransfer) A(gent)s, but can help against simple spam
  producing programs.

(And --test-mode will simply output a valid resource file again.)

Graylisting is an old (~20 years) method which seem to have
originated on this list (and is standardized since ~10), and
stable programs exist for long which implement this "logic".  
My initial intent was not to create a new graylisting
implementation, but it came up in a different context.  However,
doing the other thing requires the same "infrastructure", it just
adds another code path "on top".  Wait, this is what i have
written on another list, quoting myself, and one sentence of
John Levine, who also seems to be on this list (i hope it is ok to
quote that one, too), eh, i strip it a bit:

 ||Everyone I know who does greylisting with Postfix uses Postgrey,
 ||available here:
 ||
 ||https://postgrey.schweikert.ch/
 ||
 ||Are you sure you need to reinvent this particular wheel?
 |
 ....
 |So that postgrey uses perl would be ok even though it uses quite
 |a bit of modules.  It uses BerkeleyDB, which is no longer free
 |software, version 5.3.28 is, aka
 |  Berkeley DB 11g Release 2, library version 11.2.5.3.28:
 |  (September 9, 2013)
 |as via [1], which is quite old.  But ok.  It however seems to use
 |what i call "[Chris ]Torek Hash", which faded a bit to grey when
 |facing possible real world attacks me thinks.  It is also very big
 |and slow, and imposes expensive locking.
 |
 |  [1] http://www.oracle.com/technetwork/database/database-technologies/ber\
 |  keleydb/
 |
 |As an effort to restrict all my (easy non-SQL, and only those here
 |right now) DB use cases to only LMDB of the OpenLDAP project for
 |example i wrote an accepted patch for bogofilter(1) in 2018, and
 |by then these were the numbers
 |
 |||> it is very small (the raw AlpineLinux code package is 90KB,
 |||> whereas DB is 1.6MB; the cloned repo is 1.2MB, whereas the 5.3.28
 |||> DB tar ball unpacked in git is 31MB), and the code is also open
 |||> and openly maintained.  And Postfix supports LMDB as a replacement
 |||> for DB out of the box, too.  All this is very desirable to me.
 ...
 ||Runtime is much smaller here, too:
 ||
 ||  #?0[steffen@essex nail.git]$ size /usr/lib/liblmdb.so
 ||     text    data     bss     dec     hex filename
 ||    69680    1344      80   71104   115c0 /usr/lib/liblmdb.so
 ||  #?0[steffen@essex nail.git]$ size /usr/lib/libdb.so
 ||     text    data     bss     dec     hex filename
 ||  1549515   38744      64 1588323  183c63 /usr/lib/libdb.so
 |
 |(It does not support VACUUM or any such, therefore i dump-out and
 |recreate these DBs in such heavy use cases once a month
 |.. automatically.)  Very, very fast and minimal overhead.
 |
 |But in fact all this is part of an effort to replace the
 |end-of-life Python2 Mailman2 with something homegrown.
 |I initially planned to use the policy server to whitelist
 |subscribers fast, for example.  That it also should do regular
 |greylisting was not the first use case.  However, in the meantime
 |i added regular use cases for a postfix configuration
 |
 |   check_sender_access lmdb:/etc/postfix-lmdb/sender_access,
 |
 |before the envisioned check_policy_service, which made this less
 |desirable, because LMDB uses fast read/write locks (or what i do
 |not like, "robust" mutexes) if available, and then even very fast
 |unix(7) communication will likely be outperformed.
 |However, maybe that will be replaced by whitelist on the policy
 |server side (again).
 |It will use SipHash for its all-in-memory dictionaries.

Ciao,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Reply via email to