Re: Some README files are not included in the postfix-files
Jaroslav Skarvada: > Hi, > > it seems the following README files are not included in the > conf/postfix-files: > BDAT_README > MAILLOG_README > POSTSCREEN_3_5_README > SMTPUTF8_README > > Is it intended? Yikes, these are all "new" files added with Postfix 3.x. I'll add a pre-release check for that. Wietse > Checked with the postfix-3.6.4. > > Downstream Fedora bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=2041056 > > thanks & regards > > Jaroslav > >
Some README files are not included in the postfix-files
Hi, it seems the following README files are not included in the conf/postfix-files: BDAT_README MAILLOG_README POSTSCREEN_3_5_README SMTPUTF8_README Is it intended? Checked with the postfix-3.6.4. Downstream Fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2041056 thanks & regards Jaroslav
Re: Some README files are not included in the postfix-files
Am 21.01.22 um 00:06 schrieb Wietse Venema: Jaroslav Skarvada: Hi, it seems the following README files are not included in the conf/postfix-files: BDAT_README MAILLOG_README POSTSCREEN_3_5_README SMTPUTF8_README Is it intended? Yikes, these are all "new" files added with Postfix 3.x. I'll add a pre-release check for that. Wietse, so after years and years I have been able to find a glitch, which is an extremely rare occasion, that is to say: Thank you for the continued attention to Postfix's high quality, in-depth. Appreciated for decades, literally. Dank U zeer. Regards, Matthias
Re: Some README files are not included in the postfix-files
> Appreciated for decades, literally. Dank U zeer. For me just decade not decades ;-) but also from my side: dankä Dir villmol Wietse Also thanks a lot to all that help here on list and all who commit code to that masterpiece of SMTP software Cheers and have a good one tobi On Fri, 2022-01-21 at 01:57 +0100, Matthias Andree wrote: > Am 21.01.22 um 00:06 schrieb Wietse Venema: > > Jaroslav Skarvada: > > > Hi, > > > > > > it seems the following README files are not included in the > > > conf/postfix-files: > > > BDAT_README > > > MAILLOG_README > > > POSTSCREEN_3_5_README > > > SMTPUTF8_README > > > > > > Is it intended? > > Yikes, these are all "new" files added with Postfix 3.x. > > > > I'll add a pre-release check for that. > > Wietse, > > so after years and years I have been able to find a glitch, which is > an > extremely rare occasion, that is to say: > > Thank you for the continued attention to Postfix's high quality, in- > depth. > Appreciated for decades, literally. Dank U zeer. > > Regards, > Matthias
Re: GhettoForge Postfix3
On 19/01/22 7:44 am, post...@ptld.com wrote: GhettoForge has a repo for Postfix3, it is not clear to me if Postfix3 is another beast entirely or if it is just a normal Postfix version 3 and higher. Can someone explain what is the purpose of "Postfix3"? It's just the latest version of Postfix, the reasin it's called "postfix3" is historical: Back before the release of Postfix 3.0 GhettoForge used to ship the package as postfix, the problem was that postfix prior to 3.0 did not have loadable dictionary types, so in order to provide support for every dictionary type the package had to compile it in, and have requirements of every lib under the sun for it. When 3.0 added loadable dictionary types I was able to package them under separate binary packages such as postfix-mysql, postfix-pgsql, postfix-pcre, etc. This allowed me to remove those from the base postfix package. The problem with this is that there were a number of people who already used postfix from GhettoForge and if they ran a "yum update" command they would have found their email servers breaking very quickly because the postfix package lacked the dictionaries that used to be compiled in. The solution was to release future postfix packages as postfix3, so that people in this situation would not have the above mentioned surprise breakage and when they updated they could install the individual dictionary packages that they needed. After that EL8 was released and for efficiency sake it is easier to build the same package names from the same source rpm rather than have a package named "postfix" for EL8 and "postfix3" for EL7. So that's the story of why it's called "postfix3" now. Are there other options (repos) for getting current versions of Postfix using dnf on a RHEL system? I have heard of the odd repo having it, but I would not recommend them over GhettoForge. Of course I'm biased. Also I believe that Red Hat intends to release newer postfix versions as module streams in later EL8 point releases, but they will not be as current as GhettoForge is. Wietse Venema Wrote: According to http://ghettoforge.org/index.php/Postfix3 it's the latest (presumably stable) release. They appear to have Postfix 3.6 at this time. 3.6.4 is in gf-testing The exmples on that page use yum, not dnf. EL7 uses yum, EL8 uses dnf, but it comes symbolic linked to yum, so the same yum commands that work in el7 also work in el8, even though you are, in fact, using dnf. The commands on the page use yum because they work in both major releases and so it avoids having to put separate commands for EL7 vs EL8 examples. post...@ptld.com Wrote: Wait, so its a fork of Postfix? And not the same code as what Wietse releases for the same version? It is not a fork, it is a packaged build from the upstream Postfix sources. There are some minor patches which come from Fedora and you can see what they are in the available src.rpm file. Peter
Should that behaviour be like this?
Today we stumbled over a postfix behaviour that was quite unexpected for us. we had in main.cf smtpd_client_restrictions = check_helo_access pcre:/etc/postfix/helo_access.pcre,regexp:/etc/postfix/helo_access.rege x so 2 access maps for helo but in "wrong" restriction. Postfix evaluated the first map (pcre) correclty in HELO State and tested the provided helo name. But the second map was used to fire in CLIENT state. So for the 2nd map postfix checked the PTR of the client. By using twice check_helo_access with just one map per line (although still in the wrong restriction) both maps were used for HELO only. Also putting the check_helo_access (all on one line) into the correct restriction "smtpd_helo_restrictions" solves the "issue" I'm fully aware that the main problem is that we placed a HELO check in the client_restrictions but still the observed behaviour was quite un- expected for us. One map in the correct state and the other in the wrong one? Does not sound like postfix ;-) We use postfix 3.5.6 Cheers and have a good one tobi
Re: Should that behaviour be like this?
tobs...@brain-force.ch: > Today we stumbled over a postfix behaviour that was quite unexpected > for us. > > we had in main.cf > > > smtpd_client_restrictions = >check_helo_access > pcre:/etc/postfix/helo_access.pcre,regexp:/etc/postfix/helo_access.rege Commas and spaces are treated identically, therefore this is equivalent to: smtpd_client_restrictions = check_helo_access pcre:/etc/postfix/helo_access.pcre regexp:/etc/postfix/helo_access.regex The syntax on the last line was deprecated, and was removed from the manpage. For backwards compatibility, if you omit the check_xxx_access before a table, then the kind of access is determined by the smtpd_xxx_restrictions type. Therefore the above is equivalent to: smtpd_client_restrictions = check_helo_access pcre:/etc/postfix/helo_access.pcre check_client_access regexp:/etc/postfix/helo_access.regex Wietse
Re: SASL questions
> On Tue, Jan 18, 2022 at 07:22:40PM -0500, Joe Acquisto-j4 > > wrote: > >> . . . >> > I would imagine that Postfix can only authenticate to >> > servers that have entries in /etc/postfix/sasl_passwd. >> > >> > smtp_sasl_password_maps (default: empty) >> > >> > Optional Postfix SMTP client lookup tables with one >> > username:password entry per sender, remote hostname >> > or next-hop domain. Per-sender lookup is done only >> > when sender-dependent authentication is enabled. If >> > no username:password entry is found, then the >> > Postfix SMTP client will not attempt to >> > authenticate to the remote host. >> > >> > But it seems unlikely that you'd have put an entry there >> > for a server of yours that doesn't authenticate. >> > >> > Perhaps you need to add that server to debug_peer_list >> > and see what the extra logs say. >> > >> > cheers, >> > raf >> >> I believe I have that correct, per examples (and it is working mostly as > expected) >> /etc/postfixsasl_passwd takes this form: >> >> j...@aaa.comjoea@AAA:ADADAD >> j...@aaad.comj...@aaad.com:ADADAD2 >> >> As said, this appears to work and does not interfer with incoming >> email that goes to a local host, unauthenticated, in all but one case. > > Yes, it has nothing to do with incoming connections. > It's used by the Postfix SMTP client when making > outgoing connections. > > Does this mean that the problem you are seeing is with > incoming connections? Sorry, but I was under the > impression that your problem was that Postfix's SMTP > client was trying to authenticate itself to a remote > server when delivering mail somewhere (presumably > because that remote server required it). If the problem > is that an incoming SMTP connection is coming from a > remote client, and your Postfix is insisting on that > connection authenticating itself, then that's a very > different thing. > >> joe a > > cheers, > raf Sorry for the confusion. I will refrain from any self-deprecating attempts at humor. It is an issue with email that postfix has received, via fetchmail, and is attempting to deliver to another system. Authentication is being attempted, without it being required or requested, at least as far as I can tell. Any "normal" mail that is fetched from that gmail account, or others, delivers with no apparent attempt to authenticate. All authentication should fail, in any case, as it is not configured on the target server. I have attempted to examine the subject email while in the deferred queue (postcat) and comparing it to other examples. Nothing jumped out at me. Did not find a way to route mail to the deferred queue so as to revert to smtp_sender_dependent_authentication = no and send a duplicate email, then compare the two. This may not be worth further effort as it is a rather problematic way for me to test and maybe should be abandoned. I've just got it in mind there is nothing "wrong" with it and it "should" work and wonder why. But, what do I know? Thanks for the follow up. joe a
