Re: Fwd: [ANN]ounce of S-postgray v0.6.0
Steffen Nurpmeso wrote in <20220407211920.aedpm%stef...@sdaoden.eu>: |Wietse Venema wrote in | <4kz8dy5nbpzj...@spike.porcupine.org>: ||To my astonishment, Postfix does not send its own version in a ||policy server request. That should probably be fixed. | |diff --git a/README_FILES/SMTPD_POLICY_README b/README_FILES/SMTPD_POLIC\ (To my shame this was not even compile tested. I just thought i had to go ... But should work, i think.) --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)
Re: Fwd: [ANN]ounce of S-postgray v0.6.0
Wietse Venema wrote in
<4kz8dy5nbpzj...@spike.porcupine.org>:
|Steffen Nurpmeso:
|> The _only_ thing that must be taken into account, and i would wish
|> postfix would offer a solution for this, is that the *_error_limit
|> configuration parameters kick in. I have drastically low numbers
|> to reduce log noise for all these nonsense connections, but with
|> graylisting each DEFER_IF_PERMIT (or DEFER etc) counts as one
|> error. So if you have a message from a non-whitelisted sender
|> that ends up with two or three valid recipients on the host, it
|> counts as two or three errors.
|> So like s-postgray will impose limit-delay sleeps per RCPT TO:,
|> postfix will count errors per RCPT TO.
|> This is no good for graylisting, better would be a special
|> access(5) entry which simply "remembers an error once".
|
|Something like WARN_IF_REJECT (but with a different name and effect)
|that you can specify before REJECT, DEFER, etc. in an access map
|or policy server response?
You mean an action prefix? Why not, this sounds good.
(I meant "DEFER_IF_PERMIT_ERROR_ONCE" that only counts as one
error per instance=, even if it occurs multiple times.)
|To my astonishment, Postfix does not send its own version in a
|policy server request. That should probably be fixed.
diff --git a/README_FILES/SMTPD_POLICY_README b/README_FILES/SMTPD_POLICY_README
index 291fa5c870..5361412464 100644
--- a/README_FILES/SMTPD_POLICY_README
+++ b/README_FILES/SMTPD_POLICY_README
@@ -85,6 +85,8 @@ a delegated SMTPD access policy request:
PPoossttffiixx vveerrssiioonn 33..22 aanndd
llaatteerr::
server_address=10.3.2.1
server_port=54321
+PPoossttffiixx vveerrssiioonn 33..88 aanndd
llaatteerr::
+mail_version=3.8.0
[empty line]
Notes:
@@ -164,6 +166,8 @@ Notes:
* The "policy_context" attribute provides a way to pass information that is
not available via other attributes (Postfix version 3.1 and later).
+ * The "mail_version" attribute corresponds to the "postconf" parameter.
+
The following is specific to SMTPD delegated policy requests:
* Protocol names are ESMTP or SMTP.
diff --git a/src/global/mail_proto.h b/src/global/mail_proto.h
index b5504638e6..5081194617 100644
--- a/src/global/mail_proto.h
+++ b/src/global/mail_proto.h
@@ -201,6 +201,8 @@ extern char *mail_pathname(const char *, const char *);
#define MAIL_ATTR_CRYPTO_CIPHER"encryption_cipher"
#define MAIL_ATTR_CRYPTO_KEYSIZE "encryption_keysize"
+#define MAIL_ATTR_MAIL_VERSION "mail_version"
+
/*
* Suffixes for sender_name, sender_domain etc.
*/
diff --git a/src/smtpd/Makefile.in b/src/smtpd/Makefile.in
index 8c4132a30b..f48d38f026 100644
--- a/src/smtpd/Makefile.in
+++ b/src/smtpd/Makefile.in
@@ -340,6 +340,7 @@ smtpd_check.o: ../../include/mail_error.h
smtpd_check.o: ../../include/mail_params.h
smtpd_check.o: ../../include/mail_proto.h
smtpd_check.o: ../../include/mail_stream.h
+smtpd_check.o: ../../include/mail_version.h
smtpd_check.o: ../../include/map_search.h
smtpd_check.o: ../../include/maps.h
smtpd_check.o: ../../include/match_list.h
diff --git a/src/smtpd/smtpd_check.c b/src/smtpd/smtpd_check.c
index a4a6af0633..fea7e4852c 100644
--- a/src/smtpd/smtpd_check.c
+++ b/src/smtpd/smtpd_check.c
@@ -228,6 +228,7 @@
#include
#include
#include
+#include /* MAIL_VERSION_NUMBER */
#include
#include
#include
@@ -4099,9 +4100,11 @@ static int check_policy_service(SMTPD_STATE *state,
const char *server,
#endif
SEND_ATTR_STR(MAIL_ATTR_POL_CONTEXT,
policy_clnt->policy_context),
+ SEND_ATTR_STR(MAIL_ATTR_MAIL_VERSION,
MAIL_VERSION_NUMBER),
ATTR_TYPE_END,
ATTR_FLAG_MISSING,/* Reply attributes. */
RECV_ATTR_STR(MAIL_ATTR_ACTION, action),
ATTR_TYPE_END) != 1
|| (var_smtputf8_enable && valid_utf8_action(server, STR(action)) ==
0)) {
NOCLOBBER static int nesting_level = 0;
--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)
Re: Fwd: [ANN]ounce of S-postgray v0.6.0
Steffen Nurpmeso: > The _only_ thing that must be taken into account, and i would wish > postfix would offer a solution for this, is that the *_error_limit > configuration parameters kick in. I have drastically low numbers > to reduce log noise for all these nonsense connections, but with > graylisting each DEFER_IF_PERMIT (or DEFER etc) counts as one > error. So if you have a message from a non-whitelisted sender > that ends up with two or three valid recipients on the host, it > counts as two or three errors. > So like s-postgray will impose limit-delay sleeps per RCPT TO:, > postfix will count errors per RCPT TO. > This is no good for graylisting, better would be a special > access(5) entry which simply "remembers an error once". Something like WARN_IF_REJECT (but with a different name and effect) that you can specify before REJECT, DEFER, etc. in an access map or policy server response? To my astonishment, Postfix does not send its own version in a policy server request. That should probably be fixed. Wietse
Re: Fwd: [ANN]ounce of S-postgray v0.6.0
Steffen Nurpmeso wrote in <20220407172531.ty1l8%stef...@sdaoden.eu>: ... |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.) (..And the limit-delay will possibly be changed to sleep per "instance" aka message, not RCPT TO.) To answer your question, i do not think that postscreen(8) does that. The graylist DB will recognize specific sender/receiver etc combinations up to 22 days. I .. do not use postscreen. I would anyhow recommend DNS related tests before the policy server placement in smtpd_recipient_restrictions, as shown in the manual. Graylisting is only a very simple mechanism that steps in at the early stages of SMTP communication (but after TLS setup, if any), and can thus reduce the cost of spam bots by not allowing them to continue unless they show up a second or third time after a delay (sites are known which Graylist for hours, so delay can also be painful), which seems to be not true for many easy bots. (It is, however, plain that a lot of spam comes from real MTAs, and the majority of my spam comes via GMail -- and that is whitelisted here like most other big sites, because not doing so only increases network traffic for nothing, as they all act properly.) The nice thing about s-postgray in particular is that it is self-contained on a POSIX/Linux standard system. Is is only a C program, and i run it in less than a megabytes of memory with 0.00 CPU time after a week of operation. The _only_ thing that must be taken into account, and i would wish postfix would offer a solution for this, is that the *_error_limit configuration parameters kick in. I have drastically low numbers to reduce log noise for all these nonsense connections, but with graylisting each DEFER_IF_PERMIT (or DEFER etc) counts as one error. So if you have a message from a non-whitelisted sender that ends up with two or three valid recipients on the host, it counts as two or three errors. So like s-postgray will impose limit-delay sleeps per RCPT TO:, postfix will count errors per RCPT TO. This is no good for graylisting, better would be a special access(5) entry which simply "remembers an error once". 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)
Re: Fwd: [ANN]ounce of S-postgray v0.6.0
Hello. Matus UHLAR - fantomas wrote in : |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 || textdata bss dec hex filename ||696801344 80 71104 115c0 /usr/lib/liblmdb.so || #?0[steffen@essex nail.git]$ size /usr/lib/libdb.so || textdata 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)
Re: Fwd: [ANN]ounce of S-postgray v0.6.0
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? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 2B|!2B, that's a question!
Fwd: [ANN]ounce of S-postgray v0.6.0
Hello. 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). Thanks, and ciao already here, --- Forwarded from Steffen Nurpmeso --- [.] Announcing the first release of S-postgray, a postfix[1] RFC 6647 graylisting policy server that aims in being fast and secure. The manual should provide detailed information, it can also be read online at [2]. I think this program is mature, and i do not expect a lot of changes in the future. It could be adjusted to run with other SMTP servers (Exim[3] should work already if it is configured to speak the postfix policy protocol, but has not been tested). What should definitely change is the build system, it is intermediate because of the SU tools used, those are part of the S-nail MUA and so need to be "baked in". Therefore: Either it builds, then it should run. Or not. :-) I have tested it on GNU and musl Linux, and on all BSDs. (Solaris needs some build system work, but should do, too.) To build this software simply run "make install". At the top of the makefile there are some variables, they can be overwritten from the command line: $ make DESTDIR=.xxx PREFIX=/usr LIBEXEC=sbin \ VAL_STORE_PATH=/var/lib/postfix \ install This will build and install the binary under [.xxx]/usr/sbin, and the default built-in path for database storage and the client/server communication socket will be /var/lib/postfix. There is a unit test ./s-postgray-test.sh (see README). The files to download are https://ftp.sdaoden.eu/s-postgray-0.6.0.tar.gz https://ftp.sdaoden.eu/s-postgray-0.6.0.tar.gz.asc They also exist in a XY-latest.* version, and are signed with my OpenPGP key available on some OpenPGP key servers, my website (also WKD), and my download area (ftp.sdaoden.eu/steffen.asc). stef...@sdaoden.eu / 1883A0DD (EE19 E1C1 F2F7 054F 8D39 54D8 3089 64B5 1883 A0DD) [1] https://www.postfix.org [2] https://www.sdaoden.eu/code-postgray.html [3] http://www.exim.org Have fun! Ciao from Germany, [.] -- End forward <20220331194300.av18f%stef...@sdaoden.eu> --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)
