[P-U] Re: Postfix lists are migrating to a new list server
If there’ a pull request to get it into the current “develop” branch of opendmarc, I have the privs to merge it. -Dan > On Mar 8, 2023, at 11:14 AM, Peter Ajamian via Postfix-users > wrote: > > On 9/03/23 08:11, Peter wrote: >> On 8/03/23 15:46, Scott Kitterman via Postfix-users wrote: >>> For Debian, if someone can find/test patches, I can get them into Debian's >>> package. I assume other distributors are similar. Feel free to update the >>> Debian bug with information. It's unfortunate we don't have a better >>> maintained solution. >> The patch appears to be committed in github: >> https://github.com/andreasschulze/OpenDMARC/commit/e8e7b41fef40032398d35650489a717108ac70de.patch > > Sorry I should note that's not official, but rather someone else's fork. It > appears to be the patch that's floating around at the moment, though. > > > Peter > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[P-U] The joke writes itself.
I know that P-U stands for postfix users. I get it that a short subject tag was desired, but would [postfix] have been that much more distracting, without adding the obvious third-grader label that might better be held by qmail? -Dan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix lists are migrating to a new list server
> On Mar 10, 2023, at 10:59 AM, Ralph Seichter via Postfix-users > wrote: > > * Jim Popovitch via Postfix-users: > >> On Fri, 2023-03-10 at 17:35 +0200, mailmary--- via Postfix-users wrote: >> >>> Looking at the opendkim/opendmarc right now, they appear dead over >>> the past 2 years or so, which is sad really. >> >> It's not sad at all. It's a testament to the stability of the project. >> Sure, both projects could use some polishing maybe, but that is not >> something that is "sad" > > Looking at the number of open issues and pull requests on GitHub for both > OpenDKIM and OpenDMARC, the assessment "He's dead, Jim." seems fitting > to me. To give just one example, Michael Orlitzky and I opened a pull > request adding OpenRC support (required for Gentoo Linux) to OpenDKIM in > April 2019 [1], and that PR is still stuck in limbo, as are many other > enhancements and bugfixes. To me, these are not signs of maturity or > stability, but of abandonment and death. So, this is a serious thread hijack off the whole “lists migrating to a new server” and I’m not going to respond much here. We could use help on a bunch of things, and I’m going to try and put together a list. I have administrative access to many things, but critically, NOT the box hosting the DNS or the mailing lists. I want to fix things. It’s not my day job, and I need help. Maybe I’ll make a separate post here. -Dan > > -Ralph > > [1] https://github.com/trusteddomainproject/OpenDKIM/pull/41 > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Helping OpenDKIM and OpenDMARC
Hey there all, I am one of the people who has maintainer access to OpenDKIM and OpenDMARC. I use both regularly, but I’m also a novice as a C-coder. (Sysadmin, not developer). As mentioned in another thread, I don’t have access to the web hosting stuff or the list management stuff, though I’m tempted to just put up a temp site on AWS and ask the person who DOES have access to put in an HTTP redirect for both of those. This is not my day job. My day job is in DNS operations, and it can be insanely busy, but also has lulls. I’ve also had a family situation that derails me at times. Without breaking confidences or saying too much, brains suck sometimes. (If you know, you know). = Anyway, Here’s a list of the things I’m trying to do, soonish: 1) Get the current “develop” branch of OpenDKIM cut into a release branch that includes recent enough SSL that it works on recent version, works with a modern autoconf, and works with the key types people are presently using. 2) Get some of the critical patches that are being used in some of the mainline OSes into base. THIS IS HARD. People jump in and say “Wait, I use GNUTLS, so I need that too!”. People say “Wait, this ancient solaris box I have in the corner running mail still uses openSSL 0.9.6, don’t break it on me!”. People complain about the lack of progress which honestly, doesn’t help. I know. This is also hard because there’s been a history of community patches breaking things on some other OS, or causing vague stability issues. 3) Get testing infrastructure spun up (on AWS or local VMware or somewhre that I can spin up for more OSes). Running unit tests on Slackware (via something like Jenkins, or manually) is not as simple as it sounds. As an example, someone posts a vague bug that says “this breaks for me on slackware 15”. Well, to respond to that, I need to replicate the problem on a Slackware 15 box. Slackware is NOT a friendly OS to just install and get running”. Same for OpenBSD. Same for Arch Linux. Same for Alpine Linux. Same for….etc. Each OS is a special snowflake with regard to how to get a BASE system able to configure a network stack and services without the system installing everything from X to Cups, maybe some firewall rules so we’re not running an open-to-the-world thing, install enough packages to build and keep up to date, and get cron running. I don’t think this project is unsalvageable, and I feel like forking it would do more harm than good. I want something better out the door, too. I may re-post this to mailop, but if you’re the kind of person that feels able to help with some of this, I’ll get (pending boss permission) a new mailing list spun up on dayjob’s existing infra that we can use to get going TODAY. Please contact me privately. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Maildir changes in 3.7.4?
All, We have our aliases file pushing things into our RT install, but also saving things to a maildir, so we can manually feed a single file back in, thusly: In /etc/aliases: noc:"|/usr/local/sbin/rtmailgate ops noc cor", "/root/ops/Maildir/" noc-comment:"|/usr/local/sbin/rtmailgate ops noc com", "/root/ops/Maildir/" On a recent upgrade, we started getting permission denied for the Maildir. (But note that the system upgrade may have also reset root’s homedir permissions) We noticed that root’s homedir was o-rwx, but we’re pretty sure it was that way before as well. (The maildir itself is owned by “nobody”) Is there supposed to be a setuid portion of postfix that allows it to deliver to user maildirs/mailboxes? Is there a way to tell it to do this when delivering to a given maildir? -Dan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Maildir changes in 3.7.4?
> On Jul 6, 2023, at 6:40 AM, Jaroslaw Rafa via Postfix-users > wrote: > > Dnia 6.07.2023 o godz. 05:43:22 Dan Mahoney via Postfix-users pisze: >> In /etc/aliases: >> >> noc:"|/usr/local/sbin/rtmailgate ops noc cor", >>"/root/ops/Maildir/" >> noc-comment:"|/usr/local/sbin/rtmailgate ops noc com", >>"/root/ops/Maildir/" >> >> On a recent upgrade, we started getting permission denied for the Maildir. > > If you really want to deliver mail to root (apart from the discussion if it > should be done or not, as in Viktor's reply), why do you want to put directly > the path to Maildir in the alias, instead of just the username "root"? As > far as I understand how aliases work, if you use just "root" (without > quotes) instead of "/root/ops/Maildir/", the mail should be delivered to > root's mailbox (unless you also aliased root to something else - but it is > strongly discouraged to do that and in many systems such a coment is even > included in the default /etc/aliases file). I don’t really want to. It’s inherited config that I’ve already changed. It could be a maildir anywhere on the filesystem, and my question was if there was a way to make the files owned by a particular user (say, the RT user). The local manpage says: Deliveries to external files and external commands are made with the rights of the receiving user on whose behalf the delivery is made. In the absence of a user context, the local(8) daemon uses the owner rights of the :include: file or alias database. When those files are owned by the superuser, delivery is made with the rights specified with the default_privs configuration parameter. I have to assume that pointing it at some archive dir is “in the absence of a user context" It’s never going to be accessed with a normal mail client, this is mainly for forensics in the case where we want to see the raw headers or report the raw body as spam evidence or something (which is not possible from within RT once RT has digested it). -Dan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Accepting mail from old Dell iDRAC
> On Aug 5, 2023, at 6:46 AM, Matus UHLAR - fantomas via Postfix-users > wrote: > > On 05.08.23 00:35, Charles Sprickman via Postfix-users wrote: >> Just following up to myself here, but this Dell POS just bails if it can't >> do TLS, lol: >> >> Aug 5 00:30:52 mail postfix/smtpd[76663]: < unknown[10.3.2.5]: EHLO ANON >> Aug 5 00:30:52 mail postfix/smtpd[76663]: discarding EHLO keywords: STARTTLS >> Aug 5 00:30:52 mail postfix/smtpd[76663]: > unknown[10.3.2.5]: 250-ANON >> Aug 5 00:30:52 mail postfix/smtpd[76663]: > unknown[10.3.2.5]: >> 250-PIPELINING >> Aug 5 00:30:52 mail postfix/smtpd[76663]: > unknown[10.3.2.5]: 250-SIZE >> 8048 >> Aug 5 00:30:52 mail postfix/smtpd[76663]: > unknown[10.3.2.5]: 250-VRFY >> Aug 5 00:30:52 mail postfix/smtpd[76663]: > unknown[10.3.2.5]: 250-ETRN >> Aug 5 00:30:52 mail postfix/smtpd[76663]: > unknown[10.3.2.5]: 250-AUTH >> PLAIN LOGIN >> Aug 5 00:30:52 mail postfix/smtpd[76663]: > unknown[10.3.2.5]: >> 250-ENHANCEDSTATUSCODES >> Aug 5 00:30:52 mail postfix/smtpd[76663]: > unknown[10.3.2.5]: 250-8BITMIME >> Aug 5 00:30:52 mail postfix/smtpd[76663]: > unknown[10.3.2.5]: 250-DSN >> Aug 5 00:30:52 mail postfix/smtpd[76663]: > unknown[10.3.2.5]: 250-SMTPUTF8 >> Aug 5 00:30:52 mail postfix/smtpd[76663]: > unknown[10.3.2.5]: 250 CHUNKING >> Aug 5 00:30:52 mail postfix/smtpd[76663]: smtp_stream_setup: maxtime=300 >> enable_deadline=0 min_data_rate=0 >> Aug 5 00:30:52 mail postfix/smtpd[76663]: < unknown[10.3.2.5]: QUIT >> Aug 5 00:30:52 mail postfix/smtpd[76663]: > unknown[10.3.2.5]: 221 2.0.0 Bye >> >> I believe I read somewhere that TLS + AUTH are linked, so I guess I'll just >> add 10.3.2.5 to "mynetworks" and call it a day... We do a lot of idraccy stuff at the day job. Yes, Auth and Encryption are linked, per: https://www.dell.com/support/kbdoc/en-us/62035/psqn-idrac7-idrac8-smtp-email-tls-encryption-settings Under the hood, idracs do use openSSL, and it’s not unreasonable to assume that both the SMTP client and the web server use the same linked version. You could start by seeing which ciphers the idrac 7 web UI supports. (Somewhere in the idrac settings, you can set a standard cipher list for the web server, but there’s not a way to get on the thing and run “openssl version"). If I understand the way the TLS handshake works, the server provides a list of supported ciphers, and the client picks one — at no point does the client say which ones it supports, implicitly. Ergo, the only way to really test this, seems to me to experimentally try STARTTLS against a much older machine (or one with older ciphers), that would have been current at the time the iDrac 7 was new, and see which the highest supported is — even if you decide not to use it in that state, the answer posted here could help someone else in the future. Also, are you running the latest iDrac firmware? -Dan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Is there a way to reject an internal domain on our border MXes
All, Pretty simple question: We have an internal domain, zimbra.example.org, but it's only used for internal routing of our corporate mail (there's a master delivery map that controls what addresses at example.org route to zimbra.example.org). We have other domains under example.org such as list servers, ticket systems, and the like, many of which have example.org addresses pointing at them. In no case should anything on the outside be directing mail directly to zimbra.example.org, and it is firewalled so only our border MXes can talk to it. Is there a way to reject mail destined to an internal domain (like zimbra.example.org) such that only our internal machines can deliver to it, but that any host on the outside gets an immediate reject notice from our border MXes? -Dan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: pushing changes to remote system
> On Mar 6, 2024, at 16:52, Wietse Venema via Postfix-users > wrote: > > Alex via Postfix-users: >> Hi, >> I have a few postfix systems on fedora38 with nearly identical >> configurations. I'd like to be able to push changes to them from a third >> system without having to login to them directly to do so. What's the >> best/most secure way to do this? >> >> For example, I'd like to push the recipient access file to both systems >> since they both relay mail for the same domains. Currently I'm doing this >> with rsync/ssh as root but would like to use a regular user. > > rsync renames files into place. That is good, because there is no > risk that it overwrites a file while some program reads from it. > > But if an unprivileged user can replace files in /etc/postfix, they > they are root equivalent. That is not the improvement that you > appear to be looking for. > > Maybe you can use a pull model instead, like curl and a REST server. This is a solved problem, using tools like ansible, chef, or puppet. Puppet specifically can be configured to do periodic pulls without having to login. -Dan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Is there a way to just quickly deliver "everything" to a file somewhere
Hey there all, I’m setting up a staging version of dayjob’s ticket system, and we’d basically like postfix to still function, but instead of touching the internet at all, just deliver everything to a single file (or a maildir, I suppose), regardless of if a file is invoked via sendmail, or a port 25 connection. I’d like nothing to leave the box. Is there some kind of transport hack I can use for this? -Dan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Is there a way to just quickly deliver "everything" to a file somewhere
> On Apr 2, 2024, at 10:52, Viktor Dukhovni via Postfix-users > wrote: > > On Tue, Apr 02, 2024 at 04:14:29AM -0400, Dan Mahoney via Postfix-users wrote: >> Hey there all, >> >> I’m setting up a staging version of dayjob’s ticket system, and we’d >> basically like postfix to still function, but instead of touching the >> internet at all, just deliver everything to a single file (or a maildir, I >> suppose), regardless of if a file is invoked via sendmail, or a port 25 >> connection. I’d like nothing to leave the box. >> >> Is there some kind of transport hack I can use for this? > ># No local(8) delivery ># >alias_database = >mydestination = >local_transport = error:5.1.2 Mailbox unavailable > ># No locally hosted domains, but you may want to set one of these ># non-empty to accept mail over SMTP, if mail comes in from outside, ># but this could also be via submission, permit_mynetworks, ... ># >relay_domains = >virtual_alias_domains = >virtual_mailbox_domains = > ># Collapse all recipients to a single address, delivered to a single ># maildir. ># >enable_original_recipient = no >virtual_alias_maps = static:allmail@$mydomain >default_transport = virtual >virtual_mailbox_maps = static:/var/spool/virtual/allmail/ >virtual_uid_maps = static:12345 >virtual_gid_maps = static:12345 I guess I missed something. — I also want it to null route (or route to a maildir) all *outbound* mail — so we can examine what our ticket system *would* send, is there something in here to do that, or is the above only for inbound? -Dan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Is there a way to just quickly deliver "everything" to a file somewhere
> On Apr 11, 2024, at 08:35, Viktor Dukhovni via Postfix-users > wrote: > > On Wed, Apr 10, 2024 at 11:39:24PM -0400, Dan Mahoney via Postfix-users wrote: > >>> On Apr 2, 2024, at 10:52, Viktor Dukhovni via Postfix-users >>> mailto:postfix-users@postfix.org>> wrote: >>> >>> On Tue, Apr 02, 2024 at 04:14:29AM -0400, Dan Mahoney via Postfix-users >>> wrote: >>>> Hey there all, >>>> >>>> I’m setting up a staging version of dayjob’s ticket system, and we’d >>>> basically like postfix to still function, but instead of touching the >>>> internet at all, just deliver everything to a single file (or a maildir, I >>>> suppose), regardless of if a file is invoked via sendmail, or a port 25 >>>> connection. I’d like nothing to leave the box. >>>> >>>> Is there some kind of transport hack I can use for this? > > Complete recipe was posted, quoted below: > >>> # No local(8) delivery >>> # >>> alias_database = >>> mydestination = >>> local_transport = error:5.1.2 Mailbox unavailable >>> >>> # No locally hosted domains, but you may want to set one of these >>> # non-empty to accept mail over SMTP, if mail comes in from outside, >>> # but this could also be via submission, permit_mynetworks, ... >>> # >>> relay_domains = >>> virtual_alias_domains = >>> virtual_mailbox_domains = >>> >>> # Collapse all recipients to a single address, delivered to a single >>> # maildir. >>> # >>> enable_original_recipient = no >>> virtual_alias_maps = static:allmail@$mydomain >>> default_transport = virtual >>> virtual_mailbox_maps = static:/var/spool/virtual/allmail/ >>> virtual_uid_maps = static:12345 >>> virtual_gid_maps = static:12345 >> >> I guess I missed something. — I also want it to null route (or route >> to a maildir) all *outbound* mail — so we can examine what our ticket >> system *would* send, is there something in here to do that, or is the >> above only for inbound? > > I see no disclaimer that this would only cover "inbound" or "outbound" > mail. Rather, I see "default_transport = virtual", which sends *all* > mail to the maildir. Once mail is in the queue it is simply mail to be > delivered, there is no "inbound" or "outbound" when making transport > decisions. > > What the recipe comments doe is that the above configuration does not > accept any inbound mail as written, you'd need to allow some clients to > inject mail via SMTP either to "inbound" domains, by e.g. adding some to > "virtual_alias_domains" or "virtual_mailbox_domains" (same result either > way). Or via "smtpd_recipient_restrictions" to allow some clients to > send mail (just adding them to "mynetworks" would typically suffice). > > Your reluctance to test this is puzzling. Read it, try to understand > it, test it, tweak as needed, repeat. I’ve dropped this in, changing only 12345 to the “nobody” UID (65534 on BSD), rather than a UID that doesn’t exist. This fails for me with: postfix/virtual[3806]: fatal: bad string length 0 < 1: virtual_mailbox_base = I’ve chown'd /var/spool/virtual/allmail to that UID/GID of course. What am I missing? -Dan___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] myorigin usage for ONLY unqualified addresses
Hello, We currently have myorigin = $mydomain, and mydomain = dayjob.org on one of our border MXes, which is also the outbound MX for our whole organization. We are a fairly large site with mxes in two locations and many machines which send mail which may relay through here. Mydomain feels like the *correct* origin answer. However, we would like our rootmail to respect our aliases file, which tells root to go to a specific mail destination on a specific box. FreeBSD by default sends all its nightly security checks and the like to "root" (bareword), and we globally deploy an alias file that reroutes this to a collector on a single machine, both for our machines that run postfix, as well as our machines that run more simple mailers like dma. We'd like the expectations consistent across the board. The docs say: === The myorigin parameter specifies the domain that appears in mail that is posted on this machine. The default is to use the local machine name, $myhostname, which defaults to the name of the machine. Unless you are running a really small site, you probably want to change that into $mydomain, which defaults to the parent domain of the machine name. For the sake of consistency between sender and recipient addresses, myorigin also specifies the domain name that is appended to an unqualified recipient address. === Is there a way to split these two functions, and ONLY affect unqualified "bareword" addresses with myorigin, without causing potential surprises elsewhere? -Dan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: myorigin usage for ONLY unqualified addresses
> On Jun 15, 2024, at 06:19, Wietse Venema via Postfix-users > wrote: > > Dan Mahoney via Postfix-users: >> Hello, >> >> We currently have myorigin = $mydomain, and mydomain = dayjob.org >> on one of our border MXes, which is also the outbound MX for our >> whole organization. We are a fairly large site with mxes in two >> locations and many machines which send mail which may relay through >> here. Mydomain feels like the *correct* origin answer. >> >> However, we would like our rootmail to respect our aliases file, >> which tells root to go to a specific mail destination on a specific >> box. > > Use virtual_alias_maps, as shown below. > >> FreeBSD by default sends all its nightly security checks and the >> like to "root" (bareword), and we globally deploy an alias file >> that reroutes this to a collector on a single machine, both for >> our machines that run postfix, as well as our machines that run >> more simple mailers like dma. We'd like the expectations consistent >> across the board. > > Use a virtual alias mapping from "r...@dayjob.org" to the collector > email address. This is a variation on > > /usr/local/etc/postfix/main.cf: > virtual_alias_maps = hash:/local/etc/postfix/virtual-for-root > > /local/etc/postfix/virtual-for-root: >r...@dayjob.org collector-u...@collector-host.dayjob.org > > Run "postmap hash:/local/etc/postfix/virtual-for-root" after > editing the file. > > Instead of a hash: map you could use a networked table such as *SQL > or LDAP. This would still result in rootmail being from root@mydomain, not root@myhostname -- regardless of the destination, which makes it way more confusing to read. If I send mail to root@localhost, it respects aliases and does the right thing. If I send mail to "root", it does not, because it already hits our existing virtual_maps destination for r...@dayjob.org <mailto:r...@dayjob.org>. (That address reaches people, not a collector script. Our cron handling script does eventually fall-through to those people if it doesn't match the usual cron stuff) We are already setting masquerade_domains for our entire domain: mydestination = $myhostname, localhost.$mydomain, post.dayjob.org, localhost masquerade_domains = !lists.dayjob.org, dayjob.org <http://dayjob.org/> masquerade_exceptions=root So on every other system that just appends their hostname to rootmail, this already works, and we don't rewrite it. So perhaps the masquerading covers most of the normal uses of myorigin=mydomain? What else is covered in the definition of "myorigin" when it says "domain that appears in mail that is posted on this machine"? -Dan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: myorigin usage for ONLY unqualified addresses
> On Jun 15, 2024, at 15:03, Wietse Venema via Postfix-users > wrote: > > One addendum about how to distinguish from root@mydomain > from different hosts. > > Dan Mahoney via Postfix-users: >>> Use a virtual alias mapping from "r...@dayjob.org" to the collector >>> email address. This is a variation on >>> >>> /usr/local/etc/postfix/main.cf: >>>virtual_alias_maps = hash:/local/etc/postfix/virtual-for-root >>> >>> /local/etc/postfix/virtual-for-root: >>> r...@dayjob.org collector-u...@collector-host.dayjob.org >>> >>> Run "postmap hash:/local/etc/postfix/virtual-for-root" after >>> editing the file. >>> >>> Instead of a hash: map you could use a networked table such as *SQL >>> or LDAP. >> >> This would still result in rootmail being from root@mydomain, not >> root@myhostname -- regardless of the destination, which makes it >> way more confusing to read. > > I forgot to mention that FreeBSD daily/security/weekly/monthly email > messages have the hostname in the Subject. Like this: > >Subject: hostname.porcupine.org weekly run output >Subject: hostname.porcupine.org daily run output >Subject: hostname.porcupine.org daily security run output > > They arrive in the same mailbox, and there is confusion about their > provenance. They do, yes, but cron messages generally do not, which is why I'm trying to solve for the more general problem. -Dan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] postfix reload writing to stderr
All, This is the most minor problem, but I’ll bring it up. We use Lets Encrypt for our certs (using the Dehydrated client), and call a “postfix reload” as part of the hook script if a cert has been renewed. We also wrapper this with ‘cronic’ which works not under the old cron principle that “all cron jobs should be silent and output only in an error” (which means by the time you’ve got an error, you’ve lost context), but instead, that you’ll get all a script’s output if it either exits with a bad error code, *or* writes to stderr. So the issue: When calling “postfix reload”, should "postfix/postfix-script: refreshing the Postfix mail system” be written to stderr? It’s not an error, and it feels like this message should go to stdout, or that there should be a command-line option to suppress non-error messages. Obviously, in my hook script, I can redirect stderr to /dev/null, but this means I might miss “real” errors. -Dan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Viktor, can you share your dane-checking script?
I know Viktor routiinely scans for TLSA signatures (and pokes folks if we get it wrong). I’d like to turn this into a check in our internal monitoring, since we do occasionally roll the cert on our MXes (which need to be “real” OV certs due to some customer requirements — I don’t make the rules). Viktor, do you have that code up somewhere? (Obviously, I’d make it single-target) -Dan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Viktor, can you share your dane-checking script?
> On Feb 10, 2025, at 01:59, Viktor Dukhovni via Postfix-users > wrote: > > On Mon, Feb 10, 2025 at 12:22:44AM -0800, Dan Mahoney via Postfix-users wrote: > >> I’d like to turn this into a check in our internal monitoring, since we >> do occasionally roll the cert on our MXes (which need to be “real” OV >> certs due to some customer requirements — I don’t make the rules). >> >> Viktor, do you have that code up somewhere? (Obviously, I’d make it >> single-target) > > The highly parallel engine, which scans over 1k domains/sec is not what > you're looking for. Rather, I have multiple times posted a link to a > much simpler bash function that uses openssl-s_client(1). > > > https://list.sys4.de/hyperkitty/list/dane-us...@list.sys4.de/thread/NKDBQABSTAAWLTHSZKC7P3HALF7VE5QY/ Followon question, related to openSSL versus Postfix, but relevant for those of us trying to understand the monitoring. So we check DANE using s_client -starttls smtp -connect $host:25 -verify 9 -verify_return_error -dane_ee_no_namechecks -dane_tlsa_domain $host -dane_tlsa_rrdata $rr And if we parse the output, the two lines in the output we’re looking for are: Verification: OK DANE TLSA 3 1 1 ...4aab479b6279fe7044a0fa89 matched EE certificate at depth 0 (Plus the openssl exit code of zero). Correct? Is either of these more “canonical" than the others? (I know that for different values in the TLSA record, the text won’t be exactly that). Is there some reason that the TLSA record openssl prints is shortened? There are definitely longer lines in the openssl output, such as "Resumption PSK”, so it’s not like OpenSSL has an arbitrary wrap-length. -Dan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Incoming OpenDKIM signature verification failing
If any of those mailing lists are open, regular lists that I could be subscribed to, for testing, I’d be happy to try to do so to validate this for you. -Dan > On May 9, 2025, at 21:07, Nick Tait via Postfix-users > wrote: > > On 10/05/2025 15:29, Nick Tait via Postfix-users wrote: >> But of course if the first scenario still exhibits the issue, then that >> probably disproves my theory immediately? > > Just thinking a bit more about this... If the first test fails, then you can > compare the headers and body in the received email with what you sent in the > raw email text file, to see if there have been any changes made in-transit. > If there aren't any differences, then the most likely explanation for the > DKIM failure would have to be a DNS issue - i.e. the server validating the > DKIM signature isn't getting the right data when querying for the DKIM > selector? In that case you might look at whether you get different results > when you query the TXT record (e.g. with "dig" tool) using your local > resolver vs. using 8.8.8.8 (for example)? > > Nick. > > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Incoming OpenDKIM signature verification failing
Mime-version was listed as a signed header but was absent. I suspect his header checks cleaned that out. Note that having a header listed in the H equals list, but having that header be absent is legal, but I don’t know why the signing software would say it’s signing that header when it’s not there. especially for a mailing list generator that presumably generates lots of the same thing. -Dan Sent from my iPhone > On May 10, 2025, at 09:41, Matus UHLAR - fantomas via Postfix-users > wrote: > > >> >> Dnia 9.05.2025 o godz. 16:18:35 Matus UHLAR - fantomas via Postfix-users >> pisze: >>> I use pyspf-milter which is from the same package I believe (python, >>> there's also perl version policyd-spf) and it only accepts/rejects >>> e-mail and adds Authentication-Results: header. > >> On 09.05.25 16:41, Jaroslaw Rafa via Postfix-users wrote: >> Check if mails that are failing DKIM: >> - already contain "Authentication-Results:" header before being processed by >> pyspf-milter, and that header is DKIM signed >> or > > Authentication-Results was not signed in OP's mail... > >>> Question: aren't those mails failing DKIM from mailing lists? >>> Because that is quite often case where DKIM does not pass. >> >> That may be a completely different issue. > > exactly, I just wanted to be sure if the problem si not misunderstood - I > also receive many invalid DKIM headers from mailing lists, because my DMARC > policy is none and mailman2 in that case often does not rewrite From: header > > >> On 09.05.25 17:17, Benny Pedersen via Postfix-users wrote: >> Matus UHLAR - fantomas via Postfix-users skrev den 2025-05-09 16:18: > [...] >> your mail gives this result here > > Benny, you should read mail more carefully. I am not the OP and don't have > the problem. > >> On 09.05.25 17:00, Phil Stracchino via Postfix-users wrote: >> Consider replacing policyd-spf, opendkim, AND opendmarc with rspamd. It >> does all of those jobs, does them *better*, and is actively maintained. > > This advice is irelevant, because none of the mentioned software causes the > issue and thus changing them is not going to fix it. > >> On 10.05.25 09:12, Ken Biggs via Postfix-users wrote: >> Woo hoo! I think I found the issue! I'm guessing this is probably an >> obvious thing, but I went line by line through my main.cf and found: >> >> mime_header_checks = regexp:/etc/postfix/header_checks >> header_checks = regexp:/etc/postfix/header_checks >> >> Not sure when I added those (it's been quite a while), but commenting them >> out seems to have resolved the issue! > > just do ls -l /etc/postfix/header_checks > >> I'm not sure if I need to be doing the header checks a different way. >> Recommendations would be appreciated. >> >> Thank you to everyone! Your input and help finally got me looking in the >> right places for the right things! The users on this mailing list are >> amazing! > > It's not the checks what caused your problem, it was something in those > checks. I am now curious: > Which headers did you add/modify/delete, which caused DKIM to fail? > > > -- > 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. > Spam = (S)tupid (P)eople's (A)dvertising (M)ethod > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: SSL cert authority, letsencrypt error
There’s only one certificate in your chain, you need to send the intermediate cert as well. The cert you’re signing with isn’t trusted by browsers. Certificate chain 0 s:CN = rollcage13.aboc.net.au i:C = US, O = Let's Encrypt, CN = R10 Arguably, this is even worse than being self-signed. Compared with my sendmail (stop laughing) server: Certificate chain 0 s:CN = prime.gushi.org i:C = US, O = Let's Encrypt, CN = E5 1 s:C = US, O = Let's Encrypt, CN = E5 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 I believe if you just point postfix at your cert chain, it will do the right thing as long as the certs are in the correct order. -Dan > On May 8, 2025, at 15:34, Carl Brewer via Postfix-users > wrote: > > > Hi, > > I've been running postscript on a FreeBSD 13.x server with Letsencrypt > running as a cron job to keep SSL certs up to date automagically : > > > in main.cf : > > > smtpd_tls_security_level = may > smtpd_tls_cert_file = > /usr/local/etc/letsencrypt/live/rollcage13.aboc.net.au/cert.pem > smtpd_tls_key_file = > /usr/local/etc/letsencrypt/live/rollcage13.aboc.net.au/privkey.pem > > As best I can tell, this has worked for a number of years without issue. > > I've noticed this error of late : > > May 9 08:15:44 rollcage13 postfix/smtpd[88039]: warning: TLS library > problem: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad > certificate:/usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:1621:SSL alert > number 42: > > And some mail isn't making it through - I guess it's possible that the above > config never worked and I didn't notice, but I suspect this is a new thing. > > > When I check the SSL config using the ssl-tools.net checks, I'm seeing > "Unknown Authority" as the error, but also seeing a cert that looks ok : > > From : https://ssl-tools.net/mailservers/rollcage13.aboc.net.au > > Certificates > First seen at: a day ago > CN=rollcage13.aboc.net.au > Certificate chain > >rollcage13.aboc.net.au >40 days remaining >2048 bit >sha256WithRSAEncryption >Unknown Authority >R10 > > Subject > Common Name (CN) > >rollcage13.aboc.net.au > > Alternative Names > >rollcage13.aboc.net.au > > > Apart from the "Unknown Authority" it looks fine. > > Permissions in the cert directory are all ok, or at least, all the same, so > if it can read one bit it can read them all : > > rollcage13:/usr/local/etc/letsencrypt/live/rollcage13.aboc.net.au # ls -la > total 16 > drwxr-xr-x 2 root wheel7 Mar 18 05:08 . > drwxr-s--- 3 root readcirts4 Sep 19 2021 .. > -rw-r--r-- 1 root wheel 692 Sep 19 2021 README > lrwxr-xr-x 1 root wheel 47 Mar 18 05:08 cert.pem -> > ../../archive/rollcage13.aboc.net.au/cert23.pem > lrwxr-xr-x 1 root wheel 48 Mar 18 05:08 chain.pem -> > ../../archive/rollcage13.aboc.net.au/chain23.pem > lrwxr-xr-x 1 root wheel 52 Mar 18 05:08 fullchain.pem -> > ../../archive/rollcage13.aboc.net.au/fullchain23.pem > lrwxr-xr-x 1 root wheel 50 Mar 18 05:08 privkey.pem -> > ../../archive/rollcage13.aboc.net.au/privkey23.pem > > > > any suggestions, I'm no wizz when it comes to SSL setups, and am pretty rusty > here. > > > > > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Incoming OpenDKIM signature verification failing
Nothing’s jumping out to me in your test message, other than that the mime-version header field is missing, but that’s legal. I might suggest trying the “Develop” branch of OpenDKIM from git, as there are some changes in that which *may* fix things, or at least…give something to compare. The ecosystem of OpenDKIM right now is that a lot of maintainers are cherry-picking their patches and the project needs love. I might also suggest setting spamassassin to validate the DKIM signatures directly, just as a diagnostic — while it’s possible that something’s folding your headers in a weird way, I’d love to see that comparison. The world really needs some tool where you can capture your single message to a .mbox file and upload it for testing. Also, OpenDKIM needs to be able to log at the very least, the computed bh of a message just so you can eliminate a body mod as a reason for a sigfail. -Dan > On May 8, 2025, at 13:06, Ken Biggs via Postfix-users > wrote: > > OpenDKIM is failing signature verification on most incoming emails. Out of > 1,146 incoming emails, 173 have been successfully verified and 973 have "bad > signature data". The failing emails include email from google, amazon, > sailthru, and many other reasonably technically capable firms that I would > expect to verify successfully. I have tested DNS lookups and have found no > issues with querying for the DKIM record. I have researched for hours trying > to find something helpful, but the few posts that aren't specifically dealing > with signing emails don't seem to address the issues I'm seeing. BTW ... > outgoing emails are signed properly and passing DKIM validation. > > I'm running: > Rocky Linux release 9.5 > Postfix 3.5.25 > OpenDKIM 2.11.0-0.34 > OpenDMARC 1.4.2-22 > SpamAssassin 3.4.6-5 > > main.cf has the following milter declarations: > milter_default_action = accept > milter_protocol = 6 > smtpd_milters = > inet:127.0.0.1:8891,inet:127.0.0.1:8893,unix:/run/spamass-milter/spamass-milter.sock > non_smtpd_milters = $smtpd_milters > > master.cf has: > policyd-spf unix - n n - 0 spawn >user=policyd-spf argv=/usr/libexec/postfix/policyd-sp > > I currently have opendmarc config RejectFailures set to false due to this > issue. I would like to set it back to true. > > Here is an example DKIM failure from the maillog: > May 8 14:40:44 primary postfix/smtpd[672210]: connect from > maile-af.linkedin.com[108.174.3.198] > May 8 14:40:45 primary postfix/smtpd[672210]: Anonymous TLS connection > established from maile-af.linkedin.com[108.174.3.198]: TLSv1.2 with cipher > ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits) > May 8 14:40:45 primary policyd-spf[672216]: spfcheck: pyspf result: > "['Pass', 'sender SPF authorized', 'helo']" > May 8 14:40:45 primary policyd-spf[672216]: Pass; identity=helo; > client-ip=108.174.3.198; helo=maile-af.linkedin.com; > envelope-from=s-2kgdgjrbd5fxo2yedmgwvt5lispoakbzohsqk7jiokpemk84raucs...@bounce.linkedin.com; > receiver= > May 8 14:40:45 primary policyd-spf[672216]: spfcheck: pyspf result: > "['Pass', 'sender SPF authorized', 'mailfrom']" > May 8 14:40:45 primary policyd-spf[672216]: Pass; identity=mailfrom; > client-ip=108.174.3.198; helo=maile-af.linkedin.com; > envelope-from=s-2kgdgjrbd5fxo2yedmgwvt5lispoakbzohsqk7jiokpemk84raucs...@bounce.linkedin.com; > receiver= > May 8 14:40:45 primary policyd-spf[672216]: prepend Received-SPF: Pass > (mailfrom) identity=mailfrom; client-ip=108.174.3.198; > helo=maile-af.linkedin.com; > envelope-from=s-2kgdgjrbd5fxo2yedmgwvt5lispoakbzohsqk7jiokpemk84raucs...@bounce.linkedin.com; > receiver= > May 8 14:40:45 primary postfix/smtpd[672210]: 603932014E: > client=maile-af.linkedin.com[108.174.3.198] > May 8 14:40:45 primary postfix/cleanup[672217]: 603932014E: > message-id=<1082066601.9633899.1746733244...@ltx1-app67844.prod.linkedin.com> > May 8 14:40:45 primary opendkim[671562]: 603932014E: maile-af.linkedin.com > [108.174.3.198] not internal > May 8 14:40:45 primary opendkim[671562]: 603932014E: not authenticated > May 8 14:40:45 primary opendkim[671562]: 603932014E: message has signatures > from maile.linkedin.com, linkedin.com > May 8 14:40:45 primary opendkim[671562]: 603932014E: signature=hpodGVG7 > domain=maile.linkedin.com selector=d2048-202308-0e result="signature > verification failed"; signature=c7qBDZxE domain=linkedin.com > selector=d2048-202308-00 result="signature verification failed" > May 8 14:40:45 primary opendkim[671562]: 603932014E: bad signature data > May 8 14:40:45 primary opendmarc[754]: 603932014E: linkedin.com fail > May 8 14:40:45 primary spamd[547780]: spamd: connection from ::1 [::1]:48946 > to port 783, fd 5 > May 8 14:40:45 primary spamd[547780]: spamd: setuid to sa-milt succeeded > May 8 14:40:45 primary spamd[547780]: spamd: processing message > <1082066601.9633899.1746733244...@ltx1-app67844.prod.linkedin.com> for > sa-milt:988 > Ma
[pfx] Re: Questions on a couple of log entries
> On May 20, 2025, at 07:43, Viktor Dukhovni via Postfix-users > wrote: > > On Tue, May 20, 2025 at 08:26:37AM -0400, Wietse Venema via Postfix-users > wrote: > >>> We're in the process of trolling all our logs to figure out what we can >>> ignore/filter/take action on, and we have a couple entries that I'm >>> wondering what's happening under the hood: >>> > > The remote SMTP client's list of TLS 1.2 supported ciphers did not overlap > with the > list supported by the SMTP server: This one I kind of suspected. Interestingly, since the fallback method is “plaintext” this is effectively just noise. > The remote SMTP client reported not liking the server certificate (sent > an alert to that effect): That was the bit that confused me — if we’re seeing an alert that says bad certificate, is it because we’re misconfigured on our end? I’m sure we’re not asking for client certs, and as far as I know there’s no way to present one if we’re not asking. I wasn’t aware there was a signaling method to say “I don’t like it, go away”. Thanks as always for what you folks do. -Dan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Questions on a couple of log entries
Hey folks, We're in the process of trolling all our logs to figure out what we can ignore/filter/take action on, and we have a couple entries that I'm wondering what's happening under the hood: 2025-05-18T15:42:07+00:00 post.dayjob.org postfix/smtpd [mail.warning] warning: TLS library problem: error:0AC1:SSL routines::no shared cipher:/usr/src/crypto/openssl/ssl/statem/statem_srvr.c:1742: And 2025-05-19T08:20:09+00:00 amstel.dayjob.org postfix/smtpd [mail.warning] warning: TLS library problem: error:0A000412:SSL routines::sslv3 alert bad certificate:/usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:1605:SSL alert number 42 They're probably harmless, but I am sort of interested in what would make these happen? -Dan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Converting a queue file into other formats
Hey there folks. I’ve been debugging a faulty milter, which was crashing due to one particular malformed message. While trying to figure out how to get it to core (and replace it with a build with debug symbols), I changed postfix to change the default milter action to quarantine. Ergo, my question is: what’s the best way to take the queue file and convert it back to something which most closely resembles what came in over the wire? The read generated by postcat has some weird wrapping and formatting. -Dan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
