[pfx] Re: Recommendation for dkim signing
On Mon, 30 Oct 2023, Jens Hoffrichter via Postfix-users wrote: We are looking into implementing DKIM signing for one of our services, and there are multiple ways to implement that. So far I have found that you can do it with opendkim and amavis - any recommendation for one or the other, or maybe something completely different I haven't found yet? I can recommend rspamd. It does (among others) DKIM signing and verifying, and works pretty much out of the box. Cheers, Bernardo ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: server does not pick up new certificates
On Mon, 24 Jul 2023, Wietse Venema via Postfix-users wrote: Bernardo Reino via Postfix-users: On Sun, 23 Jul 2023, Viktor Dukhovni via Postfix-users wrote: On 23 Jul 2023, at 4:21 pm, Charles Sprickman via Postfix-users wrote: In the case of the dehydrated ACME client (https://github.com/dehydrated-io/dehydrated) there's an option to run a bunch of commands on successful update, including something like "postfix reload" - one could also insert an email or other command to note the update. I can't imagine other ACME clients don't offer a similar function... The "certbot" ACME client offers post-hooks, but they're not "reliable". If the hook fails or doesn't run, it won't be retried. A robust "post-hook" should have "at least once" semantics, its implementation should be idempotent, ait and should be retried until it succeeds. I cannot imagine why/when the cerbot client would fail to run the post-hooks (in a sane environment). Systems crash. What are the reliability guarantees from the certbot client: will it run once, or will it somehow maintain state and recover when a run was interrupted by a system crash? In such cases, and/or just "on top" of the certbot renewal hooks, one could have a cron job doing "postmap" and/or "postfix reload" or whatever, as Viktor wrote. (but again, then your cron job must make sure that certbot is not (con)currently running). I honestly don't think that it's certbot's [*] job to do that. The hooks are IMHO a "courtesy", which is nice to have, but if you need 100% reliability, you need to implement it using another method. -- Bernardo ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: server does not pick up new certificates
On Sun, 23 Jul 2023, Viktor Dukhovni via Postfix-users wrote: On 23 Jul 2023, at 4:21 pm, Charles Sprickman via Postfix-users wrote: In the case of the dehydrated ACME client (https://github.com/dehydrated-io/dehydrated) there's an option to run a bunch of commands on successful update, including something like "postfix reload" - one could also insert an email or other command to note the update. I can't imagine other ACME clients don't offer a similar function... The "certbot" ACME client offers post-hooks, but they're not "reliable". If the hook fails or doesn't run, it won't be retried. A robust "post-hook" should have "at least once" semantics, its implementation should be idempotent, ait and should be retried until it succeeds. I cannot imagine why/when the cerbot client would fail to run the post-hooks (in a sane environment). They run reliably (in my case, using /etc/letsencrypt/renewal-hooks/deploy/), and as long as the certbot client itself doesn't crash (or is killed, etc.) I cannot imagine why it would fail. Another matter is the actual post-hook script. As long as it's a generic shell script or such, the program running it (certbot) cannot make any guarantees as to e.g. idempotency. IMHO it's advisable to do as much error checking in the post-hook script itself, rather than relying on certbot for that. Are you aware of cases where certbot actually failed to (attempt to) run the hooks? Thanks. -- Bernardo ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: delivery loop?
On Mon, 22 May 2023, Tom Reed via Postfix-users wrote: Given the case that: 1. postfix is a backup MX for foo.com 2. this postfix uses other MTA as relay_host When the primary MX for foo.com is down, messages to u...@foo.com will be delivered into backup MX. And, backup MX delivers the message to relay_host, which find that primary MX can't be reachable, so relay_host deliver message to backup MX again. I think the idea is that the MX for a given domain is expected to accept the mail, rather than relay it somewhere else. (Otherwise the other host should be the MX). But obviously, if your "other MTA" decides to send the mail to your "backup MX" then I'd say you can have a loop. Will this delivery loop happen in real world? My world is only a very small subset of the real world :), but in that world, if I say that a given server is the MX for a domain, then that's that, it should not relay further. Maybe others with more experience and/or a wider world can provide better info. Cheers. PS: Why do you (think you) need a backup MX? ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: E-mail delivery problem
On Tue, 2 May 2023, Victoriano Giralt via Postfix-users wrote: [very good information and advice] Just show/check the output of "ip a" if you are on Linux, please, you will be surprised. Maybe also add "ip r", as this would clarify whether the default route is the VPN or not (and apparently, it isn't). Cheers. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Painful Postfix
On Mon, 1 May 2023, Kolusion K via Postfix-users wrote: When I open a raw socket to the remote server on port 25 using telnet, I am able to connect and see the server announce itself, so, it is reasonable to assume that Postfix is doing the same and timing out during the SMTP transaction because Postfix is not having a problem sending mail to other servers. I don't think you even know what a raw socket is. You seem to imply that doing "telnet 25" is "opening a raw socket", which only makes your statement of the problem more unclear. I think it has been made abundantly clear that postfix is not at fault here, but whatever (intricate and/or erroneous) networking setup you have. A reasonable person does not assume their software is always telling the truth. The postfix log is telling you the truth. A reasonable person reads the logs and acts accordingly. Your problem is with your networking, so look at the relevant logs and/or check the incoming/outgoing packets (Viktor and others have already and repeatedly stated that tcpdump would allow you to identify the problem). Good luck. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: tls_high_cipherlist parameter
On Mon, 1 May 2023, Kolusion K via Postfix-users wrote: Hello Postfix's documentation for the tls_high_cipherlist parameter states to see the output of the command 'postconf -d' to see the default setting. Sadly, the documentation lacks specificness, and the output spit out about 500 lines, so I am not sure what I am suppose to be looking at. postconf -d will print all the (default) settings, you can use grep to filter the specific line you're looking for. I found the parameter mentioned on one of the lines. I was expecting to see a list of ciphers, such as AES-256 ectetera, but I don't see any mention of a type of cipher, so I'm not sure if looking at the line for the tls_high_cipherlist parameter is what I am suppose to be looking at. postfix uses openssl, and if you had read the manual you would have seen something like: * tls_high_cipherlist (default: see "postconf -d" output) The OpenSSL cipherlist for "high" grade ciphers. [...] so you should then look at your openssl configuration (which may or may not be whatever default your distribution is using). $ man 1 ciphers will take you further. Could anyone confirm if that is what I am suppose to be looking at and if I am correct in what I was expecting? Only you can know what you were expecting, and hence what you are supposed to be looking at. Good luck.___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: postscreen question
On Sat, 29 Apr 2023, Ken Peng via Postfix-users wrote: Nope. I found that if I enabled protocol test, every provider including gmail/orange/vodafone sending messages to me will get response code 450. After I disabled those protocol test, everything goes fine. So what's the correct way to deal with postscreen protocol tests? The correct way is to read the documentation before enabling the deep protocol tests, especially concerning the limitation that postscreen cannot hand off the live connection to the postfix server process. I mean the following stuff. postscreen_pipelining_enable = yes postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = yes postscreen_non_smtp_command_action = enforce postscreen_bare_newline_enable = yes postscreen_bare_newline_action = enforce Yes, go and read the POSTSCREEN_README.txt again :) Cheers. (bottom-posted part left for context). Apr 29 15:35:35 mxin postfix/postscreen[59408]: NOQUEUE: reject: RCPT from [209.85.160.53]:50219: 450 4.3.2 Service currently unavailable; from=, to=, proto=ESMTP, helo= And this is my configuration for postscreen: # postscreen postscreen_access_list = permit_mynetworks cidr:/etc/postfix/postscreen_access.cidr postscreen_blacklist_action = drop postscreen_greet_action = enforce postscreen_dnsbl_threshold = 2 postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = zen.spamhaus.org*2 postscreen_dnsbl_whitelist_threshold = -2 # postscreen protocol test postscreen_pipelining_enable = yes postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = yes postscreen_non_smtp_command_action = enforce postscreen_bare_newline_enable = yes postscreen_bare_newline_action = enforce There doesn't seem to be anything specific to gmail, so if you enable greylisting, it will apply to everyone. Cheers. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: postscreen question
On Sat, 29 Apr 2023, Ken Peng via Postfix-users wrote: Hello When I enabled postscreen, why even gmail's sender IP was greylisted? Did you expect or configure to deal with gmail differently? The log says: Apr 29 15:35:35 mxin postfix/postscreen[59408]: NOQUEUE: reject: RCPT from [209.85.160.53]:50219: 450 4.3.2 Service currently unavailable; from=, to=, proto=ESMTP, helo= And this is my configuration for postscreen: # postscreen postscreen_access_list = permit_mynetworks cidr:/etc/postfix/postscreen_access.cidr postscreen_blacklist_action = drop postscreen_greet_action = enforce postscreen_dnsbl_threshold = 2 postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = zen.spamhaus.org*2 postscreen_dnsbl_whitelist_threshold = -2 # postscreen protocol test postscreen_pipelining_enable = yes postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = yes postscreen_non_smtp_command_action = enforce postscreen_bare_newline_enable = yes postscreen_bare_newline_action = enforce There doesn't seem to be anything specific to gmail, so if you enable greylisting, it will apply to everyone. Cheers. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DNS resolvers difference for RBL checks
On Mon, 10 Apr 2023, tom--- via Postfix-users wrote: I have two debian boxes, one is running unbound for dns resolver, another is running systemd-resolve. [..] Checking for RBL on first node is successful: [..] But second is not: [..] Can you tell me why? unbound will, per default, resolve recursively, rather than forwarding the request to another resolver. systemd-resolve is not a recursive resolver (AFAIK anyway). Spamhaus blocks requests received from public resolvers (1.1.1.1, 8.8.8.8, etc.), which is one of the reasons for preferring/requiring a real/recursive resolver in a server, as Viktor has written already -- and please read, and re-read, everything he ever writes or has ever written in this list, as each message is a gem in itself :) Cheers. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Allow TLSv1 only for internal senders
On Thu, 23 Mar 2023, Steffen Nurpmeso via Postfix-users wrote:
[...]
(That is pretty off-topic for postfix; except maybe for fun
posting my SMTP related firewall
[...]
add_rule -p tcp --src ${addr}${mask} \
--dport ${p_smtp} -m limit --limit 60/m -j f_m0_2
[...]
Could it be that $mask is set to something like /24 (or worse), and that
somebody in the (ip) neighborhood of Jaroslaw is triggering your script?
(I apologize for replying to this off-topic topic).
Cheers,
Bernardo
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[P-U] Re: Postfix lists are migrating to a new list server
On Wed, 8 Mar 2023, Phil Stracchino via Postfix-users wrote:
On 3/7/23 15:36, Bernardo Reino via Postfix-users wrote:
On Tue, 7 Mar 2023, John Stoffel via Postfix-users wrote:
So what's the option for a more upto date version of DKIM milter for
debian?
rspamd does DKIM, SPF, DMARC and ARC (and lots more), and doesn't segfault
(so
far ;-)
I'm STILL trying to figure out rspamd's documentation enough to understand
how to enable and configure all of those, so that I can have one milter
instead of four.
Here some quick notes from my configuration (related to SPF/DKIM/DMARC checking,
i.e. when receiving e-mails):
SPF and DKIM are enabled by default, and at least I didn't need to have any
local config (which would go in local.d/{spf,dkim}.conf)
(DKIM signing is another matter, requiring configuration, but this is another
topic)
DMARC is also enabled by default, and I have the following in
local.d/dmarc.conf, to "add_header" instead of "reject" even when DMARC would
say otherwise. I also have enabled DMARC reporting, including a list of domains
to which no report should be sent (e.g. because they reject e-mails to the very
address they publish for this purpose..)
***
actions = {
quarantine = "add_header";
# reject = "reject";
reject = "add_header";
}
reporting {
enabled = true;
org_name = "BBMK";
domain = "bbmk.org";
email = "rep...@dmarc.bbmk.org";
from_name = "Rspamd"
max_entries = 1000; # per domain
keys_expire = 7d; # expire date for redis
# bcc_addrs = [ "postmas...@bbmk.org" ];
}
no_reporting_domains = "/etc/rspamd/local.d/dmarc_no_reporting_domains.txt";
***
(obviously, org_name, domain, email and from_name should be adapted
accordingly..)
I don't know if this is part of the default, but over time I've ended up having
the following in local.d/milter_headers.conf (replace "BBMK" with whatever
(host)name you want to appear in the X-Rspamd-Server header, or enable "remove =
true" to avoid this header)
***
extended_spam_headers = true;
authenticated_headers = ["authentication-results"];
local_headers = ["authentication-results"];
use = ["authentication-results"];
remove_upstream_spam_flag = true;
skip_local = false;
skip_authenticated = false;
routines {
x-rspamd-server {
header = "X-Rspamd-Server";
# remove = true;
hostname = "BBMK";
}
}
***
That's it for now. The documentation may be confusing (and some things changed
in the past, but I think nowadays the documentation and actual configuration are
rather stable).
There's of course the rspamd-users mailing list, which might be of assistance.
Good luck!
Bernardo
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[P-U] Re: Postfix lists are migrating to a new list server
On Tue, 7 Mar 2023, John Stoffel via Postfix-users wrote: So what's the option for a more upto date version of DKIM milter for debian? rspamd does DKIM, SPF, DMARC and ARC (and lots more), and doesn't segfault (so far ;-) Good luck. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
