Re: RHEL / CentOS 7 RPMs
On 14/3/2016 8:56 μμ, Peter wrote: The -release RPM for CentOS 7 is at: http://mirror.symnds.com/distributions/gf/el/7/gf/x86_64/gf-release-7-8.gf.el7.noarch.rpm Thank you Peter, I took a first look at your Postfix3 SRPM package today. It looks well organized and updated. Before I move on with building experimentation, a very basic question: The SPEC file, starts with: %bcond_without mysql %bcond_without pgsql %bcond_without sqlite %bcond_without ldap %bcond_without pcre %bcond_without sasl %bcond_without tls %bcond_without ipv6 %bcond_without pflogsumm So, it seems that initially the above compilation options are disabled. Right? To enable particular options, should it be enough to change the above entries to (example, to enable all options except sql*): %bcond_without mysql %bcond_without pgsql %bcond_without sqlite %bcond_with ldap %bcond_with pcre %bcond_with sasl %bcond_with tls %bcond_with ipv6 %bcond_with pflogsumm ...? And a second question: Could we build the package as postfix (not postfix3) so as to be able to replace the default OS postfix package on installation (automatic upgrade)? Why Postfix v3 should be treated differently than the standard postfix packages (currently v2.10.1 on CentOS 7)? Wouldn't an upgrade-in-place be possible? Please clarify. Thanks, Nick
Re: Mails in active queue are never tried to be sent
Pedro David Marco: > > > Hello everybody!! > > i am trying to run a filter relay with Postfix and i have a doubt about > active queues i need help with, please... > > Postfix documentation states clearly that: > > "Messages in the active queue are ready to be sent (runnable), but > are not necessarily in the process of being sent (running)." Show ALL non-debug logging for a problem message. grep name-of-queue-id /the/maillog/file You may anonymize domain names per instructions in http://www.postfix.org/DEBUG_README.html#mail Wietse
Re: RHEL / CentOS 7 RPMs
On 15/3/2016 11:44 πμ, Nikolaos Milas wrote: So, it seems that initially the above compilation options are disabled. Right? To answer my own question, in fact, it's the other way round! For example: %bcond_without ldap means ldap is enabled by default! And a second question: Could we build the package as postfix (not postfix3) so as to be able to replace the default OS postfix package on installation (automatic upgrade)? This question remains open, so please advise. By the way, it seems to me that an important option to add to the spec file is Dovecot SASL (used quite extensively these days). So, I "merged" some stuff from S. J. Mudd's RPMs and the build rolled fine. (Note however that I did not try to build without sasl support.) You may want to merge it more intelligently -as I am not proficient in spec files-. You may find the modifed file at: http://iweb.noa.gr/files/postfix3.1.0-1.noanet.spec Added sections are marked using: # Added by Nick - Section x of 4 # # # End of Nick Section x where x = 1 - 4 A final query: S.J. Mudd's SRPMs included an SPF option. Is this option still valid/meaningful/useful in latest postfix versions? All the best, Nick
Re: MAIL FROM validiity
> Le 14 mars 2016 à 22:24, Sebastian Nielsen a écrit : > > SPF and DKIM is mail tools to prevent spoofing of non-local domains. > OP was out after tools to prevent local spoofing. > > One is for example: > 1: reject_sender_login_mismatch > 2: Other is a check_sender_access table containing "yourdomain.com: > permit_sasl_authenticated, reject". > 3: Another one is reject_unlisted_sender > > Of course, all those tools perform a completely different check and they all > can be used in unison. > 1 would prevent all mismatches between login names and MAIL FROM. However, it > won't prevent a unauthenticated client from sending a spoofed mail from a > local mailbox X to a local mailbox Y (I think the tables can be setup to > enforce this for unauthenticated clients too however). > 2: This prevents authenticated senders from sending outside the domain the > server is authorative for, but also prevents any unauthenticated client from > spoofing the MAIL FROM as a local mailbox when sending mail that is targeted > to a local mailbox. > 3: This is a tool that prevents all unknown local adresses to be used as a > sender. > > > Another good thing with check_sender_access as described in 2 is that this > can be used along with IP-based authentication (permit_mynetworks) to enforce > so only specific domains can be used, and those domains cannot be used as a > sender by unauthorized individuals, so even if you have SASL disabled, you > can still enforce certain domains. > With 2, how can you deal with machines which are sending mail but can't use the authentication ? If the table contains youdomain.com: permit_mynetworks, permit_sasl_authenticated, reject then anybody connected to the network can send a mail without being authenticated, only members from outside must be authenticated. And if a hacker has the login/password from one of our users, he can use our system to send spam Thanks -- Pascal
[OT] (was Re: Is /usr/bin/mail a link to sendmail/postfix)
In message <76865be6-8041-498d-91ae-36ef80c91...@kreme.com> "@lbutlr" writes: > > On Mar 13, 2016, at 9:06 AM, Robert Chalmers wrote: > > Nice hardware, but the software is really recycled FreeBSD. say what? > > This should not be news. One of the reasons I chose FreeBSD for my > servers was because I wouldn't have to change modes between OS X and > my servers. > > -- > Marriages made in heaven are not exported. Perhaps being pedantic again, but ... oh another squirrel ... The kernel has its roots in Mach (back in the late 1980s) but doesn't closely resemble Mach since long ago. The utilities are a branch from FreeBSD a very long time ago and they do track and merge in some changes but there are a lot of differences. FreeBSD also uses code that originates from places other than BSD - for example, see src/contrib and src/sys/contrib. There are some things you can get from FreeBSD ports collection to make your Mac and FreeBSD systems look even more similar. And of course Apple's window system is unique and in no way related to the Xorg or xf86 or original MIT flavors of X-windows that FreeBSD has used over time. Yes there still is a lot of similarity, but recycled version ... No - just a quick path to get closer to posix in the utilities with least restrictive licensing. Curtis
Re: Mails in active queue are never tried to be sent
Thanks a lot Wietse... here they are: Mar 13 06:37:24 serverA postfix/qmgr[19283]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 06:47:22 serverA postfix/error[17720]: 80844160065: to=, relay=none, delay=235656, delays=235058/597/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error) Mar 13 07:57:24 serverA postfix/qmgr[19283]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 08:07:13 serverA postfix/error[22030]: 80844160065: to=, relay=none, delay=240447, delays=239858/590/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error) Mar 13 09:17:29 serverA postfix/qmgr[23376]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 09:27:25 serverA postfix/error[26367]: 80844160065: to=, relay=none, delay=245259, delays=244663/596/0/0.02, dsn=4.3.0, status=deferred (unknown mail transport error) Mar 13 10:37:29 serverA postfix/qmgr[23376]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 10:47:29 serverA postfix/qmgr[23376]: fatal: 80844160065: timeout receiving delivery status from transport: smtp Mar 13 10:47:33 serverA postfix/qmgr[30730]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 10:57:33 serverA postfix/qmgr[30730]: fatal: 80844160065: timeout receiving delivery status from transport: smtp Mar 13 10:57:35 serverA postfix/qmgr[31274]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 11:07:35 serverA postfix/qmgr[31274]: fatal: 80844160065: timeout receiving delivery status from transport: smtp Mar 13 11:07:36 serverA postfix/qmgr[31830]: 80844160065: skipped, still being delivered Mar 13 11:08:35 serverA postfix/qmgr[31830]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 11:18:35 serverA postfix/qmgr[31830]: fatal: 80844160065: timeout receiving delivery status from transport: smtp Mar 13 11:18:37 serverA postfix/qmgr[32431]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 11:28:37 serverA postfix/qmgr[32431]: fatal: 80844160065: timeout receiving delivery status from transport: smtp Mar 13 11:28:38 serverA postfix/qmgr[507]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 11:38:38 serverA postfix/qmgr[507]: fatal: 80844160065: timeout receiving delivery status from transport: smtp Mar 13 11:38:39 serverA postfix/qmgr[1051]: 80844160065: skipped, still being delivered Mar 13 11:39:44 serverA postfix/qmgr[1051]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 11:39:44 serverA postfix/smtp[1061]: 80844160065: host mailclean.destination.xyz[DDD.DDD.DDD.DDD] refused to talk to me: 450 4.3.2 try again later Mar 13 11:49:37 serverA postfix/error[1643]: 80844160065: to=, relay=none, delay=253791, delays=253198/593/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error) Mar 13 12:57:46 serverA postfix/qmgr[1798]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 13:07:33 serverA postfix/error[5936]: 80844160065: to=, relay=none, delay=258467, delays=257880/588/0/0.02, dsn=4.3.0, status=deferred (unknown mail transport error) Mar 13 14:17:49 serverA postfix/qmgr[6744]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 14:27:49 serverA postfix/qmgr[6744]: fatal: 80844160065: timeout receiving delivery status from transport: smtp Mar 13 14:27:52 serverA postfix/qmgr[10293]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 14:37:52 serverA postfix/qmgr[10293]: fatal: 80844160065: timeout receiving delivery status from transport: smtp Mar 13 14:37:53 serverA postfix/qmgr[10838]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 14:47:49 serverA postfix/error[11375]: 80844160065: to=, relay=none, delay=264483, delays=263887/596/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error) Mar 13 15:57:53 serverA postfix/qmgr[10838]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 16:07:50 serverA postfix/error[15711]: 80844160065: to=, relay=none, delay=269284, delays=268687/598/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error) Mar 13 17:17:53 serverA postfix/qmgr[10838]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 17:27:39 serverA postfix/error[20030]: 80844160065: to=, relay=none, delay=274073, delays=273487/585/0/0.02, dsn=4.3.0, status=deferred (unknown mail transport error) Mar 13 18:37:53 serverA postfix/qmgr[10838]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 18:47:28 serverA postfix/error[24370]: 80844160065: to=, relay=none, delay=278862, delays=278287/575/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error) Mar 13 19:57:55 serverA postfix/qmgr[24640]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 20:07:54 serverA postfix/error[28732]: 80844160065: to=, relay=none, delay=283688, delays=283089/599/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error) Mar 13 21:18:02 serverA postfix/qmgr[29531]: 80844160065: from=, size=64276, nrcpt=1 (
Re: Mails in active queue are never tried to be sent
By the way, Wietse... nothing is running chrooted in master.cf David. On Tue, 3/15/16, Pedro David Marco wrote: Subject: Re: Mails in active queue are never tried to be sent To: "Postfix users" Date: Tuesday, March 15, 2016, 7:50 PM Thanks a lot Wietse... here they are: Mar 13 06:37:24 serverA postfix/qmgr[19283]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 06:47:22 serverA postfix/error[17720]: 80844160065: to=, relay=none, delay=235656, delays=235058/597/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error) Mar 13 07:57:24 serverA postfix/qmgr[19283]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 08:07:13 serverA postfix/error[22030]: 80844160065: to=, relay=none, delay=240447, delays=239858/590/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error) Mar 13 09:17:29 serverA postfix/qmgr[23376]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 09:27:25 serverA postfix/error[26367]: 80844160065: to=, relay=none, delay=245259, delays=244663/596/0/0.02, dsn=4.3.0, status=deferred (unknown mail transport error) Mar 13 10:37:29 serverA postfix/qmgr[23376]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 10:47:29 serverA postfix/qmgr[23376]: fatal: 80844160065: timeout receiving delivery status from transport: smtp Mar 13 10:47:33 serverA postfix/qmgr[30730]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 10:57:33 serverA postfix/qmgr[30730]: fatal: 80844160065: timeout receiving delivery status from transport: smtp Mar 13 10:57:35 serverA postfix/qmgr[31274]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 11:07:35 serverA postfix/qmgr[31274]: fatal: 80844160065: timeout receiving delivery status from transport: smtp Mar 13 11:07:36 serverA postfix/qmgr[31830]: 80844160065: skipped, still being delivered Mar 13 11:08:35 serverA postfix/qmgr[31830]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 11:18:35 serverA postfix/qmgr[31830]: fatal: 80844160065: timeout receiving delivery status from transport: smtp Mar 13 11:18:37 serverA postfix/qmgr[32431]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 11:28:37 serverA postfix/qmgr[32431]: fatal: 80844160065: timeout receiving delivery status from transport: smtp Mar 13 11:28:38 serverA postfix/qmgr[507]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 11:38:38 serverA postfix/qmgr[507]: fatal: 80844160065: timeout receiving delivery status from transport: smtp Mar 13 11:38:39 serverA postfix/qmgr[1051]: 80844160065: skipped, still being delivered Mar 13 11:39:44 serverA postfix/qmgr[1051]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 11:39:44 serverA postfix/smtp[1061]: 80844160065: host mailclean.destination.xyz[DDD.DDD.DDD.DDD] refused to talk to me: 450 4.3.2 try again later Mar 13 11:49:37 serverA postfix/error[1643]: 80844160065: to=, relay=none, delay=253791, delays=253198/593/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error) Mar 13 12:57:46 serverA postfix/qmgr[1798]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 13:07:33 serverA postfix/error[5936]: 80844160065: to=, relay=none, delay=258467, delays=257880/588/0/0.02, dsn=4.3.0, status=deferred (unknown mail transport error) Mar 13 14:17:49 serverA postfix/qmgr[6744]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 14:27:49 serverA postfix/qmgr[6744]: fatal: 80844160065: timeout receiving delivery status from transport: smtp Mar 13 14:27:52 serverA postfix/qmgr[10293]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 14:37:52 serverA postfix/qmgr[10293]: fatal: 80844160065: timeout receiving delivery status from transport: smtp Mar 13 14:37:53 serverA postfix/qmgr[10838]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 14:47:49 serverA postfix/error[11375]: 80844160065: to=, relay=none, delay=264483, delays=263887/596/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error) Mar 13 15:57:53 serverA postfix/qmgr[10838]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 16:07:50 serverA postfix/error[15711]: 80844160065: to=, relay=none, delay=269284, delays=268687/598/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error) Mar 13 17:17:53 serverA postfix/qmgr[10838]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 17:27:39 serverA postfix/error[20030]: 80844160065: to=, relay=none, delay=274073, delays=273487/585/0/0.02, dsn=4.3.0, status=deferred (unknown mail transport error) Mar 13 18:37:53 serverA postfix/qmgr[10838]: 80844160065: from=, size=64276, nrcpt=1 (queue active) Mar 13 18:47:28 serverA postfix/error[24370]: 80844160065: to=, relay=none, delay=278862, delays=278287/575/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error)
Re: RHEL / CentOS 7 RPMs
On 16/03/16 03:16, Nikolaos Milas wrote: > On 15/3/2016 11:44 πμ, Nikolaos Milas wrote: > >> So, it seems that initially the above compilation options are >> disabled. Right? >> > > To answer my own question, in fact, it's the other way round! For example: > >%bcond_without ldap > > means ldap is enabled by default! Correct, they're all enabled. >> And a second question: Could we build the package as postfix (not >> postfix3) so as to be able to replace the default OS postfix package >> on installation (automatic upgrade)? The package was named that specifically to avoid automatically updating people who were using my older (2.11 and previous) packages. These 3.x packages have dynamic map support so you have to install (for example) postfix3-pcre in order to get pcre support and postfix3-mysql to get mysql support, before all the db types had installed in one package (the advantage with the new way is you don't have to install mysql libs if you don't want mysql support, etc). If I had left the package named postfix (without the 3) then people running my old postfix 2.11 package would have been automatically upgraded, but in the process they would have lost support for all the db types (because they would not have postfix-foo installed), thus potentially breaking their system on an automatic upgrade. To avoid doing that the package was named postfix3. You are, of course, wecome to rebuild it as postfix if you want. You can upgrade in place in this way: yum --enablerepo=gf-testing shell remove postfix install postfix3 postfix3-pcre ... run ...then yum will do all of the above as a single step and upgrade from the system postfix package to the posfix3 packages. > By the way, it seems to me that an important option to add to the spec > file is Dovecot SASL (used quite extensively these days). Dovecot SASL is in the package and works: [root@el7-test postfix]# postconf -a cyrus dovecot > So, I "merged" some stuff from S. J. Mudd's RPMs and the build rolled > fine. (Note however that I did not try to build without sasl support.) All you're doing here is doubling up on -DUSE_SASL_AUTH and changing hard-coded defaults to dovecot. Leave well enough alone and put your dovecot SASL settings in main.cf where they belong. Peter
Re: Mails in active queue are never tried to be sent
Pedro David Marco: > Mar 13 06:47:22 serverA postfix/error[17720]: 80844160065: > to=, > relay=none, delay=235656, delays=235058/597/0/0.01, > dsn=4.3.0, status=deferred (unknown mail transport error) Well there is your problem. For follow-up investigation see: http://www.postfix.org/DEBUG_README.html#logging Wietse
Re: Mails in active queue are never tried to be sent
Pedro David Marco: > Thanks a lot Wietse... > > here they are: Your Postfix SMTP clients are hanging (resulting in watchdog timeouts). Are you running in a VM, or some other hosting setup? Wietse > Mar 13 10:47:29 serverA postfix/qmgr[23376]: fatal: 80844160065: timeout > receiving delivery status from transport: smtp > Mar 13 10:57:33 serverA postfix/qmgr[30730]: fatal: 80844160065: timeout > receiving delivery status from transport: smtp > Mar 13 11:07:35 serverA postfix/qmgr[31274]: fatal: 80844160065: timeout > receiving delivery status from transport: smtp > Mar 13 11:18:35 serverA postfix/qmgr[31830]: fatal: 80844160065: timeout > receiving delivery status from transport: smtp > Mar 13 11:28:37 serverA postfix/qmgr[32431]: fatal: 80844160065: timeout > receiving delivery status from transport: smtp > Mar 13 11:38:38 serverA postfix/qmgr[507]: fatal: 80844160065: timeout > receiving delivery status from transport: smtp > Mar 13 14:27:49 serverA postfix/qmgr[6744]: fatal: 80844160065: timeout > receiving delivery status from transport: smtp > Mar 13 14:37:52 serverA postfix/qmgr[10293]: fatal: 80844160065: timeout > receiving delivery status from transport: smtp > Mar 13 08:07:13 serverA postfix/qmgr[19283]: warning: transport smtp failure > -- see a previous warning/fatal/panic logfile record for the problem > description > Mar 13 08:32:23 serverA postfix/smtp[22279]: fatal: watchdog timeout > Mar 13 08:32:24 serverA postfix/qmgr[19283]: fatal: A3FD8160067: timeout > receiving delivery status from transport: smtp > Mar 13 08:42:20 serverA postfix/smtp[22278]: fatal: watchdog timeout > Mar 13 08:42:21 serverA postfix/qmgr[23376]: warning: transport smtp failure > -- see a previous warning/fatal/panic logfile record for the problem > description > Mar 13 09:27:24 serverA postfix/smtp[25826]: fatal: watchdog timeout > Mar 13 09:27:25 serverA postfix/qmgr[23376]: warning: transport smtp failure > -- see a previous warning/fatal/panic logfile record for the problem > description > Mar 13 10:02:21 serverA postfix/smtp[27627]: fatal: watchdog timeout > Mar 13 10:02:22 serverA postfix/qmgr[23376]: warning: transport smtp failure > -- see a previous warning/fatal/panic logfile record for the problem > description > Mar 13 10:47:28 serverA postfix/smtp[28796]: fatal: watchdog timeout > Mar 13 10:47:29 serverA postfix/qmgr[23376]: fatal: 80844160065: timeout > receiving delivery status from transport: smtp > Mar 13 10:57:33 serverA postfix/qmgr[30730]: fatal: 80844160065: timeout > receiving delivery status from transport: smtp > Mar 13 10:57:33 serverA postfix/smtp[29817]: fatal: watchdog timeout > Mar 13 11:07:35 serverA postfix/qmgr[31274]: fatal: 80844160065: timeout > receiving delivery status from transport: smtp > Mar 13 11:07:35 serverA postfix/smtp[30750]: fatal: watchdog timeout > Mar 13 11:18:35 serverA postfix/smtp[31462]: fatal: watchdog timeout > Mar 13 11:18:35 serverA postfix/qmgr[31830]: fatal: 80844160065: timeout > receiving delivery status from transport: smtp > Mar 13 11:22:32 serverA postfix/smtp[31461]: fatal: watchdog timeout > Mar 13 11:28:37 serverA postfix/smtp[31456]: fatal: watchdog timeout > Mar 13 11:28:37 serverA postfix/qmgr[32431]: fatal: 80844160065: timeout > receiving delivery status from transport: smtp > Mar 13 11:32:35 serverA postfix/smtp[31458]: fatal: watchdog timeout > Mar 13 11:38:38 serverA postfix/qmgr[507]: fatal: 80844160065: timeout > receiving delivery status from transport: smtp > Mar 13 11:38:38 serverA postfix/smtp[32617]: fatal: watchdog timeout > Mar 13 11:42:42 serverA postfix/smtp[32133]: fatal: watchdog timeout > Mar 13 11:49:36 serverA postfix/smtp[1061]: fatal: watchdog timeout > Mar 13 11:49:37 serverA postfix/qmgr[1051]: warning: transport smtp failure > -- see a previous warning/fatal/panic logfile record for the problem > description > Mar 13 11:52:44 serverA postfix/smtp[32674]: fatal: watchdog timeout > Mar 13 11:52:45 serverA postfix/qmgr[1051]: fatal: A3FD8160067: timeout > receiving delivery status from transport: smtp
Re: RHEL / CentOS 7 RPMs
On 16/03/16 03:16, Nikolaos Milas wrote: > A final query: S.J. Mudd's SRPMs included an SPF option. Is this option > still valid/meaningful/useful in latest postfix versions? Missed the above question before. Postfix does not have any built-in support for SPF. A quick look at Mudd's RPM shows that it's a patched-in feature and is marked as experimental. I will not be supporting that patch mainly because SPF support can be added to postfix in many other ways (policy daemon, milter, content filter, etc), but also because I keep the patches in my RPMs to a minimum and try to have a "mostly pure" build of postfix. You are welcome to look at my spec file and see what patches are added, just about all of them originated from Fedora, were passed to Red Hat, and are kept for compatibility and upgrade-ability from the stock Red Hat and CentOS RPMs. Peter
Transport map search ordering
Hello, I'm trying to select a transport to use based on the recipient domain in a transport_map hash file, but a lower priority regexp that matches the full recipient address is overriding the higher priority domain-level match. Based on the postconf transport_maps documentation, "Tables will be searched in the specified order until a match is found." Within each table the search order is specified in the transport(5) docs. But it appears that all tables are searched for a match based on the full address first, before searching any of them for a domain. Does this sound familiar to anyone or are there any suggestions for rectifying? Perhaps I'm misunderstanding the expected behavior or have configured something incorrectly. Any insight would be appreciated. Simplified example info, with postfix-2.10.1-6.el7.x86_64: /etc/postfix/main.cf: transport_maps = hash:/etc/postfix/transport,hash:/etc/postfix/transport2 /etc/postfix/transport: example.com transport1: /etc/postfix/transport2: u...@example.com transport2: example2.com transport3: Log for email sent to u...@example.com: Mar 15 20:19:03 mx postfix/trivial-rewrite[3441]: maps_find: transport_maps: hash:/etc/postfix/transport2(0,lock|no_regsub|fold_fix): u...@example.com = transport2: Log for email sent to u...@example2.com: Mar 15 20:29:54 mx postfix/trivial-rewrite[3862]: maps_find: transport_maps: u...@example2.com: not found Mar 15 20:29:54 mx postfix/trivial-rewrite[3862]: maps_find: transport_maps: hash:/etc/postfix/transport2(0,lock|no_regsub|fold_fix): example2.com = transport3: Thanks, Jason
Re: RHEL / CentOS 7 RPMs
On 15/3/2016 9:26 μμ, Peter wrote: All you're doing here is doubling up on -DUSE_SASL_AUTH and changing hard-coded defaults to dovecot. Leave well enough alone and put your dovecot SASL settings in main.cf where they belong. Sorry for my ignorance, Thank you very much for all the clarifications and valuable information! All the best, Nick
Re: Transport map search ordering
The text under "TABLE SEARCH ORDER" describes that the search order is first user+extension@domain, second user@domain, third domain, etc. The text "Tables will be searched in the specified order until a match is found" means that it first searches all tables for user+extension@domain, second all tables for user@domain, third all tables for domain, and so on. If you must match a domain before an address in that domain, then you would need to use one regexp or pcre-based table for the whole lot. Those tables are searched with the complete address only, and the first pattern is matched first. /@example\.com$/reply for high-priority domain /^user@example\.com$/ reply for specific user. Unless you have thousands of transport_maps entries, the performance should be OK. Wietse
