recent onset of "zero result in delay template conversion of parameter" warnings in postfix 3.6 logs?
running postconf mail_version mail_version = 3.6.0 I've recently started seeing in logs postfix/bounce[10732]: warning: [built-in]: zero result in delay template conversion of parameter "maximal_queue_lifetime_days" postfix/bounce[10732]: warning: please reduce time unit "days" of "maximal_queue_lifetime_days" in delay template postfix/bounce[10732]: warning: for instructions see the bounce(5) manual" NOT fatal. Not clear if bounce queues are affected. I've never noticed these messages. I checked logs back ~ a month, and have only seen them in the last few days. The messages appear to originate at bounce/bounce_template.c ... /* bounce_template_lookup - lookup $name value */ static const char *bounce_template_lookup( ... I've never touched the bounce/delay templates, and, atm, unclear why these suddenly started appearing. Has there been a change in function, default config, etc that may be causal? Or any hint/pointer as to what might be? Other than a WARNING in logs, are there any expected effects/problems due to this?
Re: recent onset of "zero result in delay template conversion of parameter" warnings in postfix 3.6 logs?
PGNet Dev: > running > > postconf mail_version > mail_version = 3.6.0 > > I've recently started seeing in logs > > postfix/bounce[10732]: warning: [built-in]: zero result in delay > template conversion of parameter "maximal_queue_lifetime_days" > postfix/bounce[10732]: warning: please reduce time unit "days" of > "maximal_queue_lifetime_days" in delay template You changed the maximal_queue_lifetime in main.cf, or (less likely) your Postfix distributor changed the default value to less than a day. If you change it from days to hours, update the template to specify maximal_queue_lifetime_hours. Wietse
Re: recent onset of "zero result in delay template conversion of parameter" warnings in postfix 3.6 logs?
On 5/20/21 9:20 AM, Wietse Venema wrote: PGNet Dev: running postconf mail_version mail_version = 3.6.0 I've recently started seeing in logs postfix/bounce[10732]: warning: [built-in]: zero result in delay template conversion of parameter "maximal_queue_lifetime_days" postfix/bounce[10732]: warning: please reduce time unit "days" of "maximal_queue_lifetime_days" in delay template You changed the maximal_queue_lifetime in main.cf, or (less likely) your Postfix distributor changed the default value to less than a day. If you change it from days to hours, update the template to specify maximal_queue_lifetime_hours. Wietse Noted. I'll need to poke around @ distro/pkg, as postconf -t | grep maximal_queue_lifetime It will be retried until it is $maximal_queue_lifetime_days day(s) old. postconf -d maximal_queue_lifetime maximal_queue_lifetime = 5d postconf -n maximal_queue_lifetime maximal_queue_lifetime = 1d Thanks.
Re: Submission behind haproxy, TLS issues
For archival purposes to anyone reading this in the future. The answer i
was looking for, and solution i ended up using to this problem:
1) On the haproxy.example.com server, i used certbot to issue a cert to
that domain.
2) I installed a SSH key on haproxy.example.com and copied to
authorized_keys on submission.example.com. (for passwordless rsync)
3) For auto renew i made a bash script on haproxy.example.com that runs
certbot renew and then rsync the cert directory in /live/ to
submission.example.com. Placed the script to run in crontab. Manually
run script once to get initial keys to back servers.
4) On submission.example.com servers add/change the following in
master.cf
submission inet n - n - - smtpd
-o { your normal options }
-o smtpd_upstream_proxy_protocol=haproxy
-o
smtpd_tls_cert_file=/etc/letsencrypt/live/haproxy.example.com/fullchain.pem
-o
smtpd_tls_key_file=/etc/letsencrypt/live/haproxy.example.com/privkey.pem
That's it, works for TLS from [Email Client] -> [haproxy] -> [submission
server] without client giving encryption warnings.
Question about retaining mail authenticated user
Good afternoon, I have a Postfix machine that accepts outgoing mail when MUA has authenticated. Later I send that email to Amavis in order to get tagged or signed (with DKIM and Altermime). When that mails come back from Amavis (in the Postfix smtpd instance where amavis processed mail is delivered) I would needed to know which authenticated user has delivered the mail to this mail machine, in order to be able to call a FILTER action from a policy (in this Postfix smtpd instance for receiving mail processed by Amavisd). The problem is that coming mail from Amavis, does not auth so in the policy elements I don't have the sasl_username. Could I achieve in some manner, to know the sasl authenticated user in the smtpd instance for mail coming from Amavis?. Could I do perhaps with some policy element, try to later relate an incoming mail (where I see sasl_username) with that same email in the instance that comes from Amavis for being able to know which FILTER action should I use?. I know there's a possibility of using smtpd sasl authenticated header but I don't really trust in that way... Any ideas? :) Best regards, -- Egoitz Aurrekoetxea
Can't disable mx lookup with square brackets in transport map
Hi List! I want to use native SMTP host lookup instead of DNS, but only for *some* domains. >From `man 5 transport`: > and disable MX (mail ex‐changer) DNS lookups with [host] or [host]:port. I tried it, but according to postfix logs, it's still resolving it using DNS. If I replace the name within square brackets with a numeric ip address, then the mail is delivered. `/etc/postfix/transport` .lan smtp:[somehost] `/etc/postfix/main.cf` transport_maps = hash:/etc/postfix/transport _ [root@dexp postfix]# getent hosts somehost 1.2.3.4 somehost [root@dexp postfix]# mailx -s testsubject r...@other.lan , relay=none, delay=0.4, delays=0.14/0.02/0.23/0, dsn=5.4.4, status=bounced (Host or domain name not found. Name service error for name=somehost type=A: Host not found) My postfix has version 3.5.6. Thank you.
Re: Can't disable mx lookup with square brackets in transport map
On 5/20/2021 12:38 PM, basini...@gmail.com wrote: Hi List! I want to use native SMTP host lookup instead of DNS, but only for *some* domains. From `man 5 transport`: and disable MX (mail ex‐changer) DNS lookups with [host] or [host]:port. I tried it, but according to postfix logs, it's still resolving it using DNS. If I replace the name within square brackets with a numeric ip address, then the mail is delivered. `/etc/postfix/transport` .lan smtp:[somehost] `/etc/postfix/main.cf` transport_maps = hash:/etc/postfix/transport _ [root@dexp postfix]# getent hosts somehost 1.2.3.4 somehost [root@dexp postfix]# mailx -s testsubject r...@other.lan , relay=none, delay=0.4, delays=0.14/0.02/0.23/0, dsn=5.4.4, status=bounced (Host or domain name not found. Name service error for name=somehost type=A: Host not found) My postfix has version 3.5.6. Thank you. As the docs say, the brackets disable MX lookups, not DNS lookups. Sounds like you should read http://www.postfix.org/postconf.5.html#smtp_host_lookup and probably use "dns, native" -- Noel Jones
Re: Can't disable mx lookup with square brackets in transport map
basini...@gmail.com: > `/etc/postfix/transport` > .lan smtp:[somehost] This disables MX lookups before A lookups. This DOES NOT disable DNS lookups. > May 20 20:27:25 dexp.lan postfix/smtp[226399]: 4E537CEFD1: > to=, relay=none, delay=0.4, delays=0.14/0.02/0.23/0, > dsn=5.4.4, status=bounced (Host or domain name not found. Name service error > for name=somehost type=A: Host not found) As documented, Postfix looked up the A record for somehost. If you want to support names in /etc/hosts, use smtp_host_lookup. Wietse smtp_host_lookup (default: dns) What mechanisms the Postfix SMTP client uses to look up a host's IP address. This parameter is ignored when DNS lookups are disabled (see: disable_dns_lookups and smtp_dns_support_level). The "dns" mechanism is always tried before "native" if both are listed. Specify one of the following: dnsHosts can be found in the DNS (preferred). native Use the native naming service only (nsswitch.conf, or equivalent mechanism). dns, native Use the native service for hosts not found in the DNS. This feature is available in Postfix 2.1 and later.
Re: Can't disable mx lookup with square brackets in transport map
On Thu, May 20, 2021 at 12:52:38PM -0500, Noel Jones wrote: > As the docs say, the brackets disable MX lookups, not DNS lookups. > > Sounds like you should read > http://www.postfix.org/postconf.5.html#smtp_host_lookup > and probably use "dns, native" Thanks Noel, that's the right answer. I just want add the below caution: Care is appropriate when native lookups are desired for just a particular destination, with most (or at least some) mail delivered to the public Internet. In such cases, the use of "dns, native" or just "native" should be specified in master.cf for a custom smtp transport that is dedicated for non-DNS deliveries, with the default of "dns" alone continuting to be used for mail going out the Internet at large. -- Viktor.
Re: Question about retaining mail authenticated user
Egoitz Aurrekoetxea: > Good afternoon, > > I have a Postfix machine that accepts outgoing mail when MUA has > authenticated. Later I send that email to Amavis in order to get tagged or > signed (with DKIM and Altermime). When that mails come back from Amavis > (in the Postfix smtpd instance where amavis processed mail is delivered) I > would needed to know which authenticated user has delivered the mail to > this mail machine, in order to be able to call a FILTER action from a > policy (in this Postfix smtpd instance for receiving mail processed by > Amavisd). The problem is that coming mail from Amavis, does not auth so in > the policy elements I don't have the sasl_username. > > Could I achieve in some manner, to know the sasl authenticated user in the > smtpd instance for mail coming from Amavis?. Could I do perhaps with some > policy element, try to later relate an incoming mail (where I see > sasl_username) with that same email in the instance that comes from Amavis > for being able to know which FILTER action should I use?. Indeed, a policy that replies with PREPEND headername: headervalue would create a channel for this information to propagate through an external content filter. Of course the header can leak and should not contain secrets. > I know there's a possibility of using smtpd sasl authenticated header but I > don't really trust in that way... Oh, because the client might provide a fake one? Wietse > Any ideas? :) > > Best regards, > > -- > Egoitz Aurrekoetxea
Re: Can't disable mx lookup with square brackets in transport map
Thanks Viktor. So to add this "custom smtp transport" do I need to add a section in main.cf just like "smtp unix", but with a custom "service type" column and the additional option `-o smtp_host_lookup=native`? On 20.05.2021 21:01, Viktor Dukhovni wrote: > On Thu, May 20, 2021 at 12:52:38PM -0500, Noel Jones wrote: > >> As the docs say, the brackets disable MX lookups, not DNS lookups. >> >> Sounds like you should read >> http://www.postfix.org/postconf.5.html#smtp_host_lookup >> and probably use "dns, native" > > Thanks Noel, that's the right answer. I just want add the below > caution: > > Care is appropriate when native lookups are desired for just > a particular destination, with most (or at least some) mail > delivered to the public Internet. > > In such cases, the use of "dns, native" or just "native" should be > specified in master.cf for a custom smtp transport that is dedicated > for non-DNS deliveries, with the default of "dns" alone continuting > to be used for mail going out the Internet at large. >
Re: Can't disable mx lookup with square brackets in transport map
On 20.05.21 21:18, basini...@gmail.com wrote: So to add this "custom smtp transport" do I need to add a section in main.cf just like "smtp unix", but with a custom "service type" column and the additional option `-o smtp_host_lookup=native`? you can as well put IP address into the brackets. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux - It's now safe to turn on your computer. Linux - Teraz mozete pocitac bez obav zapnut.
Re: Can't disable mx lookup with square brackets in transport map
On Thu, May 20, 2021 at 09:18:56PM +0300, basini...@gmail.com wrote: > Thanks Viktor. > > So to add this "custom smtp transport" do I need to add a section in > main.cf just like "smtp unix", but with a custom "service type" column > and the additional option `-o smtp_host_lookup=native`? That'd master.cf, and a custom service name. Right now you typicall have: smtp unix ... smtp relay unix ... smtp -o ... you would add: smtp-nondns unix ... smtp -o smtp_host_lookup=native -o disable_dns_lookups=yes Then of course in transport(5): example.com smtp-nondns:[somehost] -- Viktor.
Re: Question about retaining mail authenticated user
Hi Wietse!! Thanks a lot for your time. I answer below :) I’m the same person behind ego...@gmail.com. > El 20 may 2021, a las 20:02, Wietse Venema escribió: > > > > Egoitz Aurrekoetxea: >> Good afternoon, >> >> I have a Postfix machine that accepts outgoing mail when MUA has >> authenticated. Later I send that email to Amavis in order to get tagged or >> signed (with DKIM and Altermime). When that mails come back from Amavis >> (in the Postfix smtpd instance where amavis processed mail is delivered) I >> would needed to know which authenticated user has delivered the mail to >> this mail machine, in order to be able to call a FILTER action from a >> policy (in this Postfix smtpd instance for receiving mail processed by >> Amavisd). The problem is that coming mail from Amavis, does not auth so in >> the policy elements I don't have the sasl_username. >> >> Could I achieve in some manner, to know the sasl authenticated user in the >> smtpd instance for mail coming from Amavis?. Could I do perhaps with some >> policy element, try to later relate an incoming mail (where I see >> sasl_username) with that same email in the instance that comes from Amavis >> for being able to know which FILTER action should I use?. > > Indeed, a policy that replies with > >PREPEND headername: headervalue > > would create a channel for this information to propagate through > an external content filter. Of course the header can leak and > should not contain secrets. I see. This could be a solution because I could create a not known header which I could remove in the smtpd instance that comes from Amavis. And with that header I could select the needed FILTER. I was thinking too in some sort of policy parameter like instance, which you could use at different dialogue stages (rcpt, end-of-data...) for knowing you are receiving params of the same message. In this case, not for different stages but something similar, for different smtpd services of the same Postfix system. Sometimes you need to use two FILTER actions for a mail, but you can’t obviously in the same smtpd service. The problem of using two smtpd instances is that in the second one, you loose info like sasl_user as a policy param (unless something as Xclient could be used between them). > >> I know there's a possibility of using smtpd sasl authenticated header but I >> don't really trust in that way... > > Oh, because the client might provide a fake one? Yep. We use dedicated ip addresses for each customer (just for providing a good service, of course not for allowing outgoing spam) and we do it with FILTER and the corresponding smtp client instance. So, we were using SASL auth domain for routing each customer mail properly. A standard header, could be faked by a MUA or script... so for this purpose, a standard known header, is not the best idea I assume... Thanks a lot for your time Wietse. I’ll check the possibility of using a custom header later removed. Best regards, > >Wietse > >> Any ideas? :) >> >> Best regards, >> >> -- >> Egoitz Aurrekoetxea
