[pfx] Re: SASL reject force disconnect
John Hill via Postfix-users:
> I learn something every time I read this group, when I can keep up with
> the conversation!
>
> I had auth on ports I did not need. I use auth on submission port 587,
> for users access.
>
> I do get a boat load of failed login attempts on 587. Funny how a China,
> US, Argentina, you name it, hosts, will try the same failed username
> password at nearly the same time.
>
> Small world.
>
> I use Fail2Ban to block the failed IP. The script writes it into the
> nftables table immediately.
>
> I think this keeps Postfix waiting and times out, not a big deal. Is
> there a cli that my bash script could force disconnect the ip from Postfix?
>
> I did search the man page and the docs, sorry if I missed it.
On port 587? setting "smtpd_hard_error_limit=1" might do it.
masster.cf:
submission .. .. .. .. .. .. .. smtpd
-o { smtpd_hard_error_limit = 1 }
...other -o options...
You need to "postfix reload" after editing master.cf,
This assumes that a good user makes no mistakes.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: disable authentication on port 25
Northwind via Postfix-users: > Hello, > > since my smtp instance is postscreen as showing the follow, > > smtp inet n - y - 1 postscreen > > > How can I disable authentication on port 25 then? > > I know if the smtp instance is smtpd, this option should work: > >-o smtpd_sasl_auth_enable=no As documnented somewhere, postscreen never announces AUTH support. It must therefore not be used on the submission/smtps ports. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS for SMTP Outbound -- Only One tlsproxy
Greg Sims via Postfix-users: > We see conn_use about 24% of the time: But none of the sessions shown in your message have that. Do they also have multiple-of-5-second type 'c' delays? Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Dedicated servers for Address Verification Probes
Pedro David Marco via Postfix-users: > Hi all, > is it possible to have several Postfix instances to use a centralized > Postfix server for address verification probes when this centralized > server is NOT an MDA but a relay to external MDAs? You can specify address_verify_relayhost and the like, but that will just tell you if the relayhost accepts the probe. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: how disable DSN pipe]
You have been perfectly clear. As outlined in DSN_README, the RFC does not support a way to selectively disable SUCCESS notification. Postfix is not just a bunch of random hacks thrown together. You are free to use a different mail system. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: how disable DSN pipe
Aleksandr Kolesnikov via Postfix-users: > if the user requests a DSN, he receives a delivery message via the ... > how to prohibit the sending of such DSN? Perhaps: https://www.postfix.org/DSN_README.html Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Strengthen email system security
Wietse Venema via Postfix-users: > Northwind via Postfix-users: > > Hello list, > > > > In the last two days, my mail system (small size) met attacks. > > > > mail.log shows a lot of this stuff: > > > > May 23 06:24:29 mx postfix/smtpd[2655149]: warning: > > unknown[194.169.175.17]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 > > This just wastes a few CPU cycles and file system space. > > > My questions are: > > 1. what's the purpose of this kind of attack? Brute force password > > cracking, or DDoS? > > They want to use your machine to send spam to the Internet. > > > 2. How to strengthen email system security to stop this? > > Don't accept mail from home networks. For example, use "reject_dbl_client Typo: this should be reject_rbl_client. > zen.spamhaus.org". For this you must use your own DNS resolver, > not the DNSresolver from your ISP. > > Wietse > ___ > 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: Strengthen email system security
Northwind via Postfix-users: > Hello list, > > In the last two days, my mail system (small size) met attacks. > > mail.log shows a lot of this stuff: > > May 23 06:24:29 mx postfix/smtpd[2655149]: warning: > unknown[194.169.175.17]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 This just wastes a few CPU cycles and file system space. > My questions are: > 1. what's the purpose of this kind of attack? Brute force password > cracking, or DDoS? They want to use your machine to send spam to the Internet. > 2. How to strengthen email system security to stop this? Don't accept mail from home networks. For example, use "reject_dbl_client zen.spamhaus.org". For this you must use your own DNS resolver, not the DNSresolver from your ISP. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS for SMTP Outbound -- Only One tlsproxy
Greg Sims via Postfix-users: > > It is assumed that you're not a victim of systemd-journald log mangling. > > It may be dropping some messages, and recording others out of order, > > breaking "collate". On Linux systems where systemd is doing the > > logging, you'll want to have Postfix writing its own log files directly, > > bypassing syslog. I have: I think that the nost useful info is logged by the Postfix SMTP client, especially including the low-level connection info that may not have a queue ID. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS for SMTP Outbound -- Only One tlsproxy
Wietse Venema via Postfix-users: > Greg Sims via Postfix-users: > > May 22 03:13:22 mail01.raystedman.org t123/smtp[46725]: > > 604BE30A4ACA: to=<@gmail.com>, > > relay=gmail-smtp-in.l.google.com[142.251.2.26]:25, conn_use=2, > > delay=1576, delays=0.05/1550/25/0.84, dsn=2.0.0, status=sent (250 > > 2.0.0 OK 1716372802 41be03b00d2f7-6578166a383si2117154a12.283 - > > gsmtp) > > These 25s are unexpected. > > - When Postfix saves/reuses a connection it does not rmember the > time spent setting up the connection. Technically, there is no > msg_stats_print() call in the code path that saves a connection to > the connection cache, and there is no msg_stats_scan() call in the > code path that retrieves a connection from cache. > > That means it took the Postfix SMTP client 25s to: > > - Receive a delivery request from the queue manager, > > - Retrieve a connection from the connection cache, > > - Send the RSET command to the remote SMTP server, > > - Retrieve the RSET server response. > > That is, the clock for 'connection setup' stops when the Postfix > SMTP client builds the MAIL FROM command. This is also when he > clock is started for the time spent delivering the message. If the delay is with snding or receiving RSET, then the SMTP client log "conversation with XXX timed out". I don't know if hat has a queue ID logged with thata, though. Just grep for 'conversation with'. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS for SMTP Outbound -- Only One tlsproxy
Greg Sims via Postfix-users: > May 22 03:13:22 mail01.raystedman.org t123/smtp[46725]: > 604BE30A4ACA: to=<@gmail.com>, > relay=gmail-smtp-in.l.google.com[142.251.2.26]:25, conn_use=2, > delay=1576, delays=0.05/1550/25/0.84, dsn=2.0.0, status=sent (250 > 2.0.0 OK 1716372802 41be03b00d2f7-6578166a383si2117154a12.283 - > gsmtp) These 25s are unexpected. - When Postfix saves/reuses a connection it does not rmember the time spent setting up the connection. Technically, there is no msg_stats_print() call in the code path that saves a connection to the connection cache, and there is no msg_stats_scan() call in the code path that retrieves a connection from cache. That means it took the Postfix SMTP client 25s to: - Receive a delivery request from the queue manager, - Retrieve a connection from the connection cache, - Send the RSET command to the remote SMTP server, - Retrieve the RSET server response. That is, the clock for 'connection setup' stops when the Postfix SMTP client builds the MAIL FROM command. This is also when he clock is started for the time spent delivering the message. > Another 25 seconds by google without conn_use: > > May 22 03:12:57 mail01.raystedman.org t121/smtp[47173]: > 4224D30C1817: to=<@gmail.com>, > relay=gmail-smtp-in.l.google.com[142.250.141.27]:25, delay=1543, > delays=0.01/1517/25/0.79, dsn=2.0.0, status=sent (250 2.0.0 OK > 1716372777 41be03b00d2f7-66d4526311dsi4920983a12.891 - gsmtp) Yup. Wiets ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS for SMTP Outbound -- Only One tlsproxy
Greg Sims via Postfix-users: > This is a sample of delays= for google.com -- 20 and 25 second delays: > > 0.01/11/20/0.73, > 0.01/9.5/20/0.77, > 0.01/0/25/0.74, > 0.01/7.6/25/0.91, > 0.01/6.9/25/1.1, > 0.01/13/20/4.6, > 0.01/14/25/0.56, > 0.01/14/25/1.1, > 0.01/0/0.22/0.72, > 0.01/0/0.39/0.79, So there is some reuse. You still need to answer Viktor's request for detail logging. That will reveal (to us, at least) what the those 20-25 seconds are going into. It is DNS, TCP connection setup, TLS, and so on. > Here are delays= from yahoo -- 5.3 second delays: > > 0.01/0/10/4.1, > 0.05/0/5.1/0.95, > 0.01/0/5.2/0.68, > 0.01/0/5.3/0.57, > 0.01/0/0.45/0.42, > 0.01/0/5.3/0.42, > 0.01/0/5.3/0.34, > 0.01/0.39/5.1/0.73, > 0.01/0/1.2/2, > 0.01/0/5.3/0.34, Some reuse, mostlyinsane delays. > And from icloud -- little delay: > > 0.01/0/0.14/2.5, > 0.01/0.02/0.15/2.7, > 0.01/0/0.34/11, > 0.01/0/0.13/4.9, > 0.01/0/0.06/4.1, > 0.01/0/0.13/1.5, I wonder what portion of that are reused connections. Well, you have your data collection home work. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS for SMTP Outbound -- Only One tlsproxy
Jaroslaw Rafa via Postfix-users: > Dnia 21.05.2024 o godz. 16:38:21 Wietse Venema via Postfix-users pisze: > > > delays=0.01/2639/25/0.41 > > > delays=0.01/2639/25/0.58 > > > delays=0.01/2641/25/0.58 > > > delays=0.01/2644/25/0.69 > > > delays=0.01/2643/25/0.58 > > > delays=0.01/2640/25/0.57 > [...] > > c=25s. It takes a whopping 25 econds for connection setup, including DNS, > > EHLO, and STARTTLS. And if that is not bad enough already, > > your connectuions also are not reysed. Reusing a connection would > > reduce the 25s dramatically. > > I wonder why it is *always* 25 seconds, while the other delays slightly > vary, which would be normally expected. Is it possible that something in > your sending pipeline is introducing an artificial delay when setting up the > connection, for example something tries (unsuccessfully) to connect to > somewhere and only *after* the attempt times out, Postfix continues with > connection setup? If timeout in question is 25 seconds, this would explain > why the value is so constant here... DNS queries time out after 5s, so that could be a reason, oo (bad server(s) in /etc/resolv.conf). Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Selection of a custom smtp-transport based on recipient addresse's MX with check_recipient_mx_access doesn't work
Jaroslaw Rafa via Postfix-users: > Dnia 21.05.2024 o godz. 22:27:04 Henri Schom?cker via Postfix-users pisze: > > > > So what we need to do is to limit the sending rate to all MX servers > > under protection-outlook-com. > > Postfix does not support this, Wietse probably could explain why. > You can select a transport by destination domain, but not by destination MX. > Probably what you need to do is to write an external program that interfaces > with Postfix via "socketmap" or "tcp" type lookup table, checks the MX for > the destination domain, and returns the name of the transport to be used. You could try to aggregate all deliveries for protection-outlook-com customers with a FILTER action.. check_recipient_mx_access hash:/etc/postfix/recipient_mx_access With recipient access actions like: protection-outlook-com filter smtp-protection-outlook-com And in master.cf have a dedicated SMTP client with that service name smtp-protection-outlook-com, and configure cocurrency limts and rate delays for that service name. I'm on vacation, so no time to workd out a complexrte example now. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Disable Non Delivery Notifications only for some adresses
Kevin Cousin via Postfix-users:
> Hi,
>
> We are using Postfix as relay for our internal apps. This apps are
> sending mails to final users with from nore...@example.net, but
> sometimes, adresses are wrong and a Non delivery notification is
> generated ans sent back to nore...@example.net.
>
> Is it any way to disable this notifications? only to "noreply@xxx"?
> (without disabling NDN) ?
>
> It seems creating an header check To: noreply@ DISCARD is not the good
> way.
Configure a dedicated smtpd servicce in master.cf. Then use
https://www.postfix.org/postconf.5.html#smtpd_command_filter to
append NOTIFY=NONE to RCPT TO commands.
For example, to set up a no-bounce service on port 25:
/etc/postfix/master.cf:
:26 .. .. .. .. smtpd
-o { smtpd_command_filter = pcre:/etc/postfix/no-notify.pcre }
/etc/postfix/no-notify.pcre:
# Bounce-never mail sink.
# Use notify_classes=bounce,resource,software # to send bounced
# mail to the postmaster (with message body removed).
/^(RCPT\s+TO:\s*<.*>.*)\s+NOTIFY=\S+(.*)/ $1 NOTIFY=NEVER$2
/^(RCPT\s+TO:.*)/ $1 NOTIFY=NEVER
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS for SMTP Outbound -- Only One tlsproxy
Greg Sims via Postfix-users: > Thank you Viktor. > > Answers: > * smtp_connection_cache_on_demand = yes -- this was configured > > Changes: > * certs back to defaults > * smtp_tls_loglevel = 1 > > Before enabling TLS our send rate was about 4K emails per minute -- we > are now seeing 300 to 500 per minute. > > The email creation process is sending new mail via a private network. > We are in the middle of an ip address migration so -- email creation > is currently single threaded with 100 uSec delays between emails. I > can increase the concurrency/speed of the email creation process(es) > -- I fear it would only increase the size of the inbound email queue. > > Here is a set of delays from the logs: > > delays=0.01/2639/25/0.41 > delays=0.01/2639/25/0.58 > delays=0.01/2641/25/0.58 > delays=0.01/2644/25/0.69 > delays=0.01/2643/25/0.58 > delays=0.01/2640/25/0.57 > > I scanned a large section of the logs | grep status=sent. These > delays are consistent throughout the peak demand period. I'm the person who implemented the delays=a/b/c/d breakdown. See https://www.postfix.org/postconf.5.html#delay_logging_resolution_limit In your case: a=0.01s. You have negligible delay between between Postfix reciving a message into the incoming queue, and the queue manager moving it onoto the active queue (i.e. scheduled by the queue manager for delivery). b=2640 Messages are waiting a long timr for their turn to be delivered. This is a lot of time because... c=25s. It takes a whopping 25 econds for connection setup, including DNS, EHLO, and STARTTLS. And if that is not bad enough already, your connectuions also are not reysed. Reusing a connection would reduce the 25s dramatically. d=.05s, the time to actually deliver the message. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: "delivered to command" config
Adam Weremczuk via Postfix-users: > Thank you Victor. > > What's the easiest way to change: > > bugzilla@mailserver:~$ cat ~/.forward > "|/vol/localhome/bugzilla/site/live/email_in.pl -vvv 2>/tmp/bz_emailin.log" > > to something like: > > remoteser...@mydomain.com:/vol/localhome/bugzilla/site/live/email_in.pl > -vvv 2>/tmp/bz_emailin.log There are multiple ways: 1 On the milserver achine: In ~bugzilla/.forward bugzilla@remoteser...@mydomain.com On the remoteserver, the ~bugzilla/.forward file with email_in.pl. 2) On the mailserver achine: In /etc/aliases: bugzilla: bugzilla@remoteser...@mydomain.com run the "newaliases" command after edirting the file. On the remoteserver, the ~bugzilla/.forward file with email_in.pl. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Dovecot logging to files causes postfix to break
Northwind via Postfix-users: > Hello > > When postfix delivery messages to local dovecot, how does the > authentication between postfix and dovecot happen? Local delivery does not involve IMAP. BTW This is the Postfix mailing list. Questions about Dovecot are better asked on their forum. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Dovecot logging to files causes postfix to break
Richard Rosner via Postfix-users: > I have a mailing server setup based on Debian Stable that uses > postfix for IMAP and SMTP and dovecot for internel mail handling, You mean, Postfix for SMTP, Dovecot for IMAP. > like filtering, sorting into users inboxes etc. I now wanted to > set dovecot to not write to syslog, but to dedicated files in > /var/log/dovecot. While everything indicates that this happens > successfully, postfix will soon start logging complaints: > > May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9: > to=, relay=local, delay=3.2, delays=1.9/0.29/0/1.1, > dsn=4.3.0, status=deferred (temporary failure. Command output: > lda(user): Error: net_connect_unix(/run/dovecot/stats-writer) > failed: Permission denied Can't open log file > /var/log/dovecot/error.log: Permission denied ) That is a DOVECOT error message from the DOVECOT local delivery agent (lda). Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix not doing round robin for equal weight MX records
John Doe via Postfix-users: > We have enabled TLS on nlp3 and all traffic is even now :) > Now it's time for a change to be able to reuse connections for TLS. That would be: smtp_tls_connection_reuse = yes Available in Postfix 3.4 and later. As you have found, connection reuse speeds up deliveries; the difference is even larger with TLS. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inet_interfaces and loopback
Alex via Postfix-users: > postfix[1350]: egrep: warning: egrep is obsolescent; using grep -E > postfix-out/postfix-script[1355]: starting the Postfix mail system > postfix-out/master[1357]: daemon started -- version 3.7.9, > configuration /etc/postfix-out That is the 'postfix-out' instance. > # postconf -n -c /etc/postfix-out inet_interfaces > inet_interfaces = 127.0.0.1 And the 'postfix-out' instance uses only the loopback address. > postfix[1361]: fatal: parameter inet_interfaces: no local interface found > for 130.250.NNN.197 That is not the 'postfix-out' instance. Perhaps you need to look at *that* main.cf file. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Fwd: [S-announce] [ANN]ounce of s-dkim-sign v0.6.1
This discussion seems of-topic for the postfix-users mailing list. If you feel strongly about how email is authenticated, I suggest that you join the relevant working group discussions while the details are still mutable. Complaining about the final result is too late, and publishing non-interoperable tech is unproductive. Frankly, I don't care how a digital signature is computed as long as it is clear what it does and does not protect. All algorithms will eventually become obsolete, though it may take 20 years. There will be an opportunity to replace a bad algorithm with a better or worse one. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix not doing round robin for equal weight MX records
Viktor Dukhovni via Postfix-users: > On Fri, May 10, 2024 at 01:13:06PM -0400, Wietse Venema via Postfix-users > wrote: > > > > Logs: > > > grep relay=nlp[123456].*status=sent /var/log/maillog | sed > > > 's/.*relay=//' | sed 's/,.*//' | sort | uniq -c > > This fails to deduplicate multi-recipient deliveries, which record > the same relay= for each message recipient. It also does not > distinguish between original connections and connection reuse. > > > > 5770 [23]nlp1.loc-prd.net[10.56.155.14]:25 > > > 5694 [24]nlp2.loc-prd.net[10.32.32.103]:25 > > > 5402 [25]nlp4.loc-prd.net[10.32.32.104]:25 > > > 21531 [26]nlp3.loc-prd.net[10.26.15.31]:25 > > > 5570 [27]nlp6.loc-prd.net[10.26.15.32]:25 > > > 5694 [28]nlp5.loc-prd.net[10.26.15.34]:25 > > The OP's original post included: > > smtp_connection_cache_on_demand = yes > > A subsequent post did not. With the configuration in flux, the > measurements are likely to present an inconsistent view. > > Note also, that with connection connection caching, the *fastest* > (lowest-latency) server will handle more of the traffic, because its > connection is returned to the "connection pool" more frequently. This > is a *feature*, you want to avoid slow servers so that slow servers > don't impact throughput. Otherwise, the slow servers can become > connection *attractors* tying up all available connection slots. > > Clearly round-robit is happening, and the observed fairness anomaly > is almost certainly not due to lack of randomisation, but rather > a result of measurement methodology and/or connection caching. I agree that connection reuse can be a plausible explanation. As Viktor mentions, the default Postfix connection reuse limits will favor the faster relay server. That is a feature, not a bug. These are the defaults: smtp_connection_reuse_count_limit = 0 smtp_connection_reuse_time_limit = 300s You can verify this "connection reuse" behavior, by looking at the "conn_use=" attribute in Postfix logging. With the default connection reuse limits, - The range for "conn_use=" counts for the other relays will be smaller than nlp3 (the other relays will have less reuse). - The range for "delay=" values for the other relays will be similar to nlp3. It is possible to defeat Postfix's preference for the fastest relay, by relying on a reuse count limit instead of a reuse time lmit. But if you do that, the slower relay servers will attract more traffic, which no-one wants to happen. For details of how that works, see https://www.postconf.org/postconf/5.html#smtp_connection_reuse_time_limit Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix not doing round robin for equal weight MX records
Wietse Venema: > Please provide evidence in the form of logs that show the > preference. John Doe: > Is this OK / enough ? > Logs: > grep relay=nlp[123456].*status=sent /var/log/maillog | sed > 's/.*relay=//' | sed 's/,.*//' | sort | uniq -c > 5770 [23]nlp1.loc-prd.net[10.56.155.14]:25 > 5694 [24]nlp2.loc-prd.net[10.32.32.103]:25 > 5402 [25]nlp4.loc-prd.net[10.32.32.104]:25 > 21531 [26]nlp3.loc-prd.net[10.26.15.31]:25 > 5570 [27]nlp6.loc-prd.net[10.26.15.32]:25 > 5694 [28]nlp5.loc-prd.net[10.26.15.34]:25 That's 49661 deliveries, where nlp3 gets 15905 more conections than the average for the other five hosts, or 32% of the 49661. This belies the idea that Postix does not round robin. It is more like some of the time it fails to reach the other five MX hosts. (I'm assuming that you weren't changing Postfix configurations during the time that the logs were created). At this point I consider this problem as external to Postfix. And the remainder of this response is pure hallucination. A difference in connectivity could show up as larger than expected 'delay' results in Postfix logging, when it randomly tries to reach one or more of the other five MX hosts before it succeeds with nlp3. Note that these six hosts are in different subnets, and I suspect that you may have a transient address-specific connectivity problem that sometimes affects connecttivity to the other five hosts. People who use Postfix have seen address-specific connectivity problems caused by a bad netmask, and by a data-dependend hardware error (a bad port on a network switch). A bad DHCP server could reply with a bad netmask (this is nasty, especially when there are multiple DHCP servers and the bad one wins only some of the time). Specifically, 10.56.155 has host nlp1 10.32.32 has host nlp2 and nlp4 10.26.15 has hosts nlp3, nlp5, and nlp6. HOWEVER: nlp3 is in range 10.26.15[.0-31] (10.26.15.0/27) nlp5 and nlp6 are in 10.26.15.[32-64] (10.26.15.32/27) What are the IP address and netmask of the problem server? How do these servers get their IP address: from DHCP or statically? Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix not doing round robin for equal weight MX records
John Doe via Postfix-users: > Hi, > > I was hoping for real MX record round-robin but it does not work on one of > my servers. > > Somehow, postfix is prioritising one of the MX more than others. By default, Postfix looks up SMTP servers in DNS, and randomizes the order of equal-preference records. After 25 years this is one of the more bizarre problem reports. > Always the same: nlp3.loc-prd.net Then you aren't using the default settings for server lookup, or Postfix is using a different resolver than your manual tests (with dig), or Postfix has to ignore hosts that speak only IPv6 while Postfix speaks only IPv4, or your resolver is doing nasty things. Postfix has no built-in DNS protocol support and relies on system infrastructure. Historically that was a local bind or unbound server, but more recently, systemd has also invaded into this territory. > All MX servers, are in local network to this client mailserver. Postfix can handle that. > We have relayhost in main.cf: > > relayhost = mxmail.adatum.net Good. You have MX lookups turned on. > We have MX record for this relayhost with equal weights of 10 for each, DNS > TTL is setup to 300s, dns system is BIND, not Windows. > dig mx mxmail.adatum.net Can you demonstrate that this uses the exact same resolv.conf file as Postfix? > mxmail.adatum.net. 146 IN MX 10 nlp1.loc-prd.net. > mxmail.adatum.net. 146 IN MX 10 nlp2.loc-prd.net. > mxmail.adatum.net. 146 IN MX 10 nlp3.loc-prd.net. > mxmail.adatum.net. 146 IN MX 10 nlp6.loc-prd.net. > mxmail.adatum.net. 146 IN MX 10 nlp5.loc-prd.net. > mxmail.adatum.net. 146 IN MX 10 nlp4.loc-prd.net. What are the IP addresses for these hosts? Postfix will use only hosts that it gets an IP address for. > Some setup parametres for better view: This is not useful, because you select only the things that YOU thnk are useful. Send "postconf -n" output (as an attachment if your mail software does not respect line endomgs and mashes everything up. There is no need for smtpd_xxx settings. But I do need to see things like any non-default inet_protocol settings. > We have another 2 servers with the same setup, and they relay quite equally. Equally as in that they also "prefer" the same MX host? Or a different one? > Anything that will help to sove this issue would be much appreciated. Please provide evidence in the form of logs that show the preference. grep 'postfix/smtp.*relay=' /the/maillog/file | grep -v nlp3.loc-prd.net You can anonymize user names and domain names, and you can omit mail that wasn't using the $relayhost setting. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Difference between alias_maps and alias_database
On Tue, May 07, 2024 at 05:47:59PM +0200, Matus UHLAR - fantomas via Postfix-users wrote: > On 07.05.24 17:13, Дилян Палаузов via Postfix-users wrote: > >I try to understand the difference between alias_database and alias_maps. > > >Or, does postalias/newaliases use is alias_database as input, ignoring > >alias_maps, while local ignores alias_databases and uses alias_maps? > > Precisely. > > alias_maps is for local(8) to know which database(s) to read. > They don't need to be writable (e.g. nis:mail.aliases) Only "newaliases" knows what "alias_database" is. By default, "newaliases" invokes "postalias" with a list of databases specified in "alias_database". Wietse > alias_database is for newaliases/postalias to know which database to > reindex. > > ...because not all databases in aliases can be indexed by postfix programs. > > >when the same table is supposed to be used by local and postaliases, the > >same value (filename) must be set to alias_database and alias_maps? > > If you want postfix to work properly, yes. > > >I think it would be better to have only one parameter: alias_maps, and > >newaliases should either update, what is pointed to by alias_maps, or > > This may not be possible for NIS maps, LDAP maps etc etc. > That's why there are separate parameters. > > >report an error on failure. In any case the presence of the two options > >currently suggests that there are use cases to have for both options two > >different local files as value and the documentation does not elaborate > >whether this is a good or bad idea. > > perhaps the default value for alias_maps could be something like: > > alias_maps = $alias_database, nis:mail.aliases > > But the rest still applies. > > -- > 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. > Silvester Stallone: Father of the RISC concept. > ___ > 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: When to set virtual_alias_domains, when virtual_mailbox_domains is already set?
On Mon, May 06, 2024 at 11:37:54AM +0200, Дилян Палаузов via Postfix-users wrote: > Hello, > > postconf(5) contains: > > virtual_alias_domains (default: $virtual_alias_maps) > virtual_alias_maps (default: $virtual_maps) > virtual_maps (default: empty) > > Thus virtual_alias_domains is by default emtpy. > > VIRTUAL_README says: > • NEVER list a virtual alias domain name as a mydestination domain! > • NEVER list a virtual MAILBOX domain name as a virtual ALIAS domain! > > My reading is that a domain in virtual_alias_domains can be mentioned > neither in virtual_mailbox_domains nor as mydestination domain. Please see https://www.postfix.org/ADDRESS_CLASS_README.html#classes (or a local copy of that file) for what each domain list is for, and how Postfix looks up valid recipient addresses. Wietse > What can be put in virtual_alias_domain, when virtual_mailbox_domain and > mydestination are set? Why cannot this value always be put in > virtual_mailbox_domains? > > Having a domain in virtual_mailbox_domains implies that domain is handled by > virtual aliases provisions. I think it will be useful to extend one of > existing examples in VIRTUAL_README with a case, where both > virtual_alias_domains and virtual_mailbox_domains are set. > > Greetings > Дилян > ___ > 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: rejecting mails to expired accounts including a hint at the new address
Edgar Fuss via Postfix-users: > Hello, > > I'm looking for prior art on rejecting mails to expired accounts > including a hint at the new address. You could use the relocated_maps feature for this. This will reject at RCPT TO time, with a hard-coded response "5.1.6 User has moved to ". You could also use transport_maps which gives more control over the text: u...@example.com error:5.1.6 account no longer exists, try That is without the 5XX SMTP code. The Postfix SMTP server will prepend a suitable value. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Relaying Teams Invitations send by Microsoft365 via Postfix to the Internet
Norbert Schmidt via Postfix-users:
> Hello,
>
> We've got a single user needing Micro$oft Teams. This users mailaccount
> u...@contenso.com is configured on our server AND within Microsoft365 as
> sending address for the invitations.
> All other mail accounts are local and send via postfix.
> With blimmen Microsoft365 the invitation mails are directly send out to the
> internet with the u...@contenso.com sender address. These mails get bounced
> quite often because neither are the Microsoft365 Servers configured within
> SPF nor is Microsoft365 configured to DKIM sign these mails.
> I've configured a SMTP connector on the Microsoft side to route all mail
> through our postfix system. The SMTP connector is unable to use
> authentication or to be configured to use a different port. So, to make this
> work I had to add the Microsoft365 sending IP CIDR Ranges to the
> smtpd_recipient_restrictions by using "check_client_access
> cidr:/etc/postfix/microsoft365_cidr"
> The postfix server now is accepting the mail, but when relaying it to the
> internet the reciving server says: " 550 5.7.26 Message rejected per DMARC
> policy by contonso.com"
> I suppose this is either because the the originating server was not listed
> in the SPF entry or because the mail is not DKIM signed.
>
> My questions:
> - Would postfix be an almost open relay using this configuration as all
> users of Micro$oft365 would be able to send mail through my server to the
> internet?
> - Is there a safe way to configure the M365-SMTP-Connector to send mail
> through my postfix mailserver (and only my mail, not the mail of any other
> Microsoft 365 user)???
> - How to DKIM sign these mails with "dkimproxy" as these mails are received
> via port 25 smtpd they would be checked by dkimproxy if they are destined to
> our users but not signed when relayed to the internet?
You could configure a Postfix SMTP daemon with a dedicated IP address
or port to forward and sign email only from Microsoft, and only
from a specific sender address.
This daemon would have its own Postfix settings for access control
and DKIM signing.
The example assumes that you can configure an additional IP address
or port to receive mail with the existing Postfix host.
master.cf:
a.b.c.d:25 inet n - n - - smtpd
# Require an expected Microsoft client IP address
-o { mynetworks = p.q.r.s/24 }
-o { smtpd_client_restrictions = permit_mynetworks, reject }
-o { smtpd_recipient_restrictions = permit_mynetworks, reject }
# Require an expected sender address
-o { smtpd_sender_restrictions =
check_sender_access inline:{{ u...@contonso.com = permit }}, reject }
# Override main.cf settings with empty value
-o { smtpd_helo_restrictions = }
-o { smtpd_relay_restrictions = }
# Sign with dkimproxy
-o content_filter=dksign:[127.0.0.1]:10027
-o receive_override_options=no_address_mappings
Then, you would have to change nothing on the standard port 25
service (os port 587 or 465).
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: milter: how about a SMFIP_NOQUIT?
Wietse Venema via Postfix-users: > Looks like there is sufficient basis to make SMTPD_QUIT_NC rerquests > thts from Postfix. Just need to figure out how to enable/disable > this particular command based on the Postfix and Milter protocol > versions. There is already some 'set' intersection code for doing > such things on the Postfix side. A later follow-up: after a little detective work, I found that it should be safe to send the following depending on the effective protocol version in the MTA to Milter handshake: SMFIC_QUIT_NC version >= 6, otherwise send SMFIC_QUIT as usual. (that's because SMFIC_QUIT_NC was introduced in sendmail-8.14 which also introduced Milter protocol version 6.) I've opened a development branch locally and will add the version checks and SMFIC_QUIT_NC stuff later. It's a non-trivial change, because there are many places in the code where Postfix automatically closes a Milter connection when no further events of interest will be sent (for example after a Milter replies with "accept", or rejects or tempfails a "connect" event). This may require a new conection state for such milter connections, to enforce sanity. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: long header folding and DKIM fails
Steffen Nurpmeso via Postfix-users: > But one thing is plain, if lines get folded "artificially" to > satisfy line length limits, then this is a whitespace that DKIM > will see, and if it was not in the original message, the signature > will break. After the DKIM signature is generated, the artificial line break already invalidates the signature. The purpose of the artificial space after this line break is to preserve the MIME structure, so that humans aren't exposed to raw html, q-p, or base64 etc. > The only possibility to get over this hurdle is to apply RFC 2047 > (or RFC 2231, in a parameter) MIME encoding, and then [...] Any such actions need to be taken sender-side, before the DKIM signature is generated. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: long header folding and DKIM fails
Postfix does not store line endings internally, because different environments have different line ending conventions (for example SMTP has while UNIX has ). Postfix strips line endings on input, and adds them on output. Postfix was modeled after routers with different kinds of network interfaces. The Postfix sendmail command allows both and , because too many app developers were messing up. As of January 2024, Postfix replaces any and that are not part of a line ending with space. This prevents outbound SMTP smuggling, and makes DKIM signatures more likely to verify. The default setting "cleanup_replace_stray_cr_lf = yes" was added in Postfix 3.9, 3.8.5, 3.7.10, 3.6.14, and 3.5.24 later. Returning to the problem at hand, the options that I see are: - Forward the message including all its MIME headers, and leave the decoding to the recipient's mail software. - Use a real MIME parser and decoder to extract the plain text that you want to forward. The trick to strip " =" works only for quoted-printable encoding, but does not handle messages encoded in base64. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: HowTo Migrate from text based mapping/routing to Database based routing
Ml Ml via Postfix-users: > Hello, > > currently we manually use text files for mapping/routing: > > # postconf -n |grep -e transport -e alias > alias_database = hash:/etc/aliases hash:/etc/postfix/aliases > alias_maps = hash:/etc/aliases hash:/etc/postfix/aliases > allow_mail_to_commands = alias,forward,include > local_transport = lmtp:unix:/run/cyrus/socket/lmtp > mailbox_transport = lmtp:unix:/run/cyrus/socket/lmtp > transport_maps = hash:/etc/postfix/mailertable (=> sub.example.com > smtp:[somerelay.net] > virtual_alias_domains = /etc/postfix/local-host-names (=> example.com) > virtual_alias_maps = hash:/etc/postfix/virtusertable > hash:/etc/postfix/aliases (=> f...@example.com pop-1234-0005) > virtual_transport = lmtp:unix:/run/cyrus/socket/lmtp > > We would like to migrate to a Database in order to manage it with a > GUI or something. > Any hints on this? Are there existing scripts/projects? Some of the above settings have no support for table lookups, for example *_transport and allow_mail_to_commands. See https://www.postfix.org/postconf.5.html Any database scheme will do, as long as you can provide the queries that return the answers that Postfix expects to see. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: long header folding and DKIM fails
Steffen Nurpmeso via Postfix-users: > Wietse Venema via Postfix-users wrote in > <4vsq5f6q3nzj...@spike.porcupine.org>: > |Tim Coote via Postfix-users: > .. > |> SMTP headers are often 'folded' as they flow through MTAs. The > |> standard approach to folding and unfolding is covered in rfcs 5322 > ... > |3) Lines that exceed 998 bytes (not including ) cannot be > | sent in SMTP. The result of sending such text is UNDEFINED. > ... > |When a line is too long, the Postfix SMTP client inserts > | (controlled by smtp_line_length_limit). > > This is a deficit of the entire RFC *822 series that a superficial > whitespace is necessary at that point. It was simply not on the > table, and i got not even an answer on that in private > communication (but maybe because of my way of speaking things out, > i mean, isn't that just a desaster: this *breaks* the protocol). > (On the other hand the dinosaur nmh just got (partially) proper > line folding in September last year: > > > http://git.savannah.gnu.org/cgit/nmh.git/commit/?id=542cb12b6d0646b711772ee97c1e2aacf2bada86 > > and they will fail for the artificial case as i said in > > https://lists.nongnu.org/archive/html/nmh-workers/2023-08/msg00010.html > [https://lists.nongnu.org/archive/html/nmh-workers/2023-08/msg00011.html]) > > |Before Postfix inserted , some MTA would insert > |a line break after ~1024 without adding a space. This would > |"terminate" the message header, destroy the MIME structure, and > > This is really what they do? Then .. my "artificial whitespace" > thought of a decade ago would be wrong. I would have thought they > possibly reformat with RFC 2047 (if they can), as i said in the > msg00011 thing above. Yes this was a real problem. For example, an email message like this: label: value label: value-that exceeds-smtp-limit ...zero or more label: value... MIME-Version-1.0 Content-type: multipart/mixed, boundary="foobar" END_OF_PRIMARY_HEADER This is a multi-part message in MIME format. --foobar first body part --foobar first body part --foobar-- Was received as: label: value label: value label: first-part-of-value-that-exceeds-smtp-limit END_OF_PRIMARY_HEADER first body line with remainder-of-value-that-exceeds-smtp-limit >From here on all remaining content including headers and MIME boundaries was received as one large non-MIME message body and was displayed to the user in its encoded form includeing MIME boundaries encoded text (quoted-printable or base62 encoded). Why did that happen? Because some MTA's input reader did not know if it was reading a header or body line. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: long header folding and DKIM fails
Tim Coote via Postfix-users: > Hullo > > I've recently stumbled across this issue and wondered if it's a/ > common, b/ how it can be addressed. > > SMTP headers are often 'folded' as they flow through MTAs. The > standard approach to folding and unfolding is covered in rfcs 5322 > and is relied on in 6377 (DKIM). Message signing (DKIM) is > increasingly used to avoid spam/phishing and relies on consistent > header formats when the signature is generated and validated. > > It is known that of the two folding mechanisms, one, called > 'simpled', just assumes that the messages are not changed in any > way, which is not, in general, practical. You appear to be confusing: 1) Header folding, which involves folding whitespace as described in RFC 5322. When Postfix is allowed to rewrite ADDRESS headers (controlled with local_header_rewrite_clients) then it may re-fold address headers but NOT OTHER headers (such as List-Unsubscribe). 2) DKIM header or body canonicalization, either simple or relaxed, which is a way to process message content before computing or verifying its DKIM signature as described in RFC 6376. 3) Lines that exceed 998 bytes (not including ) cannot be sent in SMTP. The result of sending such text is UNDEFINED. But this is unlikely the cause of a problem with a List-Unsubscribe header that you show in a later email message. That header was only 756 bytes before it was broken up. When a line is too long, the Postfix SMTP client inserts (controlled by smtp_line_length_limit). Before Postfix inserted , some MTA would insert a line break after ~1024 without adding a space. This would "terminate" the message header, destroy the MIME structure, and users would see message attachments as raw base64 content that had become part of the main message body. For DKIM signatures to work across multiple email systems, a message has to be already in RFC compliant form before it is signed, and has to remain RFC compliant after signing. Messages that rely on UNDEFINED behavior may have DKIM signature failures. > Unfortunately, the other folding mechanism (relaxed) is based on > replacing with (thus turning one > line into two), and unfolding consists of deleting where > it is preceded by . The approach is unfortunate as > some headers don't have any , so the unfolded header > is different from the original (signed) version. So if one of these > headers is included in the signature it will fail. > AFAICT, Postfix folds headers and, if there is not whitespaces > typically puts after a comma in the data structure > of the header, thus breaking DKIM on unfolding (as there is an > extra character not in the original header used to construct > the signature. As mentioned above, Postfix may re-fold ADDRESS headers (see point 1 above) but not other headers (such as List-Unsubscribe). Additionally, Postfix will 'break' long lines that cannot be sent within the SMTP specification with (see point 3 above). > This raises a few questions: > - is my analysis correct: postfix header folding can break DKIM as described See points 1), 2) and 3) above. > - is the problem common (not very, but it's often silent, so it > could just be that it's not being found as it's not being looked > for) As mentioned before, DKIM is defined only for messages that are fully RFC compliant before and after the mesage is signed. A message that relies on UNDEFINED behavior may have its signatures broken by any MTA that handles that message. > - is there a pragmatic fix in Postfix configuration (e.g. to > increase ths maximum size of a header line?) See 3) above. If Postfix does not break too-long lines, then you are depending on UNDEFINED behavior and other remote MTAs may still break the signature. You just won't be able to verify that so easily like you did with gmail. But, Postfix isn't changing the List-Unsubscribe header in your later example. To change the SMTP specification, you'd have to convince the IETF community for SMTP to allow arbitrary line lengths. > - is it legitimate to fold without according to rfc 5322 Did you mean fold a line with instead of ? Postfix does not do that. Other MTAs might depending on how long the line is. See 3) above. > - if there's an issue of incompatibility between folding/unfolding > of headers, how will this be addressed in the longer term Did you mean 1) folding, 2) canonicalization, or 3) breaking long lines that violate the SMTP specification with ? The longer term fix is to send messages that meet RFC recommendations (lines SHOULD be <=78) and requirements (lines MUST be <= 998) before and after they are signed. A proper base64 decoder will ignore line breaks and whitespace, so there should be no need to send jumbo header or body lines at all. In later email I see that you have a long List-Unsubscribe header, but its total length is well under the Postfix smtp_line_length_limit, so if it is folded after
[pfx] Re: ipv6 connection
Jack Raats: > Wietse, > > I run the script every five minutes for more than 13 hours to the DNS > server of Cloudflare (2620:fe::fe). > Four times I had some packet drops (about 25%). Was that network path in any way similar to the path to your MX checker? You can check that with mtr (or traceroute which is much less informative) > I think that cann't explain why postfix is not reachable on ipv6. I think you have proven that some MX checker over some unknown path cannot always reach your Postfix system. I routinely run ping and mtr to monitor my connectivity. If there is packet loss, them mtr will tell me where on the network path that happens. > Can postscreen drop an ipv6 connection? Postfix does not care if a connection is over IPv4 or IPv6. Really. If there is a difference, then that happens at a lower level in the stack. It just happens to be more visible at the application level. Don not shoot the messenger of the bad news. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: ipv6 connection
Jack Raats via Postfix-users: > In the Netherlands but also in other countries you can use internet.nl > to test your e-mail and webserver. > It test your e-mailserver for ipv6 connectivity, SPF, DMARC and DKIM. > > My mailserver scores sometimes 100%, but also sometimes lower because it > cann't connect postfix on ipv6. > > In main.cf mynetworks and inet_interfaces has my ipv4 and ipv6 address. > inet_protocols = all. > > In the rest of my configs I'm using my ipv4 address. > > What is possible wrong in postfix or is it the connection? To monitor your IPv6 connectivity, you could run a cron job that runs a script that pings a well-connected IPv6 address: #!/bin/sh ping -q -c 10 some-ipv6 | loggger -t check-ping -p daemon.info and scan the log every day or so. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: milter protocol: chgheader: wondering on indices
> * For smfi_chgheader, filter order is important. Later >filters will see the header changes made by earlier ones. Yes, that is fundamental to the way that the Milter API works. Each Milter "inspects" the header and body content that exists after Postfix and previous Milters have made their changes. I trust that you are using a Postfix version that has all known bugs fixed, i.e. Postfix 3.9, or one of the versions annnounced at https://www.postfix.org/announcements/postfix-3.8.6.html Do not request 100% Sendmail compatibility for weird requests like making changes at a bogus header position. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: status=deferred (bounce or trace service failure)
Viktor Dukhovni via Postfix-users: > On Mon, Apr 22, 2024 at 12:21:01AM -0400, 785 243 via Postfix-users wrote: > > > Recently i'm seeing a few messages deferred with status=deferred > > (bounce or trace service failure) > > > > instead of status=deferred (host .. said: 450 ...) > > > > from the logs: > > > > postfix/smtp[272605]: warning: unexpected protocol > > delivery_request_protocol from private/bounce socket (expected: > > delivery_status_protocol) > > Your master.cf file has bad settings. Post the verbatim (no rewrapping > of whitespace of line breaks) output of "postconf -Mf". > > The "bounce" service entries should be: > > # Possibly chrooted, if Debian prefers that. > # > bounce unix - - n - 0 bounce > defer unix - - n - 0 bounce > trace unix - - n - 0 bounce > > Or perhaps the "bounce" service executable has been replaced with a link > to a delivery agent? The "real" bounce service supports the expected > protocol. Replacing the 'bounce' service with the 'discard' delivery agent has never been a supported configuration. It just happened to "work" because of sloppy protocol checks. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: active queue is too high
Wietse Venema via Postfix-users: > Gino Ferguson via Postfix-users: > > We have a relay server which has been working fine (postfix > > 3.3.0-1ubuntu0.4) > > Now there are ~20K mails in the active queue for a certain recipient > > and they are just sitting there. > > Wietse Venema: > > What does the output look like from: > > grep status= /var/log/maillog | grep the-certain-recipient > > Gino Ferguson via Postfix-users: > > Nothing. There are no status lines for these certain recipients. > > The last log entry is the 'queue active' for each mail. > > And how long ago was that entry? > > Can you share that line? I need the date format for the next analysis step. I suppose the problem may have fixed itself over the weekend. However it would be good if you could go back a few days and look for any issues logged concerning the queue manager. grep -E '(warning|error|panic).*qmgr' the-log-file Then, report any events logged during the time of trouble. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: active queue is too high
Gino Ferguson via Postfix-users: > We have a relay server which has been working fine (postfix 3.3.0-1ubuntu0.4) > Now there are ~20K mails in the active queue for a certain recipient > and they are just sitting there. Wietse Venema: > What does the output look like from: > grep status= /var/log/maillog | grep the-certain-recipient Gino Ferguson via Postfix-users: > Nothing. There are no status lines for these certain recipients. > The last log entry is the 'queue active' for each mail. And how long ago was that entry? Can you share that line? I need the date format for the next analysis step. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: active queue is too high
Gino Ferguson via Postfix-users: > Hi, > > > We have a relay server which has been working fine (postfix 3.3.0-1ubuntu0.4) > > Now there are ~20K mails in the active queue for a certain recipient and they > are just sitting there. > What does the output look like from: grep status= /var/log/maillog | grep the-certain-recipient Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: submission port 465 question
Mr. Peng via Postfix-users: > Hello, > > I saw this configuration in our master.cf as follows. > > What's the difference between the option "smtpd_relay_restrictions" and > "smtpd_recipient_restrictions"? In my opinion they both mean the sender > must pass the smtp auth. Thanks. > > smtps inet n - y - - smtpd > -o syslog_name=postfix/smtps > -o smtpd_tls_wrappermode=yes > -o smtpd_sasl_auth_enable=yes > -o smtpd_relay_restrictions=permit_sasl_authenticated,reject > -o > smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject > -o smtpd_sasl_type=dovecot > -o smtpd_sasl_path=private/auth You need to ask the distributor why they chose this. It is not part of the Postfix souce-code distribution. With the smtps (submissions) and submission services, either -o smtpd_relay_restrictions=permit_sasl_authenticated,reject -o smtpd_recipient_restrictions= or -o smtpd_relay_restrictions= -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject would be sufficient. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: hmm spf is missing :)
Benny Pedersen via Postfix-users: > Authentication-Resultslist.sys4.de; dkim=pass header.d=porcupine.org; > arc=none (Message is not ARC signed); dmarc=pass (Used From Domain > Record) header.from=porcupine.org policy.dmarc=none > > intended ? Are you asking why list.sys4.de ignores the porcupine.org SPF policy? Wietse > dmarc can't be aligned with this missing, i just complain for the > authres in spamassassin can't see this detail > > ___ > 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: duplicate deliveries
Marek Podmaka via Postfix-users: > On Sun, 14 Apr 2024 at 01:15, Wietse Venema via Postfix-users < > postfix-users@postfix.org> wrote: > > > If there is a difference in deduplication, then you have introduced > > a difference up-stream of the delivery agents. You need to find > > that difference. > > > ... > The differences between the servers are not large, the newer one is based > on the older, with some settings changed to be more "how it should be > currently done". On the old server (original config maybe 15 years old, > with debian/postfix upgrades but minimal config changes), I prefer the > "don't touch running system" approach, as modifying working parameters to > be better (but with same functionality) could cause unpredicted issues. > Both servers use the same underlying database structure. This is an opportunity to use the "diff" command. On the old system: postconf -n > postconf-old On the new system: postconf -n > postconf-new Compare the two with the diff command. diff postconf-old postconf-new | less If there are any differences besides domain names and the virtual delivery agent versus the lmtp delivery agent, then make the differences go away in the new Postfix. At that point, the new Postfix will deduplicate recipients addresses in the exact same way as the old one did. If people forward messages with Dovecot sieve, then loops can happen. You can configure the Postfix LMTP client to add a Delivered-to: message header, and reject a message that it has already delivered to the same recipient: master.cf: lmtp unix - - n - - lmtp flags=DX main.cf: lmtp_destination_recipient_limit = 1 See also: https://www.postfix.org/lmtp.8.html Sections "COMMAND ATTRIBUTE SYNTAX" and "SINGLE-RECIPIENT DELIVERY" https://www.postfix.org/postconf.5.html#transport_destination_recipient_limit Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: duplicate deliveries
Marek Podmaka via Postfix-users: > Hi, > > When/how does postfix prevent duplicate deliveries when delivering to an > alias and explicitly also to the alias result? For example all@domain + Cc > to one of the members of that alias. I have found parameters > "duplicate_filter_limit" and "enable_original_recipient" that mention it, > but I don't understand how exactly it works. The above duplicate filter is in effect when Postfix writes recipients to a queue file. This happens after virtual alias expansion, always_bcc, sender_bcc_mapsm, recipient_bcc_maps, and after any recipients added with Milter actions. When enable_original_recipient is turned on, the above duplicate filter will NOT discard duplicate recipients that differ in their "original recipient" address. This is for use cases where all mail for a domain is received in a single mailbox, and where the original recipient is obtained from the X-Original-To: header. > I have an older mailserver where this works (no duplicate deliveries, > otherwise someone would complain). I am using virtual users with default > virtual delivery. > > I also have another mail server also with the same type of virtual users > (same database schema), but which was setup with Dovecot LDA as delivery > agent. And there the deduplication doesn't work, I had to use If that is the only difference: you changed from delivery with the virtual delivery agent to delivery with the lmtp or pipe delivery agent, then Postfix still delivers the same recipients. If there is a difference in deduplication, then you have introduced a difference up-stream of the delivery agents. You need to find that difference. I siggest that you start with comparing the outputs from "postconf -n" on the old and new servers. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Submission Forward
svoop_pvde84wdgt--- via Postfix-users:
> Hiya!
>
> I'm running my own Postfix as part of a dockered MailU which works
> really smoothly for my own domains. However, I also have a few
> email addresses for client projects at work and for the sake of
> MUA simplicity, I forward all incoming mail to these addresses to
> my main email address on my own domain. Receiving is a piece of
> cake, unfortunately, sending is another story.
>
> This is the situation stripped to the important bits:
>
> * m...@mydomain.org is my main email handled by my own MX (Postfix/MailU)
> * m...@clientproject.org is my email used for this client project and handled
> by Google workspace
>
> Incoming mail to m...@clientproject.org is forwarded to m...@mydomain.org and
> delivered normally.
>
> Outgoing mail as m...@clientproject.org should use the (authenticated)
> SMTP of Google to assure SPF/DKIM alignment, but my MUAs don't
> support such a setting. (IMO, only Thunderbird allows multiple
> outgoing SMTP per email account.)
>
> I tried to figure out a server-side solution instead, something
> like a reverse forward or submission forward: Submit outgoing mail
> as m...@clientprojet.org to my own Postfix which is configured to
> recognise this "From" as external and therefore resubmit the message
> via the SMTP of Google (using my credentials for auth).
The official solution is to use sender_dependent_default_transport_maps
(indexed by envelope.from) to choose the relay MTA (such as Google
for a google-hosted sender address), combined with smtp_sasl_passwd
maps, indexed by that same relay MTA (including any :port and []).
Untested example:
/etc/postfix/main.cf:
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
smtp_sasl_passwd_maps = hash:/etc/postfix/smtp_sasl_passwd
smtp_tls_security_level = may
/etc/postfix/sender_relay:
m...@clientproject.org [smtp.google.com]:587
/etc/postfix/smtp_sasl_passwd:
[smtp.gmail.com]:587usedrname:password
Again, untested, typed from fallible memory.
You can harden this further with sender_dependent_default_transport_maps
and defining a dedicated SMTP client in master.cf, with
-o { smtp_tls_security_level = encrypt }
to make TLS mandatory.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Forward mail
Paul van der Vlis via Postfix-users: > Hallo, > > Unfortunately, I have quite a few customers who want to receive email > from their own domain at a different email address, such as a Gmail or > Hotmail address. I forward this in /etc/postfix/virtual. > > But I actually don't understand why this arrives, especially if the > sender has an SPF or DMARC clearly states that it should be rejected if > the email comes from the wrong IP. If a message has valid DKIM signatures (the message header and body still match) and the receiving systemn verifies DKIM, then it may still accept forwarded mail, despite SPF mismatch. > Perhaps Gmail and others don't care about that, but it could also be > that they look beyond the forward address and see that it comes from a > legitimate IP, but only forwarded is. > That would be good, but maybe easily forged without DKIM? > > Could someone tell us more about this? > > And what is a good solution for forwarding? Rewrite the sender? SRS? If the receiving system insists on SPF despite valid DKIM, yes. I have no first-hand experience doing that, but there is some SPF and SRS tooling. This is a part of Postfix that needs some work. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: disable search by at_domain in virtual
v k via Postfix-users: > When delivering mail, Postfix generates LDAP queries with query_filter > mail=@domain, which are unnecessary in my environment. This becomes > critical when sending to a mailing list group with many participants, > as each member address generates an additional query, consuming > extra time. In the Postfix LDAP configuration file, specify the "domain" parameter. domain (default: no domain list) This is a list of domain names, paths to files, or "type:table" databases. When specified, only fully qualified search keys with a *non-empty* localpart and a matching domain are eligible for lookup: 'user' lookups, bare domain lookups and "@domain" lookups are not performed. This can significantly reduce the query load on the LDAP server. There is partial support to control the lookups of virtual_alias_maps. Internal support exists, but it is not yet configurable. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Thunderbird 91, Postfix 3.7.x, Debian 12, Virtual Mailbox Users, TLS with Letsencrypt, error improper command pipelining after helo
David Mehler via Postfix-users: > Hello, > > Here is the complete log of the connections, IPS x-d out, but I tried > twice, once on 587, once with smtps enabled. Any help appreciated. We DID NOT ask for verbose logs. All we asked for is this: > postfix/submission/smtpd[1529]: improper command pipelining after EHLO > from xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]: QUIT\r\n and that is logged without verbose logging. I found on-line reports from 2018 where Thunderbird sends EHLO we-guess.mozilla.org\r\nQUIT\r\n I suppose that is an autoconf feature that hopefully can be turned off in Thunderbird, otherwise someone on the mozilla needs to learn how SMTP works. https://bugzilla.mozilla.org/show_bug.cgi?id=1681946 https://bugzilla.mozilla.org/show_bug.cgi?id=538809 Wietse > Dave. > > #tail -f /var/log/mail.log > 2024-04-02T09:48:08.220604-04:00 hostname > postfix/submission/smtpd[1529]: connect from > xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx] > 2024-04-02T09:48:08.220939-04:00 hostname > postfix/submission/smtpd[1529]: smtp_stream_setup: maxtime=300 > enable_deadline=0 min_data_rate=0 > 2024-04-02T09:48:08.221246-04:00 hostname > postfix/submission/smtpd[1529]: match_hostname: > smtpd_client_event_limit_exceptions: xxx.xxx.xxx.xxx ~? 127.0.0.0/8 > 2024-04-02T09:48:08.221434-04:00 hostname > postfix/submission/smtpd[1529]: match_hostaddr: > smtpd_client_event_limit_exceptions: xxx.xxx.xxx.xxx ~? 127.0.0.0/8 > 2024-04-02T09:48:08.221704-04:00 hostname > postfix/submission/smtpd[1529]: match_list_match: xxx.xxx.xxx.xxx: no match > 2024-04-02T09:48:08.221881-04:00 hostname > postfix/submission/smtpd[1529]: match_list_match: xxx.xxx.xxx.xxx: no match > 2024-04-02T09:48:08.222386-04:00 hostname > postfix/submission/smtpd[1529]: auto_clnt_open: connected to private/anvil > 2024-04-02T09:48:08.222577-04:00 hostname > postfix/submission/smtpd[1529]: private/anvil: wanted attribute: protocol > 2024-04-02T09:48:08.222801-04:00 hostname > postfix/submission/smtpd[1529]: input attribute name: protocol > 2024-04-02T09:48:08.222935-04:00 hostname > postfix/submission/smtpd[1529]: input attribute value: anvil_protocol > 2024-04-02T09:48:08.223103-04:00 hostname > postfix/submission/smtpd[1529]: private/anvil: wanted attribute: (list > terminator) > 2024-04-02T09:48:08.223264-04:00 hostname > postfix/submission/smtpd[1529]: input attribute name: (end) > 2024-04-02T09:48:08.223453-04:00 hostname > postfix/submission/smtpd[1529]: send attr request = connect > 2024-04-02T09:48:08.223579-04:00 hostname > postfix/submission/smtpd[1529]: send attr ident = submission:xxx.xxx.xxx.xxx > 2024-04-02T09:48:08.223857-04:00 hostname > postfix/submission/smtpd[1529]: private/anvil: wanted attribute: status > 2024-04-02T09:48:08.223987-04:00 hostname > postfix/submission/smtpd[1529]: input attribute name: status > 2024-04-02T09:48:08.224153-04:00 hostname > postfix/submission/smtpd[1529]: input attribute value: 0 > 2024-04-02T09:48:08.224389-04:00 hostname > postfix/submission/smtpd[1529]: private/anvil: wanted attribute: count > 2024-04-02T09:48:08.224565-04:00 hostname > postfix/submission/smtpd[1529]: input attribute name: count > 2024-04-02T09:48:08.224734-04:00 hostname > postfix/submission/smtpd[1529]: input attribute value: 1 > 2024-04-02T09:48:08.225001-04:00 hostname > postfix/submission/smtpd[1529]: private/anvil: wanted attribute: rate > 2024-04-02T09:48:08.225165-04:00 hostname > postfix/submission/smtpd[1529]: input attribute name: rate > 2024-04-02T09:48:08.225314-04:00 hostname > postfix/submission/smtpd[1529]: input attribute value: 1 > 2024-04-02T09:48:08.225465-04:00 hostname > postfix/submission/smtpd[1529]: private/anvil: wanted attribute: (list > terminator) > 2024-04-02T09:48:08.225610-04:00 hostname > postfix/submission/smtpd[1529]: input attribute name: (end) > 2024-04-02T09:48:08.225750-04:00 hostname > postfix/submission/smtpd[1529]: > xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]: 220 > hostname.example.com ESMTP > 2024-04-02T09:48:08.225896-04:00 hostname > postfix/submission/smtpd[1529]: smtp_stream_setup: maxtime=300 > enable_deadline=0 min_data_rate=0 > 2024-04-02T09:48:08.226037-04:00 hostname > postfix/submission/smtpd[1529]: watchdog_pat: 0x55810ef6a110 > 2024-04-02T09:48:08.293029-04:00 hostname > postfix/submission/smtpd[1529]: < xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]: EHLO > we-guess.mozilla.org > 2024-04-02T09:48:08.293161-04:00 hostname > 2024-04-02T09:48:08.293252-04:00 hostname > postfix/submission/smtpd[1529]: match_list_match: xxx.xxx.xxx.xxx: no match > 2024-04-02T09:48:08.293413-04:00 hostname > postfix/submission/smtpd[1529]: match_list_match: xxx.xxx.xxx.xxx: no match > 2024-04-02T09:48:08.293480-04:00 hostname > postfix/submission/smtpd[1529]: > xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]: > 250-hostname.example.com > 2024-04-02T09:48:08.293547-04:00 hostname > postfix/submission/smtpd[1529]: > xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]: > 250-PIPELINING >
[pfx] Re: Is there a way to just quickly deliver "everything" to a file somewhere
Dan Mahoney via Postfix-users: > 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? The local delivery agent comes to mind. It delivers to files or maildirs - It is the default setting for "local_transport". - It delivers by default to the system mail spool directory https://www.postfix.org/postconf.5.html#mail_spool_directory - It can deliver to the user's home directry https://www.postfix.org/postconf.5.html#home_mailbox And it can deliver to any file that is writable by the default user https://www.postfix.org/aliases.5.html https://www.postfix.org/postconf.5.html#default_privs https://www.postfix.org/local.8.html Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Thunderbird 91, Postfix 3.7.x, Debian 12, Virtual Mailbox Users, TLS with Letsencrypt, error improper command pipelining after helo
David Mehler via Postfix-users: > to utilize Thunderbird v91.x. I've tried configuring with both the > automatic configuration and the manual configuration, in both cases I am > getting an error in my maillog from submission/smtpd service stating > error improper command pipelining after helo. Googling showed this error Thunderbird pipelining errors after helo? People sometimes have improper command pipelining errors after *connect*, when - The Postfix SMTP server is configured in master.cf with smtpd_tls_wrappermode turned off (this is the usual configuration for connect to the submission service a.k.a. port 587). - The SMTP client is configured with smtpd_tls_wrappermode turned on (this is the usual configuration for clients that connect to the submissions service a.k.a. port 465). The client then starts talking befor the server expects that to happen. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: milter_mail_macros in master.cf for using rspamd
Martin Stenzel:
> Awesome, incredibly fast, you are awesome
> But, when I put this definition into master.cf (as you explained
> wisely (postfix is overwhelming, in a positive way)) the
> X-Spamd-Result header is missing.
>
> When I put it in main.cf, it works as expected. This is the part of
> master.cf which is in the _non-working_ config.
I suppose there is a configuration mistake...
> submission inet n - n - - smtpd
> -o syslog_name=postfix/submission
> -o smtpd_tls_security_level=may
> -o smtpd_sasl_auth_enable=yes
> -o smtpd_sasl_type=dovecot
> -o smtpd_sasl_path=private/auth
> -o smtpd_sasl_local_domain=$myhostname
> -o smtpd_sasl_security_options=noanonymous
> ...too much tls stuff...
> -o { smtpd_milters = inet:localhost:10099 inet:localhost:11332 }
> -o { non_smtpd_milters = inet:localhost:10099 inet:localhost:11332 }
> -o { milter_mail_macros = i {mail_addr} {client_addr} {client_name}
> {auth_authen} }
> -o milter_default_action=tempfail
Caution: output from "postconf -Mf" is preferred over hand-edited
listings, because humans do make mistakes.
DO review the output from "postconf -Mf" and compare it to what you
expect it to be.
Note that these apply to the submission (TCP port 587) service only.
Other mail flows, such as /usr/sbin/sendmail, are not covered.
There is no black magic in how master.cf settings take precedence
over main.cf settings.
If rspamd does not work in the exact same way with settings in
master.cf, as it does work with settings in main.cf, then the mistake
could be:
- There is some important main.cf setting that you forgot to move
into master.cf.
- There is some important main.cf setting that cannot be moved into
an smtpd -o option, because that setting is implemented by a different program.
- Your mail flow does not go through the submission service.
- You forgot to "postfix reload" .
- You forgot to watch the log for warnings.
> Maybe you wonder why I need to put it into master.cf?
>
> Because I have this entry in master.cf
>
> ---
>
> 10.4.0.2:10026 inet n - n - - smtpd
> -o content_filter=
> -o local_recipient_maps=
> -o relay_recipient_maps=
> -o smtpd_restriction_classes=
> -o smtpd_client_restrictions=
> -o smtpd_helo_restrictions=
> -o smtpd_sender_restrictions=
> -o smtpd_recipient_restrictions=permit_mynetworks,reject
> -o mynetworks=127.0.0.1,10.4.0.1,10.4.0.2
> ---
>
> If I put the milter entries into main.cf the milters get run twice,
> which obviously is not what is desirable.
I suppose that you could add "-o smtpd_milters=" there.
> This is my scenario
>
> https://www.ciphermail.com/documentation/gateway-administration-guide/network-architecture.html#content-scanner-with-redirect
>
Before diving into that, let's look for simple mistakes first.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: milter_mail_macros in master.cf for using rspamd
Martin Stenzel via Postfix-users:
> Hi group,
>
> I run rspamd on the same server in which the latest version of postfix
> runs on.
>
> Plus, there is ciphermail for the purpose of GPG signing.
>
>
> For rspamd functionality I have to define milter_mail_macros, but in
> master.cf, not in main.cf
>
> This is how the entry looks like
>
> -o
> milter_mail_macros=i,{mail_addr},{client_addr},{client_name},{auth_authen}
>
> master.cf does not "like" spaces.
It does, in Postfix 3.0 and later.
-o { milter_mail_macros = . }
Relevant text from https://www,postfix.org/master.5.html is below.
Wietse
Command name + arguments
...
-o { name = value } (long form, Postfix >= 3.0)
-o name=value (short form)
Override the named main.cf configuration parameter. The
parameter value can refer to other parameters as $name
etc., just like in main.cf. See postconf(5) for syntax.
...
NOTE 1: With the "long form" shown above, whitespace af-
ter "{", around "=", and before "}" is ignored, and
whitespace within the parameter value is preserved.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Fallback virtual_transport
Emmanuel Seyman via Postfix-users: > > Hello, all. > > I handle two SMTP gateways at $WORK which relay mail from the internet > to an internel server and vice-versa. Accordingly, I have > "virtual_transport = smtp:internal-host.example.com" in my main.cf . > > We recently had a network issue between the gateways and the internal > host, after which I was informed there was a fallback host the gateways > could still have reached. > > Can I specify a fallback nexthop in virtual_transport? MAYBE: virtual_transport = smtp:internal-host.example.com, other-host.example.com NOT: virtual_transport = smtp:internal-host.example.com, smtp:other-host.example.com Only the SMTP client allows multiple next-hop destinations. But a more native approach would be to use relaying: DNS: domain1 IN MX 10 your-server /etc/postfix/main.cf: relay_domains = domain1, ... releay_recipient_maps = ... transport:maps = hash:/etc/postfix/transport /etc/postfix/transport: domain1 smtp:internal-host.example.com, other-host.example.com Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Setting up another "smarthost" with Postfix
Cowbay via Postfix-users: > On 2024/3/28 00:25, Samuel Goodies via Postfix-users wrote: > > Hi guys. I'm inheriting a job that has an email server hosting several > > domains, and I'm wanting to move them behind our firewall and route mail > > from the main mail server to an offsite postfix server that will in turn > > send them out to wherever they need to go, kind of like my own homemade > > smarthost. Because of security we need to keep it all in house, so a paid > > smarthost isn't an option. This postfix server will only take mail from the > > server and send it out, and return bounce/errors to the main host. It won't > > accept any? incoming mail. > > > I'm a postfix user and try to image your plan. > > ___ >( ) > ( internet ) >(___) > ^ > | > v > __ > | MAIN MAIL SERVER | > ~~ > ^ > | > v > _ > // FIREWALL /// > ~ > ^ > | > v > > | OFFSITE POSTFIX SERVER | > >^ ^ >| | "send them out to wherever they need to go" >v v > [DOMAIN1] [DOMAIN2] "several domains" > > If this is what you said, then the "OFFSITE POSTFIX SERVER" is a relay only > mail server. The "several domains" are the destinations. > In the offsite server's master.cf, open the port 25 service smtp inet n - n - - smtpd In the offssite server's main.cf, permit relaying from your main mail server network(s) and reject mail from other systems. mynetworks = 10.0.1.1, ... smtpd_relay_restrictions = permit_mynetworks, reject In the main server's main.cf, send mail through the offssite server: relayhost = [name-of-offsite-server] Where the [] are used to suppress MX lookups. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Documentation update request
Ricardo F via Postfix-users: > > > Hello, > > I would like to suggest an addition to the documentation under > default_destination_rate_delay and default_destination_concurrency_limit > > As pointed in > https://mailing.postfix.users.narkive.com/yvG5ceqQ/balancing-destination-concurrency-rate-delay > > "As documented, rate_delay enforces a delay BETWEEN deliveries to > the same destination, and therefore, the concurrency to that > destination is always 1" > > So something like the following could be helpful and clear to > understand: > > With default_destination_rate_delay > 0, > default_destination_concurrency_limit is always 1. With one message per destination rate delay, why is that not obvious? Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Setting up another "smarthost" with Postfix
My reading is that this will be a sending only host: This postfix server will only take mail from the [main] server and send it out, and return bounce/errors to the main host. It won't accept any incoming mail. We should probably ask how they expect to be receiving mail, then. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Setting up another "smarthost" with Postfix
Samuel Goodies via Postfix-users: [ text/html is unsupported, treating like TEXT/PLAIN ] > Hi guys. I'm inheriting a job that has an email server hosting > several domains, and I'm wanting to move them behind our firewall > and route mail from the main mail server to an offsite postfix > server that will in turn send them out to wherever they need to > go, kind of like my own homemade smarthost. Because of security we > need to keep it all in house, so a paid smarthost isn't an option. > This postfix server will only take mail from the server and send > it out, and return bounce/errors to the main host. It won't accept > any incoming mail. > > Edit: I'll number these questions because wow they got out of > hand the more I stressed about completely breaking our email > serversHere goes...Bear with me please... > > 1. From what I've read there's not a 'smarthost' option in the > setup config. Would I just choose 'Internet Site'? Or does it > matter at all if I'm just going to monkey with the conf anyway? > You appear to be talking about some third-party configuration system (Zimbra? Mail-in-a-Box?) If so, then postfix-users may not be the right forum. Anyway, the Postfix main.cf file has the "relayhost" parameter for this purpose. Specify one of: relayhost = [hostname] relayhost = [hostname]:port The [] are required to turn off DNS MX lookups. The port is needed if you want to connect to a port other than the default (25, smtp). You may also specify a list relayhost = [hostname1], [hostname2] (ports are also allowed here). > 2. And regarding the conf, any tips to make this run smoothly > with minimal maintenance? > 3. And is there a way to keep logging to a minimum so it doesn't > fill up the server? No. Just rotate logs daily and you should be fine. > 4. Can I force it to use a different outbound port than 25 so I > can host it on the same machine that hosts our proxy server that > sends traffic to our main server? Covered under question 1. > 5. Our domains only send from 2 IPs, say 4.4.4.4 and 5.5.5.5, but > have 22 different domains they'll send from. Is there a way to > just filter relaying by IP address or would another form of > security be better? Firewall rules could take care of this (allow connections to TCP port 25 only from specific network blocks). > I apologize for all the questions. I'm not a real email guy. I'm > just a guy that fell into this job because everyone else was even > worse equipped to handle it than me. A step by step would surely > be appreciated. This may be more than you bargained for. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: check_policy_service for customizing routing & load balancing
Viktor Dukhovni via Postfix-users: > On Tue, Mar 26, 2024 at 02:20:55PM -0400, Wietse Venema via Postfix-users > wrote: > > Viktor Dukhovni via Postfix-users: > > > That's fine, the SRV records can be keyed by destination domain. > > > > Locally-managed SRV records, keyed by the final destination domain > > name, to select a local relay host? > > Yes. The only tricky part is getting the queries to go to the right > zone, which requires appending a suffix to the nexthop domain. This is a very clever approach based on configuration data in DNS and Postfix. Would a routing policy help here? I'm thinking of a declarative interface (like postfwd for access policies). This may require a non-blocking client that supports multiple outstanding requests. Wietse > So a socketmap transport lookup that maps: > > foo.example -> dnslb:foo.example.dnslb.local:smtp > > and a custom DNS authoritative server handling "dnslb.local" (or other > suitable suffix). > > To have separate load-balanced transport per-sender, one could have > > sender_dependent_transport: > example.com dnslb1 > example.net dnslb2 > ... > > And the socketmap would then leave the transport unchanged, and tweak > just the nexthop: > > foo.example -> :foo.example.dnslb.local:smtp > > Encoding both the sender domain and the recipient domain into a single > lookup, as with the policy service, is otherwise difficult, so if > all mail is single-recipient, one might use FILTER, and still SRV > lookups on the backend: > > sender domain: belongs to client1 > recipient = ...@example.net > > action = FILTER dnslb:example.net.client1.dnsbl.local > > Then the DNS server can parse out the destination and client id and do > as it pleases. > > -- > Viktor. > ___ > 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: check_policy_service for customizing routing & load balancing
Viktor Dukhovni via Postfix-users: > That's fine, the SRV records can be keyed by destination domain. Locally-managed SRV records, keyed by the final destination domain name, to select a local relay host? Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: check_policy_service for customizing routing & load balancing
Colin McKinnon via Postfix-users: > Hi, > > I want to provision load balancing for my relays. The catch is that > there is already some customized routing in place based on recipient > domain and large block lists. These are currently handled by a > transport map. > > I would prefer not to implement 2 layers of relays. If this were > implemented as a plugin which is told the recipient address it could > determine how the mail should be routed. But I need to ensure that I > don't create any loops - i.e. the routing decision is based on the > recipient AND where the email came from/via. > > The policy server (https://www.postfix.org/SMTPD_POLICY_README.html) > seems to be ideal for my requirements since I get both recipient_name > and helo_name, however the documentation only covers its use in the > context of 'smtpd_recipient_restrictions'. I tried provisioning using: Unfortunately, check_policy_service is documented and supported only for smtpd_mumble_restrictions. transport_maps queries one or more (key, value) stores. Given one key, it returns one corresponding value (or not found, or error). A policy is different: iy takes a list of (key, value) pairs, and returns a list of (key, value) pairs or error. What you are looking for does not yet exist in Postfix: a routing policy that takes a list of (client, helo, sender, recipient, etc.) and that returns (transport, nexthop, maybe recipient). This is a use case that the other open-source MTA may handle better. If routing policy were implemented in Postfix, its precedence should be chosen carefully. For non-local deliveries, the (transport, nexthop) are determined from the envelope recipient with the current set of routing features, in descending precedence: transport_maps, sender_dependent_default_transport_maps, default_transport, sender_dependent_relayhost_maps, relayhost. We could place the routing policy last (i.,e. highest precedence), and feed it the (client, helo, sender, recipient, etc.) from the message, plus the (transport, nexthop) as determined with the above current set of routing features. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Sending email via ipv4
Jack Raats via Postfix-users: > Hi, > > Can any help me. I want to recieve email via ipv4 and ipv6. main.cf: inet_protocols=ipv4,ipv6 as well as appropriate DNS MX and A records. > I want to send email via ipv6 only. master.cf: smtp .. .. .. .. .. .. smtp -o inet_protocols=ipv6 > I tried using smtp_address_preference = ipv6, but that didn't work. smtp_address_preference=ipv6 tells Postfix to try sending over IPv6 before trying IPv4. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: dane.sys4.de
Benny Pedersen via Postfix-users: > it go into endless loop if mx is missing, so it does not do a/ > failback testing, is this a bug ? What is 'it', what did you ask 'it' to do, and what are the concrete symptoms in the form of logging? Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Do I have to reload Postfix after the X.509 certificate (and key) file has been renewed?
TLS using processes will eventually pick up new certifictate info. A Postfix SMTP client and server process has a limited life time, bounded by max_idle (100s) and max_use (100 times). A tlsproxy process (used by postscreen, and by a Postfix SMTP client when reusing an SMTP-over-TLS connection) terminates voluntarily after being idle for max_idle (100s) or after max_idle*max_use seconds, whichever happens first. Thus, atomic updates are desirable (one file instead of multiple files) but "reload" will not be necessary for routine updates. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Why has smtpd_tls_cipherlist been deprecated?
Matthias Nagel via Postfix-users: > Hello everybody, > > what is the rationale behind the deprecation of the setting > `smtpd_tls_cipherlist`? Are there any plans to remove it entirely > in some future versions? smtpd_tls_cipherlist was removed in Postfix 2.3 (18 years ago). Postfix 2.9 (12 years ago) and later log "unused parameter: smtpd_tls_cipherlist" warnings. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix thinks smtp.gmail.com uses self-signed certificate
Cowbay via Postfix-users: > So, I will collect necessary information next time I encounter this > issue as what Viktor suggested. Please note that Postfix does not automatically use the "system" root CA store that openssl s_client and curl may use. That could result in verification differences between Postfix and other tools. https://www.postfix.org/postconf.5.html#tls_append_default_CA tls_append_default_CA (default: no) Append the system-supplied default Certification Authority certificates to the ones specified with *_tls_CApath or *_tls_CAfile. The default is "no"; this prevents Postfix from trusting third-party certificates and giving them relay permission with permit_tls_all_clientcerts. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix thinks smtp.gmail.com uses self-signed certificate
Unleess you can hand over the certificate that Postfix complained about, you have not proven that Postfix was in error. Specifically, yout tests with curl and openssl s_client may have used a different IP address than Postfix, because the smtp.gmail.com IP address changes frequently. The smtp.gmail.com A record has a TTL of 300s, but it changes every few seconds (it not only depends on when you ask, it also depends on where you are). Here is a small sample, asked from an IP address near New York city: Fri Mar 22 04:54:12 PM EDT 2024 172.253.62.109 Fri Mar 22 04:54:13 PM EDT 2024 172.253.62.109 Fri Mar 22 04:54:14 PM EDT 2024 172.253.62.108 Fri Mar 22 04:54:16 PM EDT 2024 172.253.62.109 Fri Mar 22 04:54:17 PM EDT 2024 172.253.62.108 Fri Mar 22 04:54:18 PM EDT 2024 172.253.62.108 Fri Mar 22 04:54:19 PM EDT 2024 172.253.62.108 Fri Mar 22 04:54:20 PM EDT 2024 172.253.62.109 Fri Mar 22 04:54:21 PM EDT 2024 172.253.62.109 Fri Mar 22 04:54:22 PM EDT 2024 172.253.62.108 Fri Mar 22 04:54:23 PM EDT 2024 172.253.62.108 Even if your tests did use the same IP address as Postfix, each connection may be serviced by a different backend behind a load balancer. Even if you connected to the same backend, its configuration may have changed. Like other providers, Google rolls out (SMTP) server updates frequently. It updates a few servers and if the error rate remains small it updates more servers, otherwise it rolls back the change. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: postfix and from
natan via Postfix-users: > 1. > FROM is encoded as "FRIENDLY_NAME " == encoding ==> "base64" That form is NOT VALID. For proper encoding, please see https://datatracker.ietf.org/doc/html/rfc2047#section-5 > 2. > FROM is encoded as "FRIENDLY_NAME " == encoding ==> > "base64 " That form is valid, as long as it follows RFC 2047 requirements. > This means that if the entire FROM content is encoded, "author's ticket > app" cannot read it. The email sending application is in error. It needs to be fixed to satisfy https://datatracker.ietf.org/doc/html/rfc2047#section-5 Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Don't BCC a particular domain
Richard Raether via Postfix-users: > Should I take out thee always_bcc in main.cf? Would this solution also > allow everything else to be BCC'd? Allsoo what would the line be if > "lists" were not in the domain name. I'm not familliar with the syntax. Use always_bcc if you want to copy all email messages. Use recipient_bcc_maps (and/or sender_bcc_maps) if you do want to copy selectively based on the recipient (and/or sender). I don't know what you need to exclude, so you need to adapt the example, or you need to provide *in direct email to me* the domain name(s) and/or email addresses that need to be excluded. Wietse > Excuse. my ignorance, > > Richard > > On 3/21/24 8:54 AM, Wietse Venema via Postfix-users wrote: > > Richard Raether via Postfix-users: > >> We have an auditor account where all incoming and outgoing mail is BCC'd > >> to, to retain for compliance reasons. However, since mailman retains its > >> own archives, and we have a mailman on a separate server with a separate > >> domain, is there a way to tell postfix DO bcc everything EXCEPT DON'T > >> bcc anything from this particular domain? BTW, the other machine uses > >> our mail server as a relay, which might make a difference. > > It is not possible with always_bcc (as the name suggests, it does > > make any distinction). > > > > It is possible if you use sender_bcc_maps and/or reciopient_bcc_maps. > > > > Example for recipient_bcc_maps, to exclude BCC copies for recipients > > that match anyth...@lists.example.com: > > > > /etc/postfix/main.cf: > > recipient_bcc_maps = pcre:/etc/postfix/recipient_bcc > > > > /etc/postfix/recipient_bcc: > > # DO NOT indent text between the IF and ENDIF lines! > > IF !/@lists\.example\.com$/ > > /./ ...auditor... > > ENDIF > > > > Wietse > > ___ > > 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 > ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Feature request
Ralf Hildebrandt via Postfix-users: > Hi! > > I wonder if this is possible: > > If a PCRE/regexp style map is triggering, it can be quite hard to > find out WHICH pattern actually caused the action. > > So maybe postmap (when invoked with "-b", "-h" or "-q key") could emit > which regular expression (or which line it was in) actually matched. > > Yes, I could give all my regular expressions patterns a unique RHS or > find the regular expressions by divide-et-impera, but I'm being lazy. After a rule is compiled, Postfix no longer has access to source information, especially when information is stored externally such as indexed files and LDAP or SQL databases. Source information could be maintained with the en-memory tables but that would add some bloat, and maybe disappoitment when some tables have source info some don't. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Don't BCC a particular domain
Richard Raether via Postfix-users: > We have an auditor account where all incoming and outgoing mail is BCC'd > to, to retain for compliance reasons. However, since mailman retains its > own archives, and we have a mailman on a separate server with a separate > domain, is there a way to tell postfix DO bcc everything EXCEPT DON'T > bcc anything from this particular domain? BTW, the other machine uses > our mail server as a relay, which might make a difference. It is not possible with always_bcc (as the name suggests, it does make any distinction). It is possible if you use sender_bcc_maps and/or reciopient_bcc_maps. Example for recipient_bcc_maps, to exclude BCC copies for recipients that match anyth...@lists.example.com: /etc/postfix/main.cf: recipient_bcc_maps = pcre:/etc/postfix/recipient_bcc /etc/postfix/recipient_bcc: # DO NOT indent text between the IF and ENDIF lines! IF !/@lists\.example\.com$/ /./ ...auditor... ENDIF Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Trouble with qmqp
Wietse Venema via Postfix-users: > Brad Koehn via Postfix-users: > > I'm trying to deliver email with Postfix 3.7.10 using `qmqpd`. > > Unfortunately when I do this, the email is often unreadable by a > > variety of email clients. > > I suppose you mean "receive" mail with Postfix using qmqpd. > > > Curiously, if I deliver the same email directly to Dovecot via > > LMTP, clients have no issue with the message. I expected the > > opposite to be the case: by bypassing all the cleanup functionality > > my emails would be harder to read. > > > > I'm early in my investigation, but I was wondering what might be > > going wrong? I notice for starters that the version I deliver via > > QMQP has the `Content-Length` header removed; th LMTP version > > preserves it. > > This is configurable with message_drop_headers (default: bcc, > content-length, resent-bcc, return-path). But I think you have worse > problems. > > > In another case, the QMQP version has an extra CRLF before the > > "This is a multi-part message in MIME format" text, which I believe > > makes it unrenderable; the LMTP version doesn;t have that extra > > line > > Your message is malformed: there was no empty line after the last > header line. When email is out-of-spec, it may not be delivered > in it malformed state. Your mention that Content-Length is somehow needed to make a message readable is another sign of trouble. I suspect that your message is not properly formatted as lines of text as requried for MIME formatted text: https://datatracker.ietf.org/doc/html/rfc2045#section-2.7 https://datatracker.ietf.org/doc/html/rfc2045#section-2.8 Again, there are no guarantess for "correct" delivery of email messages that violate the spec. This is another way of saying that the burden of proof is on you: show that a well-formed message is mis-handled by Postfix, with evidence in form of pcap files, hex dumps, or loss-less equivalents. Wietse that Postfix supports: 7bit and 8bitmime. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Trouble with qmqp
Brad Koehn via Postfix-users: > I'm trying to deliver email with Postfix 3.7.10 using `qmqpd`. > Unfortunately when I do this, the email is often unreadable by a > variety of email clients. I suppose you mean "receive" mail with Postfix using qmqpd. > Curiously, if I deliver the same email directly to Dovecot via > LMTP, clients have no issue with the message. I expected the > opposite to be the case: by bypassing all the cleanup functionality > my emails would be harder to read. > > I'm early in my investigation, but I was wondering what might be > going wrong? I notice for starters that the version I deliver via > QMQP has the `Content-Length` header removed; th LMTP version > preserves it. This is configurable with message_drop_headers (default: bcc, content-length, resent-bcc, return-path). But I think you have worse problems. > In another case, the QMQP version has an extra CRLF before the > "This is a multi-part message in MIME format" text, which I believe > makes it unrenderable; the LMTP version doesn;t have that extra > line Your message is malformed: there was no empty line after the last header line. When email is out-of-spec, it may not be delivered in it malformed state. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: smtpd filter orig_client
Reg Inaldo via Postfix-users: > > Hi > > I am seeing an issue with relaying and am looking for a way to filter on > a specific smtp line but can't find a way to make it work: > > In the transaction (eg):? mta-k postfix/smtpd[23771]: 97F808837: > client=localhost[127.0.0.1], orig_client=localhost[127.0.0.1] > > I want to reject anything on the "orig_client" basis where: > *orig_client**=localhost*[127.0.0.1] Use smtpd_milters (and non_smtpd_milters) instad of content_filter. Wietse > All of the standard submissions to the MTAs include the originating > server, eg:? client=localhost[127.0.0.1], > orig_client=m236-67.mailgun.net[159.135.236.67] > > The fact that they are all coming via 'client=localhost' makes it > difficult to just use that term. > > Any suggestions are welcomed. > > Thanks > > Reg > > ___ > 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: [PATCH] Drop removed -style option from html2text
Wietse Venema via Postfix-users: > Christian Goettsche via Postfix-users: > > On Mon, 11 Mar 2024 at 17:50, Wietse Venema wrote: > > > > > > Christian Goettsche via Postfix-users: > > > > html2text dropped the command line option -style in version 2[1]. > > > > > > I am not using that html2text version on the machine where I prepare > > > Postfix releases. I found that removing that flag makes the output > > > massively different. > > > > > > I need that documentation builds are reproducible. Otherwise, that > > > greatly affects the sizes of source-code diffs and patches. > > > > Maybe one could incorporate the "pretty" default values from > > https://github.com/grobian/html2text/blob/master/contrib/pretty.style > > into the bundled proto/html2text.rc? > > Someone who is more familiar with html2text could do that. But this > still would not address the need for reproducible documentation builds. > > Almost every improvement to html2text will change the result > (othewise, why bother :-), so that earlier results are no longer > reproducible, and diffs and patches will bloat. > > It's the same problem with code formatting: the indent tool has > imperfections, but the result needs to be reproducible otherwise > (bug or emergency) patches will bloat, and worse: they will fail > to apply when I need to rebase them to an earlier Postfix release. Just for due diligence I appended the pretty.style settings at the end of html2text.rc. With the existing html2text version on my release machine, that does not reproduce the existing results, for example, less leading space with items in unordered lists, and more leading space with block quotes. That in turn changes word wrapping. This is not a request to update the Postfix settings for the html2text version on the machine that builds documentation for releases, or to arrive at settings that reproduce existing output with a current html2text version. That would take hours away from the time that I want to spend on Postfix. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [PATCH] Drop removed -style option from html2text
Christian Goettsche via Postfix-users: > On Mon, 11 Mar 2024 at 17:50, Wietse Venema wrote: > > > > Christian Goettsche via Postfix-users: > > > html2text dropped the command line option -style in version 2[1]. > > > > I am not using that html2text version on the machine where I prepare > > Postfix releases. I found that removing that flag makes the output > > massively different. > > > > I need that documentation builds are reproducible. Otherwise, that > > greatly affects the sizes of source-code diffs and patches. > > Maybe one could incorporate the "pretty" default values from > https://github.com/grobian/html2text/blob/master/contrib/pretty.style > into the bundled proto/html2text.rc? Someone who is more familiar with html2text could do that. But this still would not address the need for reproducible documentation builds. Almost every improvement to html2text will change the result (othewise, why bother :-), so that earlier results are no longer reproducible, and diffs and patches will bloat. It's the same problem with code formatting: the indent tool has imperfections, but the result needs to be reproducible otherwise (bug or emergency) patches will bloat, and worse: they will fail to apply when I need to rebase them to an earlier Postfix release. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [PATCH] Drop removed -style option from html2text
Christian Goettsche via Postfix-users: > html2text dropped the command line option -style in version 2[1]. I am not using that html2text version on the machine where I prepare Postfix releases. I found that removing that flag makes the output massively different. I need that documentation builds are reproducible. Otherwise, that greatly affects the sizes of source-code diffs and patches. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Dumb question about logging
Viktor Dukhovni via Postfix-users: > On Sat, Mar 09, 2024 at 12:49:42PM +0100, Matus UHLAR - fantomas via > Postfix-users wrote: > > > In case of domains in relay_domains, the command could be even > > postfix/relay, so one needs to exclude that one as well. > > Actually, no, the "relay" transport is implemented by the smtp(8) > delivery agent, which uses "postfix/smtp" for log messages, regardless > of the transport name. As of Postfix 3.3, the "stock" master.cf file looks like this: relay unix - - n - - smtp -o syslog_name=postfix/$service_name Cheers, Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] Re: [OT] postfwd3 as check_policy_service hogging the CPU
Matus UHLAR - fantomas via Postfix-users: > On 07.03.24 12:14, Wietse Venema via Postfix-users wrote: > >The Postfix SMTP server counts only the recipients that it accepts, > >not the ones that it rejects. > > > >That is, a DATA or BDAT command after all recipients are rejected > >will result in a "554 5.5.1 Error: no valid recipients". > > So I guess there is no way for a milter/policy server to know about > rejected recipients (other than parsing log file)? > > e.g. the DCC milter would report total count of recipients (including > rejected/non-existing) to DCC servers. Basic principle: Postfix sends only the SMTP commands and message content that Postfix has not rejected. The exception is the "unknown command" event in the Milter protocol. This prevents that Postfix and Milter get out of step, for example when Postfix rejects something and the Milter accepts it. Both Postfix and Milters (or the libmilter library) have ideas of what to expect next, and I control only the Postfix expectations. Changing this on the Postfix side after almost 20 years is risky. There must be Milters that have only talked to Postfix. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: preserving multi line header_checks REPLACE
Viktor Dukhovni via Postfix-users: > On Fri, Mar 08, 2024 at 03:45:42PM -0500, Wietse Venema via Postfix-users > wrote: > > > The postmap command reads input from stdin one line at a time, and > > applies each input line to all the header_checks patterns. It can't > > be used for multiline inputs. > > Time has passed, and you've forgotten that you implemented "postmap -hq -". > :-) Indeed, I was using pre-2.6 syntax. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: preserving multi line header_checks REPLACE
Mailinglists35 via Postfix-users: > > Hi > > I run a postfix 3.5.9 smtp relay for a webserver that sends user signup and > forgot password emails. That's the only use case and the server does not > receive any other emails and neither generates any locally. > > I'm trying to prevent leaking internal information (hostname & IP) in > Received header. If the use case is sending "signup" and "reset" email messages, you cuold drop all Received: headers that match your pattern (the pattern can then be simplified because it only needs to look at the first line). But wait, there is more. > For this, I've setup `smtp_header_checks = regexp:/etc/postfix/header_checks` > with the contents: > > /^(Received: from \[127\.0\.0\.1\] \(web\d\w+ > \[\d+\.\d+\.\d+\.\d+\]\))((.|\n|\t)*)/m REPLACE Received: from > email.domain.tld (email.domain.tld. [1.2.3.4])$2 > The postmap input looks like this: > > echo -e"Received: from [127.0.0.1] (web1dev [10.11.12.13])\n\tby > email.domain.tld (Postfix) with ESMTPS id C9056 >7E002\n\tfor ; Fri,8 Mar 2024 19:20:29 +0200 (EET)" > | postmap -q - pcre:/etc/postfix/header_checks >Received: from [127.0.0.1] (web1dev [10.11.12.13]) REPLACE Received: > from email.domain.tld (email.domain.tld. [1.2.3.4]) > > What I am doing wrong? The postmap command reads input from stdin one line at a time, and applies each input line to all the header_checks patterns. It can't be used for multiline inputs. However, it can handle multiline input when used like this, but the details may be bash specific. $ cat header_checks /^Received: from \S+ \(web\d\w+ [^)]+\)(.+)/m REPLACE Received: from email.domain.tld (email.domain.tld. [1.2.3.4])$1 input=$(echo -e "Received: from [127.0.0.1] (web1dev [10.11.12.13])\n\tby email.domain.tld (Postfix) with ESMTPS id C90567E002\n\tfor ; Fri, 8 Mar 2024 19:20:29 +0200 (EET)") $ postmap -q "$input" pcre:header_checks REPLACE Received: from email.domain.tld (email.domain.tld. [1.2.3.4]) by email.domain.tld (Postfix) with ESMTPS id C90567E002 for ; Fri, 8 Mar 2024 19:20:29 +0200 (EET) It took me a while to figure that out. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Dumb question about logging
Stephen Satchell via Postfix-users: > Assuming that one's configuration has open relay, what does a log entry > for relayed mail look like? > > I don't think I've any open relay, but I want to look and make sure. > > I've searched for half an hour, and no answer came up. But, I did find > some hints. Specifically, I use this command to list all outgoing mail: > > > grep relay= mail.log | grep -v relay=local As Mathus noted, that is the remote MX host. You are safe if 1 - You have no other rules between permit_mynetworks, permit_sasl_authenticated, and reject_unauth_destination. Examples: smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination smtpd_recipient_restrictions = ...other rules... permit_mynetworks permit_sasl_authenticated reject_unauth_destination ...other rules... 2 - You have no wildcards in $mydestination, $virtual_alias_domains, or $relay_domains. If you want to detect open relay problems after the fact from logging, you need something like "collate.pl" (included in the Postfix source tarball), which groups records that belong to the same message, then delete the groups that are safe: 3 - Delete record groups with deliveries for local submissions (with logging from the "pickup" but this gets complicated if you use a "simple pipe plus sendmail" based content filter because you should not delete record groups with "pickup ... uid=xxx" that match the content filter. 4 - Delete record groups with deliveries from authorized clients (logging that has "sasl_user=username"). 5 - Delete record groups with deliveries to authorized destinations (match the domains in $mydestination, $virtual_alias_domains, or $relay_domains). What remains could be unauthorized relaying. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Misunderstanging on masquerade_domains and rewriting in master.conf
Steffen Nurpmeso via Postfix-users: > What if i would have multiple smtpd listening on different xy and > each needs different settings? Would i need different main.cf's > for each of those? > And you say the local_header_rewrite_clients at least i can > specifiy via -o, if i understand correctly. I think so. The SMTP server uses local_header_rewrite_clients to determine whether the addres rewriting context is local or remote. The result is used by cleanup and by some delivery agents. The sendmail command-line submission claims that the addres rewriting context is local, unless the -G option is given (as it is in basic post-queue Postfix content filter examples). Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Active queue congestion
Colin McKinnon via Postfix-users: > Thank you, Viktor. > > I am planning to look at increasing the size of the Active queue however I > would need to resize to a minimum of 50x based on past events. That should be OK as long as your syustem has enough memory. > > You can also configure a non-zero smtpd_client_message_rate_limit > > H, not so sure about that. The docs do advise against this for > legitimate traffic - and I've yet to see anything in the documentation that > describes what happens when these rates are exceeded is it a 4xx? a 5xx? Is > the IP just blocked? It does not interact well when the client is an MTA as it messes up scheduling and can result in huge delays. If the clients are human-operated MUAs then that would not apply. postfix does not reject mail that exceeds the limit (WTF?) but it returns a 4xx status. Wietse > I now know that the config settings do not do what I expected - which is > unfortunate as this would have been a very simple solution. > > > you could use a policy service to impose rate limits per SASL login, or > sender address > > I had not considered that as a means of load balancing across the available > relays (delaying the message at the origin is very much a last resort). I > will do some reading on this. > > C. > > On Thu, 7 Mar 2024 at 13:46, Viktor Dukhovni via Postfix-users < > postfix-users@postfix.org> wrote: > > > On Thu, Mar 07, 2024 at 12:26:06PM +, Colin McKinnon via Postfix-users > > wrote: > > > > > I look after a SAAS site where customers can send emails to their own > > > domains. At times some of our customers can initiate sending of large > > mail > > > volumes - which can swamp the active queue. > > > > Given sufficient memory, you can substantially raise the active queue > > size limit. Servers have a lot more RAM now than they did in 2001. > > The default of 20,000 could easily be raised by 10x to 20 on a > > server-class machine. > > > > If customers indeed send mail only to their own domain, the destination > > concurrency limits should ensure fairness, given sufficient space in the > > queue and sufficiently many delivery agent slots. > > > > Speaking of delivery agent slots, if you have enough network bandwidth, > > you can raise the smtp(8) delivery process limit in master.cf from 100 > > to 1000: > > > > smtp unix - - n - 1000smtp > > > > Not that this could require some system-dependent tuning of the open > > file hard limit in whatever code starts Postfix, if the limit is not > > already very generous (on a Fedora 39 system with 65GB RAM, "ulimit -Hn" > > reports ~1.8 million max open files). > > > > > >From [1]: > > > "The only way to reduce congestion is to either reduce the input rate or > > > increase the throughput. Increasing the throughput requires either > > > increasing the concurrency or reducing the latency of deliveries." > > > > I am suggesting increasing concurrency, and also increasing the queue > > depth to allow your customer to send larger bursts of mail without > > overflowing the queue size limit. You can also configure a non-zero > > > > smtpd_client_message_rate_limit > > > > if abuse of your resources is plausible even with the larger queue size. > > If that's too crude, you could use a policy service to impose rate > > limits per SASL login, or sender address, ... > > > > > I thought that reducing TRANSPORT_recipient_refill_limit and > > > TRANSPORT_recipient_limit would prevent messages sent to the customers > > > domain from dominating the active queue / prevent blocking of other > > > customers / backup messages in the incoming queue. > > > > These controls affect deliveries of single messages with many > > recipients, but have no effect on a flood of single-recipient messages. > > > > -- > > Viktor. > > ___ > > Postfix-users mailing list -- postfix-users@postfix.org > > To unsubscribe send an email to postfix-users-le...@postfix.org > > > > > -- > -BEGIN GEEK CODE BLOCK- > Version: 3.1 > GCM d s+:+ a+ C+++(---)$ UL+++ P+(--) L+++ E--- W+++ N++ w-- PS++(+++()) > t+ 5+ X R- tv-- b++ DI++ D e+++ h > --END GEEK CODE BLOCK-- > ___ > 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: [ext] Re: [OT] postfwd3 as check_policy_service hogging the CPU
Ralf Hildebrandt via Postfix-users: > * Viktor Dukhovni via Postfix-users : > > > Note that if you want the actual recipient addresses, (not just a > > count), > > I just need the count in this case > > > you'll need to also intercept recipient restrictions. > > oh! > > > The Postfix smtpd(8) server does not keep the recipient list in memory, the > > list is streamed out into the queue file (really cleanup service or > > pre-queue proxy filter). The Postfix SMTP server counts only the recipients that it accepts, not the ones that it rejects. That is, a DATA or BDAT command after all recipients are rejected will result in a "554 5.5.1 Error: no valid recipients". Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Postfix stable release 3.9.0
[An on-line version of this announcement will be available at
https://www.postfix.org/announcements/postfix-3.9.0.html]
Postfix stable release 3.9.0 is available. Postfix 3.5 - 3.8 were
updated earlier this week; after that, Postfix 3.5 will no longer
be updated.
The main changes are below. See the RELEASE_NOTES file for further
details.
Removed functionality:
* As described in DEPRECATION_README, the SMTP server features
"permit_naked_ip_address", "check_relay_domains", and
"reject_maps_rbl" have been removed, after they have been logging
a warning for some 20 years. These features now log a warning
and return a "server configuration error" response.
* The MySQL client no longer supports MySQL versions < 4.0. MySQL
version 4.0 was released in 2003.
Officially obsolete functionality:
* As covered in DEPRECATION_README, the configuration parameter
"disable_dns_lookup" and about a dozen TLS-related parameters
are now officially obsolete. These parameters still work, but
the postconf command logs warnings that they will be removed
from Postfix.
* As covered in DEPRECATION_README, "permit_mx_backup" logs a
warning that it will be removed from Postfix.
Changed functionality:
* In message headers, Postfix now formats numerical days as
two-digit days, i.e. days 1-9 have a leading zero instead of a
leading space. This change was made because the RFC 5322 date
and time specification recommends (i.e. SHOULD) that a single
space be used in each place that folding white space appears.
This change avoids a breaking change in the length of a date
string.
* The MySQL client default characterset is now configurable with
the "charset" configuration file attribute. The default is
"utf8mb4", consistent with the MySQL 8.0 built-in default, but
different from earlier MySQL versions where the built-in default
was "latin1".
New functionality:
* Support to query MongoDB databases, contributed by Hamid Maadani,
based on earlier code by Stephan Ferraro. See MONGODB_README
and mongodb_table(5)
* The RFC 3461 envelope ID is now exported in the local(8) delivery
agent with the ENVID environment variable, and in the pipe(8)
delivery agent with the ${envid} command-line attribute.
* Configurable idle and retry timer settings in the mysql: and
pgsql: clients. A shorter than default retry timer can sped up
the recovery after error, when Postfix is configured with only
one server in the "hosts" attribute. After the code was frozen
for release, we have learned that Postfix can recover faster
from some errors when the single server is specified multiple
times in the "hosts" attribute.
* Optional Postfix TLS support to request an RFC7250 raw public
key instead of an X.509 public-key certificate. The configuration
settings for raw key public support will be ignored when there
is no raw public key support in the local TLS implementation
(i.e. Postfix with OpenSSL versions before 3.2). See RELEASE_NOTES
for more information.
* Preliminary support for OpenSSL configuration files, primarily
OpenSSL 1.1.1b and later. This introduces two new parameters
"tls_config_file" and "tls_config_name", which can be used to
limit collateral damage from OS distributions that crank up
security to 11, increasing the number of plaintext email
deliveries. Details are in the postconf(5) manpage under
"tls_config_file" and "tls_config_name".
Attack resistance:
* With "smtpd_forbid_unauth_pipelining = yes" (the default),
Postfix defends against multiple "blind" SMTP attacks. This
feature was back-ported to older stable releases but disabled
by default.
* With "smtpd_forbid_bare_newline = normalize" (the default)
Postfix defends against SMTP smuggling attacks. See RELEASE_NOTES
for details. This feature was back-ported to older stable
releases but disabled by default.
* Prevent outbound SMTP smuggling, where an attacker uses Postfix
to send email containing a non-standard End-of-DATA sequence,
to exploit inbound SMTP smuggling at a vulnerable remote SMTP
server. With "cleanup_replace_stray_cr_lf = yes" (the default),
the cleanup daemon replaces each stray or character
in message content with a space character. This feature was
back-ported to older stable releases with identical functionality.
* The Postfix DNS client now limits the total size of DNS lookup
results to 100 records; it drops the excess records, and logs
a warning. This limit is 20x larger than the number of server
addresses that the Postfix SMTP client is willing to consider
when delivering mail, and is far below the number of records
that could cause a tail recursion crash in dns_rr_append() as
reported by Toshifumi Sakaguchi. This also introduces a similar
limit on the number of DNS requests that a
[pfx] Re: Milter multiline header formatting
Claus Assmann via Postfix-users: > On Wed, Mar 06, 2024, Wietse Venema via Postfix-users wrote: > > > > Again, Postfix does not store line terminators, not when email comes > > > from UNIX tool with \n, via SMTP with \r\n, or encapsulated as > > > netstrings which uses neither. > > > In headers that Postfix sends to a milter. I may want to change that > > or at least make it configurable with an appropriate default. > > AFAICT the libmilter docs define the line endings: > > libmilter/docs/xxfi_header.html > > |headerv |Header field value. The content of the header may > | > ||include folded white space, i.e., multiple lines > | > ||with following white space where lines are > separated| > ||by LF (not CRLF). The trailing line terminator > | > ||(CRLF) is removed. > > Changing that would probably break compatibility for milters. > > > I just checked what happens with bodies. There, the Postfix Milter > > client is hard coded to send lines ending in "\r\n". > > libmilter/docs/xxfi_body.html > > * End-of-lines are represented as received from SMTP (normally CRLF). Thanks. I was searching online, and could have found it in the sendmail source. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: improving SRS support
Viktor Dukhovni via Postfix-users: > On Wed, Mar 06, 2024 at 07:30:01PM -0500, Christophe Kalt via Postfix-users > wrote: > > > The two options I've seen for implementing SRS are milter and > > [sender_]canonical_maps but it seems to me that neither are a good fit when > > rewriting the envelope From as they happen early on (smtpd and cleanup > > specifically) and before Postfix knows where the mail is going. > > > > That's a bit of a problem as rewriting the sender only makes sense if the > > mail is being sent over SMTP (and even then, it would be great to have more > > control as it is not always desirable). Looking for another option, the > > closest seems to be smtp_generic_maps except that it rewrites both envelope > > and header Froms. > > > > I suspect this could easily be adjusted with a new smtp_generic_classes > > parameter (similar to [sender_]canonical_classes) ? > > Yes, but I'm somewhat concerned about lack of "orthogonality" of > features. What if one wants both generic mapping of interal addresses > in headers, and SRS for remote envelopes? > > Perhaps SRS should be using a feature that (like virtual aliases for > recipient addresses) transforms only the envelope sender address and > does not preclude generic(5) rewriting? SRS is really an 'output' dependent rewrite. So an additional envelope.from mapping may be needed for (some) delivery agents. Generic in its current form pre-dates message signing. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Milter multiline header formatting
Wietse Venema via Postfix-users: > Again, Postfix does not store line terminators, not when email comes > from UNIX tool with \n, via SMTP with \r\n, or encapsulated as > netstrings which uses neither. > > Instead, Postfix generates line terminators upon output, and until > now they are always \n. In headers that Postfix sends to a milter. I may want to change that or at least make it configurable with an appropriate default. I just checked what happens with bodies. There, the Postfix Milter client is hard coded to send lines ending in "\r\n". Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: improving SRS support
Christophe Kalt via Postfix-users: > Hi, > > The two options I've seen for implementing SRS are milter and > [sender_]canonical_maps but it seems to me that neither are a good fit when > rewriting the envelope From as they happen early on (smtpd and cleanup > specifically) and before Postfix knows where the mail is going. > > That's a bit of a problem as rewriting the sender only makes sense if the > mail is being sent over SMTP (and even then, it would be great to have more > control as it is not always desirable). Looking for another option, the > closest seems to be smtp_generic_maps except that it rewrites both envelope > and header Froms. > > I suspect this could easily be adjusted with a new smtp_generic_classes > parameter (similar to [sender_]canonical_classes) ? This location in the message flow seems right to me. And we already have an example for implementing an address rewriting _classes feature. This can even be configured in master.cf if one also needs to send messages with non-SRSed envelope.from, for example to internal systems. I won't have time for new code in the coming weeks. But if someone can contribute then I'll look at it. Wietse ___ 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
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. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Milter multiline header formatting
Steffen Nurpmeso via Postfix-users:
> Wietse Venema via Postfix-users wrote in
> <4tqh100n6pzj...@spike.porcupine.org>:
> |Are you trying to say that Postfix represents a multiline message
> |header as text with \n instead of \r\n?
>
> Yes.
>
> |That is very well possible. Postfix strips \n and \r\n line terminators
> |on input, and the MIME parser synthesizes multiline headers with
> |\n boundaries thusly, before they are sent to header_checks or
> |Milter:
> |
> |if (IS_SPACE_TAB(*text)) {
> |if (LEN(state->output_buffer) < var_header_limit) {
> |vstring_strcat(state->output_buffer, "\n");
> |vstring_strncat(state->output_buffer, text, len);
> |
> |That code was written years before Postfix Milter support and DKIM
> |plugins.
> |
> |I agree that \r\n would be better, but I'm surprised that this has
> |not come up before.
>
> Maybe other MUAs create valid emails with only CRLF when passing
> over to the MTA, or simply do not use line continuation when the
> email is to be passed to the MTA.
> Plus DKIM is maybe not used widely by the my-MUA-is-a-shell-script
> folks yet.
Every Received: header is multiline, and it is not unusual to have
multiline Subject:, To:, and other common headers.
Again, Postfix does not store line terminators, not when email comes
from UNIX tool with \n, via SMTP with \r\n, or encapsulated as
netstrings which uses neither.
Instead, Postfix generates line terminators upon output, and until
now they are always \n.
Postfix systems have been signing with Milters since Postfix Milter
support was added in 2006. I'm just surprised that the non-canoncal
line endings in a multiline header have not been a problem before.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: SOLVED: Escaping of braces {} in configuration (master(5))
Are you trying to say that Postfix represents a multiline message
header as text with \n instead of \r\n?
That is very well possible. Postfix strips \n and \r\n line terminators
on input, and the MIME parser synthesizes multiline headers with
\n boundaries thusly, before they are sent to header_checks or
Milter:
if (IS_SPACE_TAB(*text)) {
if (LEN(state->output_buffer) < var_header_limit) {
vstring_strcat(state->output_buffer, "\n");
vstring_strncat(state->output_buffer, text, len);
That code was written years before Postfix Milter support and DKIM
plugins.
I agree that \r\n would be better, but I'm surprised that this has
not come up before.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: dmarc reports from Microsoft (possibly off topic)
Alan Munday: > As of the 22 Feb 2024 I have been seeing invalid MAIL FROM address from > Microsoft: > > In: MAIL FROM: XATTRDIRECT=Originating > XATTRORGID=xorgid:96f9e21d-a1c4-44a3-99e4-37191ac61848 Wietse: > When I send the above as one line into Postfix, the response is: > > 555 5.5.4 Unsupported option: XATTRDIRECT=Originating There is no need for Postfix workarounds, they have rolled out a fix. https://techcommunity.microsoft.com/t5/exchange/microsoft-dmarc-aggregate-report-smtp-issues/m-p/4072531 Wietse >/etc/postfix/main.cf: >smtpd_command_filter = pcre:/etc/postfix/command_filter > >/etc/postfix/command_filter: ># Work around clients that send XATTRDIRECT or XATTRORGID ># when Postfix announces no such support in the EHLO response. >/^(MAIL FROM:\s*<.*>.*)\s+XATTRDIRECT=\S+\s+XATTRORGID=\S+(.*)/ $1$2 > > This pattern seems to work with light testing. Do not omit the (.*) > at the end of the pattern, or the $2 in the result. These are for > supported options that they might send after XATTRORGID. > > Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: dmarc reports from Microsoft (possibly off topic)
Alan Munday via Postfix-users: > As of the 22 Feb 2024 I have been seeing invalid MAIL FROM address from > Microsoft: > > In: MAIL FROM: XATTRDIRECT=Originating > XATTRORGID=xorgid:96f9e21d-a1c4-44a3-99e4-37191ac61848 > > Clearly an issue with line termination, but one I have yet to find > reported online. Postfix "chat history" will fold long lines for readability (note that there is only one "In:" above). When I send the above as one line into Postfix, the response is: 555 5.5.4 Unsupported option: XATTRDIRECT=Originating And Postfix is correct. The Postfix EHLO response does not announce support for XATTRDIRECT or XATTRORGID, therefore the client must not send such arguments in MAIL FROM. There is no second "554" reponse (for XATTRORGID) because that would break SMTP. If this is a problem then you could use smtpd_command_filter to remove these options. /etc/postfix/main.cf: smtpd_command_filter = pcre:/etc/postfix/command_filter /etc/postfix/command_filter: # Work around clients that send XATTRDIRECT or XATTRORGID # when Postfix announces no such support in the EHLO response. /^(MAIL FROM:\s*<.*>.*)\s+XATTRDIRECT=\S+\s+XATTRORGID=\S+(.*)/ $1$2 This pattern seems to work with light testing. Do not omit the (.*) at the end of the pattern, or the $2 in the result. These are for supported options that they might send after XATTRORGID. Wietse > I have seen a couple of reports where the Reporting Organization is set > to "Enterprise Outlook" but none from "Outlook.com" > > Has anyone else seen this behaviour and could this be related to SMTP > smuggling? Huh? Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: SOLVED: Escaping of braces {} in configuration (master(5))
Wietse Venema via Postfix-users:
> The text should have said:
>
> Other command-line arguments
> Specify "{" and "}" around command arguments that must start
> with "{" or that must contain whitespace (Postfix 3.0 and
> later). These outer "{" and "}" are removed from the input,
> together with any leading or trailing whitespace.
>
> Basically, Postfix strips one level of {} around any command-line
> argument that starts with "{".
>
> In that light, if you want "{daemon_name},sign", you need to specify
> {{daemon_name},sign} like this:
>
> dkim-sign unix - n n - 0 spawn
> user=_postfix_xlocal argv=/tmp/s-dkim-sign
> --milter-macro-sign {{daemon_name},sign}
> --key rsa-sha256,rsa,/tmp/pri-rsa.pem
Or, as you're using "long" options:
dkim-sign unix - n n - 0 spawn
user=_postfix_xlocal argv=/tmp/s-dkim-sign
--milter-macro-sign={daemon_name},sign
--key=rsa-sha256,rsa,/tmp/pri-rsa.pem
should also be valid.
In this form, no argument starts with "{", and you can avoid the
extra "{" and "}"
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] SOLVED: Escaping of braces {} in configuration (master(5))
Wietse Venema via Postfix-users:
> With this in master.cf:
>
> dkim-sign unix - n n - 0 spawn
> user=_postfix_xlocal argv=/tmp/s-dkim-sign
> --milter-macro-sign {daemon_name},sign
> --key rsa-sha256,rsa,/tmp/pri-rsa.pem
>
> These are options to a non-Postfix program, so I need to investigate
> why the syntax parser is treating it as Postfix syntax.
This behavior was introduced on 20140927, and it is partially
documented in the master(5) manpage.
Other command-line arguments
Specify "{" and "}" around command arguments that contain
whitespace (Postfix 3.0 and later). Whitespace after"{"
and before "}" is ignored.
The text should have said:
Other command-line arguments
Specify "{" and "}" around command arguments that must start
with "{" or that must contain whitespace (Postfix 3.0 and
later). These outer "{" and "}" are removed from the input,
together with any leading or trailing whitespace.
Basically, Postfix strips one level of {} around any command-line
argument that starts with "{".
In that light, if you want "{daemon_name},sign", you need to specify
{{daemon_name},sign} like this:
dkim-sign unix - n n - 0 spawn
user=_postfix_xlocal argv=/tmp/s-dkim-sign
--milter-macro-sign {{daemon_name},sign}
--key rsa-sha256,rsa,/tmp/pri-rsa.pem
I'll update the manpage text.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Postfix stable release 3.8.6, and legacy releases 3.7.11, 3.6.15, 3.5.25
[An on-line version of this announcement will be available at https://www.postfix.org/announcements/postfix-3.8.6.html] This is the first regular update after the SMTP smuggling episode. As the last regular update was early November, this update is larger than usual. Fixed with Postfix 3.8.6, 3.7.11, 3.6.15, 3.5.25: * Bugfix (defect introduced: Postfix 2.3, date 20051222): the Dovecot auth client did not reset the 'reason' from a previous Dovecot auth service response, before parsing the next Dovecot auth server response in the same SMTP session, resulting in a nonsensical "authentication failed" warning message. Reported by Stephan Bosch. * Bugfix (defect introduced: Postfix 3.1, date: 20151128): "postqueue -j" produced broken JSON when escaping a control character as \u. Found during code maintenance. * Cleanup: this fixes posttls-finger certificate match expectations for all TLS security levels, including warnings for levels that don't implement certificate matching. By Viktor Dukhovni. * Bugfix (defect introduced: Postfix 2.3): after prepending a header at the top of a message (with an access(5), header_checks(5) or Milter action), the Postfix Milter "delete header" or "update header" action was skipping the prepended header, instead of skipping the Postfix-generated Received: header. Problem report by Carlos Velasco. * Workaround: tlsmgr logfile spam. Reportedly, some OS lies under load: it says that a socket is readable, then it says that the socket has unread data, and then it says that read returns EOF, causing Postfix to spam the log with a warning message. * Bugfix (defect introduced: Postfix 3.4): the SMTP server's BDAT command handler could be tricked to read $message_size_limit bytes into memory. Found during code maintenance. * Safety: limit the total size of DNS lookup results to 100 records; drop the excess records, and log a warning. This limit is 20x larger than the number of server addresses that the Postfix SMTP client is willing to consider when delivering mail, and is far below the number of records that could cause a tail recursion crash in dns_rr_append() as reported by Toshifumi Sakaguchi. This fix also limits the number of DNS requests that a check_*_*_access restriction can make. * Performance, related to the previous problem: eliminate worst-case behavior where the queue manager could defer delivery to all destinations over a specific delivery transport, after only a single delivery agent crash. The scheduler now throttles deliveries to one destination, and allows other deliveries to keep making progress. You can find the updated Postfix source code at the mirrors listed at https://www.postfix.org/. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Escaping of braces {} in configuration (master(5))
With this in master.cf:
dkim-sign unix - n n - 0 spawn
user=_postfix_xlocal argv=/tmp/s-dkim-sign
--milter-macro-sign {daemon_name},sign
--key rsa-sha256,rsa,/tmp/pri-rsa.pem
These are options to a non-Postfix peogram, so I need to investigate
why the sytnax parser is treating it as Postfix syntax.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
