Re: rereading header_checks file after file modified
On Fri, Apr 08, 2022 at 06:20:12AM +0200, Fourhundred Thecat wrote: > I have header_checks configured in master.cf: > > header-check unix n -n-0 >cleanup >-o header_checks=regexp:/var/local/postfix/maps/header_checks > > when I edit the header_checks file containing the regex rules, how do I > make postfix re-read the new changed file ? > > Do I have to restart postfix, or is there a way to do it without restart? If you're not in a hurry, do nothing. The cleanup process will be replaced after handling $max_use messages or being idle for $max_idle seconds. If you're in a hurry, a "postfix reload" is sufficient, no need to restart, which is needlessly disruptive. Note that this will also cause the queue manager to exit and be replaced, which causes all active message to move back into the incoming queue. So you don't want to reload frequently, especially on busy systems. -- Viktor.
rereading header_checks file after file modified
Hello, I have header_checks configured in master.cf: header-check unix n -n-0 cleanup -o header_checks=regexp:/var/local/postfix/maps/header_checks when I edit the header_checks file containing the regex rules, how do I make postfix re-read the new changed file ? Do I have to restart postfix, or is there a way to do it without restart?
Re: mailer-daemon sent by invalid host
On 2022-04-08 01:38, Alex wrote: Return-Path: <> X-Envelope-From: <> Received: from mail.nrtc.syn-alias.com (mail.nrtc.syn-alias.com [129.213.214.220]) Received: from [127.0.0.1] ([local]) by smtp03.nrtc.email-ash1.sync.lan (envelope-from <>) (ecelerity 4.3.1.69410 r(Core:4.3.1.0)) with INTERNAL id 6E/B8-17947-1D0FB426; Tue, 05 Apr 2022 03:33:37 -0400 From: Mail Delivery System To: u...@example.com Subject: Mail Delivery Failure Message-ID: <6e.b8.17947.1d0fb...@smtp03.nrtc.email-ash1.sync.lan> I've pasted the entire message here https://pastebin.com/zEkxMzuq How should I handle this? Ideas greatly appreciated. have you ensured not ACCEPT and BOUNCE is not what happend ? full postconf -nf if unsure
Re: Postfix + rspamd will not rewrite sender
> On 8 Apr 2022, at 1:48 am, Benny Pedersen wrote: > > On 2022-04-07 16:50, Matus UHLAR - fantomas wrote: >> On 07.04.22 09:16, Horst Simon wrote: > >>> In the main.cf I removed >>> content_filter = amavis:[127.0.0.1]:10024 >> this is not milter interface... > > an its removed :) > > more info is needed to help imho I am using sender_canonical to change address name@localdomain to name@ispdomain. It works perfect with amavisd-new, but when using rspamd it does not modify the sender address. I assume when using milter the sender_canonical_map is not used.
mailer-daemon sent by invalid host
Hi, I'm having trouble figuring out why this header check doesn't reject a mailer-daemon bounce email with ".lan" in the From address: /^From:.*\.lan>$/ REJECT Invalid domain It works if I use postmap directly, but not when the bounce message is received. Does it have something to do with it being a bounce message? $ postmap -q 'From: Mail Delivery System ' pcre:/etc/postfix-110/header_checks.pcre REJECT Invalid domain /etc/postfix-110/main.cf: header_checks = regexp:/etc/postfix-110/header_checks pcre:$config_directory/header_checks.pcre Apr 5 03:33:44 armor postfix-110/smtpd[1323082]: connect from mail.nrtc.syn-alias.com[129.213.214.220] Apr 5 03:33:45 armor policyd-spf[1323084]: prepend Received-SPF: None (no SPF record) identity=no SPF record; client-ip=129.213.214.220; helo=mail.nrtc.syn-alias.com; envelope-from=<>; receiver= Apr 5 03:33:45 armor postfix-110/smtpd[1323082]: 3EA5320055E46: client=mail.nrtc.syn-alias.com[129.213.214.220] Apr 5 03:33:45 armor postfix-110/cleanup[1323942]: 3EA5320055E46: message-id=<6e.b8.17947.1d0fb...@smtp03.nrtc.email-ash1.sync.lan> Apr 5 03:33:45 armor postfix-110/qmgr[1314349]: 3EA5320055E46: from=<>, size=4906, nrcpt=2 (queue active) The message is then quarantined by amavis because of the From address having ".lan". Return-Path: <> X-Envelope-From: <> Received: from mail.nrtc.syn-alias.com (mail.nrtc.syn-alias.com [129.213.214.220]) Received: from [127.0.0.1] ([local]) by smtp03.nrtc.email-ash1.sync.lan (envelope-from <>) (ecelerity 4.3.1.69410 r(Core:4.3.1.0)) with INTERNAL id 6E/B8-17947-1D0FB426; Tue, 05 Apr 2022 03:33:37 -0400 From: Mail Delivery System To: u...@example.com Subject: Mail Delivery Failure Message-ID: <6e.b8.17947.1d0fb...@smtp03.nrtc.email-ash1.sync.lan> I've pasted the entire message here https://pastebin.com/zEkxMzuq How should I handle this? Ideas greatly appreciated. Thanks, Alex
Re: About smtp_fallback_relay parameter
On 07/04/2022 17:55, Pedro David Marco wrote: Probably i am misunderstanding Postfix documentation but... What is exactly the Postfix criteria about using smtp_fallback_relay I also had an issue with this some time ago, which I didn't understand. At the time I had set the fallback relay as the smart-host of my ISP. Postfix offered a message to the (correct) direct destination and was grey-listed. Postfix immediately resent the message via the fallback relay. I felt that this behaviour mimicked some of the larger ISPs which resend messages using a different IP address every time, and which never got past the grey-list. I thought that this was "wrong" and - at the time - removed the fallback directive. What I *WANTED* was only to use the fallback if Postfix could not resolve a direct IP address. There are probably issues with this, too; if the address is unresolvable for me, it is likely to be unresolvable for my ISP also. What are the optimum settings for these circumstances? Thanks Allen C
Re: Postfix + rspamd will not rewrite sender
> On 8 Apr 2022, at 12:50 am, Matus UHLAR - fantomas wrote:
>
> On 07.04.22 09:16, Horst Simon wrote:
>> I used to have working correctly postfix + amavisd-new + dovecot working
>> correctly with re-writing the sender address when forwarding email to my ISP
>> using sender_canonical, I am using postfix 3.7.0.
>> After changing from amavisd-new to rspamd it will not rewrite the sender
>> address and forwarding to my ISP fails.
>
> did amavis change the sender when used as milter?
> i'm not sure milter supports changing sender…
Haven't used milter for amavisd-new only content_filter in main.cf and
following in master.cf
amavis unix - - - -2 lmtp
-o max_use=20
-o lmtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o lmtp_data_done_timeout=1200
>> In the main.cf I removed
>> content_filter = amavis:[127.0.0.1]:10024
>
> this is not milter interface...
>
>> and added
>> smtpd_milters = unix:/opt/local/var/run/rspamd/milter.sock
>> non_smtpd_milters = $smtpd_milters
>> milter_protocol = 6
>> milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
>> milter_rcpt_macros = i {rcpt_addr}
>> milter_default_action = accept
>>
>> Everything is working with rspamd except for the sender rewrite. Is there
>> anything else I need to change in the postfix configuration to get this
>> working again?
>
>
> --
> 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.
> "Two words: Windows survives." - Craig Mundie, Microsoft senior strategist
> "So does syphillis. Good thing we have penicillin." - Matthew Alton
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: About smtp_fallback_relay parameter
Understood! Thanks a lot Wietse and Viktor! Tete. On Thursday, April 7, 2022, 08:03:36 PM GMT+2, Wietse Venema wrote: Pedro David Marco: > Sorry, but i am confused... documentation is accurate, but probably > not my understading of it... Instead of arguing about what happens, look in your logs for the messages that end up in the deferred queue. In the implementation, Postfix appends the fallback relay(s) to the list of MX hosts for the recipient (the list can be empty). There is a safety check so that mail will not bounce when a fallback relay is not found. Wietse
Re: About smtp_fallback_relay parameter
Pedro David Marco: > Thanks Viktor, > i do not pretend to bother anybody to the extent of reviewing logs... i > justneed to understand smpt_fallback_relay a little bit more... thanks again > for your kindness.. > So... a soft fail in delivery is considered a "unreachable" destination, and > hence, smtp_fallback_relaytakes place...? ?my understanding was that > unreacahble meant "cannot connect to remote smtp port"... The text is based on a very early Postfix implementation. The text should be updated: smtp_fallback_relay is now used when (non-fallback) delivery fails with a 4xx status or when the (non-fallback) destination is not found. Wietse
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: About smtp_fallback_relay parameter
Thanks Viktor, i do not pretend to bother anybody to the extent of reviewing logs... i justneed to understand smpt_fallback_relay a little bit more... thanks again for your kindness.. So... a soft fail in delivery is considered a "unreachable" destination, and hence, smtp_fallback_relaytakes place... my understanding was that unreacahble meant "cannot connect to remote smtp port"... Thanks again! Pete. On Thursday, April 7, 2022, 07:52:43 PM GMT+2, Viktor Dukhovni wrote: On Thu, Apr 07, 2022 at 04:55:26PM +, Pedro David Marco wrote: > I have destinations not accepting email with a 451 return code. Some > of them are being sent by postfix to the smtp_fallback_relay and some > of them are just sent to the deferred queue... Probably i am > misunderstanding Postfix documentation but... What is exactly the > Postfix criteria about using smtp_fallback_relay When at least one envelope recipient soft fails for all attempted connections and/or SMTP sessions, then connections are attempted to any configured fallback relays (for such remaining envelope recipients). No detailed analysis is possible without logs. If you post all the relevant log entries (including relevant messages from the "smtp" processes with same "pid" as the final defer log entry) then it'll be possible to disect the sequence of events for a particular delivery attempt. You may find the "collate" script useful: https://github.com/vdukhovni/postfix/tree/master/postfix/auxiliary/collate -- Viktor.
Re: About smtp_fallback_relay parameter
Pedro David Marco: > Sorry, but i am confused... documentation is accurate, but probably > not my understading of it... Instead of arguing about what happens, look in your logs for the messages that end up in the deferred queue. In the implementation, Postfix appends the fallback relay(s) to the list of MX hosts for the recipient (the list can be empty). There is a safety check so that mail will not bounce when a fallback relay is not found. 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: About smtp_fallback_relay parameter
On Thu, Apr 07, 2022 at 04:55:26PM +, Pedro David Marco wrote: > I have destinations not accepting email with a 451 return code. Some > of them are being sent by postfix to the smtp_fallback_relay and some > of them are just sent to the deferred queue... Probably i am > misunderstanding Postfix documentation but... What is exactly the > Postfix criteria about using smtp_fallback_relay When at least one envelope recipient soft fails for all attempted connections and/or SMTP sessions, then connections are attempted to any configured fallback relays (for such remaining envelope recipients). No detailed analysis is possible without logs. If you post all the relevant log entries (including relevant messages from the "smtp" processes with same "pid" as the final defer log entry) then it'll be possible to disect the sequence of events for a particular delivery attempt. You may find the "collate" script useful: https://github.com/vdukhovni/postfix/tree/master/postfix/auxiliary/collate -- Viktor.
Re: About smtp_fallback_relay parameter
On Thursday, April 7, 2022, 07:23:14 PM GMT+2, Wietse Venema wrote:>>Pedro David Marco:>>> Hi,>> Postfix documentation about smtp_fallback_relay says: smtp_fallback_relay (default: $fallback_relay):>> Optional list of relay hosts for SMTP destinations that can't>> be found or that are unreachable. With Postfix 2.2 and earlier>> this parameter is called fallback_relay. I have destinations not accepting email with a 451 return code.>> Some of them are being sent by postfix to the smtp_fallback_relay>> and some of them are just sent to the deferred queue... Probably>> i am misunderstanding Postfix documentation but... What is exactly>> the Postfix criteria about using smtp_fallback_relay If the mail stays in the Postfix queue, then the smtp_fallback_relay>was not available, or it rejected the mail with a 4XX status, or>you restarted Postfix while it was delivering mail.>>You can see that with some logfile analysis.>> Wietse> Thanks Wietse, that is my understanding but no one restarted Postfix... smtp_fallback_relay only applies when destination is not found or unreachable. "Unreachable" meansthat Postfix cannot connect to the remote TCP port, am i right? A 4XY status means the destination "is reachable", so mail should always be deferred, is this correct? Sorry, but i am confused... documentation is accurate, but probably not my understading of it... Thanks, Pete.
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: About smtp_fallback_relay parameter
Pedro David Marco: > Hi, > Postfix documentation about smtp_fallback_relay says: > > smtp_fallback_relay (default: $fallback_relay): > Optional list of relay hosts for SMTP destinations that can't > be found or that are unreachable. With Postfix 2.2 and earlier > this parameter is called fallback_relay. > > I have destinations not accepting email with a 451 return code. > Some of them are being sent by postfix to the smtp_fallback_relay > and some of them are just sent to the deferred queue... Probably > i am misunderstanding Postfix documentation but... What is exactly > the Postfix criteria about using smtp_fallback_relay > If the mail stays in the Postfix queue, then the smtp_fallback_relay was not available, or it rejected the mail with a 4XX status, or you restarted Postfix while it was delivering mail. You can see that with some logfile analysis. Wietse
About smtp_fallback_relay parameter
Hi, Postfix documentation about smtp_fallback_relay says: smtp_fallback_relay (default: $fallback_relay): Optional list of relay hosts for SMTP destinations that can't be found or that are unreachable. With Postfix 2.2 and earlier this parameter is called fallback_relay. I have destinations not accepting email with a 451 return code. Some of them are being sent by postfix to the smtp_fallback_relay and some of them are just sent to the deferred queue... Probably i am misunderstanding Postfix documentation but... What is exactly the Postfix criteria about using smtp_fallback_relay Thanks! Pete.Hi,
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!
Re: Postfix + rspamd will not rewrite sender
On 2022-04-07 16:50, Matus UHLAR - fantomas wrote: On 07.04.22 09:16, Horst Simon wrote: In the main.cf I removed content_filter = amavis:[127.0.0.1]:10024 this is not milter interface... an its removed :) more info is needed to help imho
Re: Postfix + rspamd will not rewrite sender
On 07.04.22 09:16, Horst Simon wrote:
I used to have working correctly postfix + amavisd-new + dovecot working
correctly with re-writing the sender address when forwarding email to my
ISP using sender_canonical, I am using postfix 3.7.0.
After changing from amavisd-new to rspamd it will not rewrite the sender
address and forwarding to my ISP fails.
did amavis change the sender when used as milter?
i'm not sure milter supports changing sender...
In the main.cf I removed
content_filter = amavis:[127.0.0.1]:10024
this is not milter interface...
and added
smtpd_milters = unix:/opt/local/var/run/rspamd/milter.sock
non_smtpd_milters = $smtpd_milters
milter_protocol = 6
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
milter_rcpt_macros = i {rcpt_addr}
milter_default_action = accept
Everything is working with rspamd except for the sender rewrite. Is there
anything else I need to change in the postfix configuration to get this
working again?
--
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.
"Two words: Windows survives." - Craig Mundie, Microsoft senior strategist
"So does syphillis. Good thing we have penicillin." - Matthew Alton
Re: Mail is being delivered to /var/mail/*user* instead of Maildir
On Thu, Apr 07, 2022 at 08:20:54AM -0500, Rob McGee wrote: > > IIUC, you are telling me to change local to virtual, in order to use > > virtual_mailbox_maps, so vmailbox_result_format => Maildir. > > "vmailbox_result_format" is not a setting, where did you see this > documented? Actually, it is a valid component of an inline LDAP table definition. See ldap_table(5). Wietse has identified the problem, the OP is relying on virtual(8) delivery settings, but has configured "virtual_transport = local". -- Viktor.
Re: Merging accounts/home directories
>The best course of action is to bounce the messages with a >relocated_maps entry and force the sender to resend? "the best" is subjective. using relocated_maps http://www.postfix.org/relocated.5.html you make sure people will not receive mail to the old address, and any mail must be re-sent to new address to pass. On 07.04.22 08:32, Alex wrote: The plan was to migrate the existing username/passwords to the new n...@example.com format and have the users configure their mail client to login to receive their mail from the new address only. yes, this is how it needs to be done, if you want to migrate at all :-) The original recommendation involved setting the Reply-To address to be the new address, there's no point in this - this can only be used in the new e-mail, which will already be send from the new address, so the Reply-To: address would be the same as From: but I'm not sure of the point of that - is the expectation here that the user will login to both the new and old accounts? that's possible but it should be useless. Simply redirecting old address to new address at MTA level is easier than playing with multiple addresses, and multiple configurations in mail clients. If the recommendation is also to reject/bounce mail to the old address, when is someone ever going to see an email from the old address that they would need the reply-to info? you got it. someone may take this for unnecessary work for senders, which aren't responsible for recipient who wished to change their address. Perhaps "best practices" would have been better language, then. >How does using virtual_alias_maps affect my existing configuration if >I'm not currently using virtual domains or virtual maps? Currently the >server is processing mail for one domain listed in relay_domains. virtual_alias_maps is processed each time a mail is received, so you are able to alias any mail recipient, even those in remote domains: http://www.postfix.org/ADDRESS_REWRITING_README.html#virtual Okay, I'll experiment with that. later (e.g. in a year) you can convert those redirects in virtual_alias_maps to relocated. -- 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. The only substitute for good manners is fast reflexes.
Re: Best way forwarding to Gmail
On 2022-04-06 12:09, John Levine wrote: It appears that Byung-Hee HWANG said: There is good guidance for forwarding? If it is on Gmail, is best option. In my experience, forwarding to Gmail is an exercise in futility. I My view is that if you want to use gmail, hire them to host mail for your domain. If you want to host your own mail, use IMAP, or console-based MUAs on the mail server host. -- http://rob0.nodns4.us/
Re: Mail is being delivered to /var/mail/*user* instead of Maildir
On 2022-04-07 01:25, Tan Mientras wrote: On Wed, Apr 6, 2022 at 3:34 PM Wietse Venema wrote: You have configured *the other Postfix* system to deliver mail with virtual_transport = virtual (which is the default) That uses virtual_mailbox_maps to locate mailboxes/maildirs. But here, you have: virtual_transport = local This uses mail_spool_directory to locate mailboxes/maildirs. IIUC, you are telling me to change local to virtual, in order to use virtual_mailbox_maps, so vmailbox_result_format => Maildir. "vmailbox_result_format" is not a setting, where did you see this documented? IMO it's pretty much always a misconfiguration to mix up your address classes like this. http://www.postfix.org/ADDRESS_CLASS_README.html What drives me crazy is that this is actually working on Debian6. Is this a buggy behaviour in debian 6 which actually works ok? The bug is that you have yet to share any non-verbose logging that shows the issue. http://www.postfix.org/DEBUG_README.html#mail -- http://rob0.nodns4.us/
Re: Merging accounts/home directories
> >The best course of action is to bounce the messages with a > >relocated_maps entry and force the sender to resend? > > "the best" is subjective. using relocated_maps > http://www.postfix.org/relocated.5.html > you make sure people will not receive mail to the old address, and any mail > must be re-sent to new address to pass. The plan was to migrate the existing username/passwords to the new n...@example.com format and have the users configure their mail client to login to receive their mail from the new address only. The original recommendation involved setting the Reply-To address to be the new address, but I'm not sure of the point of that - is the expectation here that the user will login to both the new and old accounts? If the recommendation is also to reject/bounce mail to the old address, when is someone ever going to see an email from the old address that they would need the reply-to info? > someone may take this for unnecessary work for senders, which aren't > responsible for recipient who wished to change their address. Perhaps "best practices" would have been better language, then. > >How does using virtual_alias_maps affect my existing configuration if > >I'm not currently using virtual domains or virtual maps? Currently the > >server is processing mail for one domain listed in relay_domains. > > virtual_alias_maps is processed each time a mail is received, so you are > able to alias any mail recipient, even those in remote domains: > > http://www.postfix.org/ADDRESS_REWRITING_README.html#virtual Okay, I'll experiment with that.
Re: Merging accounts/home directories
[note: quoted content modified slightly; it was rejected for some reason previously] Not a lot. In as far as this pertains to postfix, just ch-ange the primary add-ress and add aliases for the old ones. The reply-to address should be set to the new address. See virtual_alias_maps and relocated_maps for details. On 06.04.22 19:14, Alex wrote: The best course of action is to bounce the messages with a relocated_maps entry and force the sender to resend? "the best" is subjective. using relocated_maps http://www.postfix.org/relocated.5.html you make sure people will not receive mail to the old address, and any mail must be re-sent to new address to pass. someone may take this for unnecessary work for senders, which aren't responsible for recipient who wished to change their address. How does using virtual_alias_maps affect my existing configuration if I'm not currently using virtual domains or virtual maps? Currently the server is processing mail for one domain listed in relay_domains. virtual_alias_maps is processed each time a mail is received, so you are able to alias any mail recipient, even those in remote domains: http://www.postfix.org/ADDRESS_REWRITING_README.html#virtual I believe the documentation of virtual_alias_maps http://www.postfix.org/postconf.5.html#virtual_alias_maps should be bit more clear about this. Op 6 apr. 2022 20:33 schreef Alex : We hae a set of users who wish to change their account names from name123@ to just name@ and I'm trying to determine the best way to manage that. The accounts are set up using actual password/shadow entries with check_client_access to recipient restrictions. Users retrieve mail using dovecot. I've been thinking one approach would be to create password/shadow entries for these new users and set their home directories to be the same as their old ones, then also add new entries to the check_client_access map. Does that make sense? -- 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. Linux is like a teepee: no Windows, no Gates and an apache inside...
Re: Mail is being delivered to /var/mail/*user* instead of Maildir
On Wed, Apr 6, 2022 at 3:34 PM Wietse Venema wrote: > You have configured *the other Postfix* system to deliver mail with > >virtual_transport = virtual (which is the default) > > That uses virtual_mailbox_maps to locate mailboxes/maildirs. > > But here, you have: > > virtual_transport = local > > This uses mail_spool_directory to locate mailboxes/maildirs. > > Wietse > IIUC, you are telling me to change local to virtual, in order to use virtual_mailbox_maps, so vmailbox_result_format => Maildir. What drives me crazy is that this is actually working on Debian6. Is this a buggy behaviour in debian 6 which actually works ok? Going to test virtual asap.
Re: Mail is being delivered to /var/mail/*user* instead of Maildir
On Wed, Apr 6, 2022 at 3:20 PM Matus UHLAR - fantomas wrote: > note that different behaviour can be caused by: > - destination domain in virtual_mailbox_domains > both equal - home_mailbox > not sent in config - mailbox_command > same command please, notice we're using the SAME configuration file for both environments(debian 6, older & working, vs ubuntu 20 newer and buggy)
