[pfx] Re: TLS for SMTP Outbound -- Only One tlsproxy

[Viktor Dukhovni via Postfix-users]

On Thu, May 23, 2024 at 05:48:29PM -0400, Wietse Venema via Postfix-users wrote:

> 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?

Indeed those multiples of 5s sure feel like DNS lookup delays.  Unclear
why this would correlated with enabling TLS connection reuse, I'd
conjecture that's not the case, and that similar delays would also be
seen for non-TLS connections to the same destination.

It is also unclear whether the delays are the OP's systems looking up
Google's addresses, or Google's systems looking up the OP's reverse and
forward DNS, though when I query Quad8 DNS for the OP's MTA, the
response is prompt.

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Wed, May 22, 2024 at 11:27:15PM -0500, Scott Techlist via Postfix-users 
wrote:

> >All of these entries are using the LOGIN mech.  Unless you have an
> >extremely old outlook express MUA (or similar) you xan and should be
> >using the PLAIN mech.  You can eliminate all of the above attacks by
> >removing LOGIN from the list of mechs you accept.
> 
> Peter:
> 
> I too see a lot of these so I went to try your solution.  I edited 
> /etc/sasl2/smtpd.conf  
> It now contains:
> 
> pwcheck_method: saslauthd
> #mech_list: plain login
> mech_list: plain

That's for *Cyrus* SASL, but since you mention "dovecot", perhaps you're
using "dovecot" SASL, check your "smtpd_sasl_type" parameter setting.

Dovecot has its own mechanism list, while Postfix has a mechanism list
filter.  You should be able to set:

smtp_sasl_mechanism_filter = plain

or, in dovecot.conf, set:

auth_mechanisms = plain

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Wed, May 22, 2024 at 12:19:03PM -0500, Greg Sims wrote:

>   [root@mail01 postfix]# postconf -nf
>   maximal_backoff_time = 16m
>   minimal_backoff_time = 2m
>   queue_run_delay = 2m

FWIW (not related to your immediate issue) I would not recommend such a
short maximal backoff, you're potentially filling the active queue with
messages that will again tempfail , and perhaps take a long time to do
so.  I typically go with:

minimal_backoff_time = 225s
maximal_backoff_time = 7200s
queue_run_delay = 225s

>   sender_dependent_default_transport_maps =
>   regexp:/etc/postfix/sender_relay.regexp, randmap:{t121,t122,t123,t124}

See below...


>   smtp_tls_security_level = may
>   smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
>   smtp_tls_CApath = /etc/pki/tls/certs

The CAfile and CApath are not needed (just waste memory) until you set
something other than "may" as the security level for at least some
destinations.

>   smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem
>   smtpd_tls_key_file = /etc/pki/tls/private/postfix.key
>   smtpd_tls_security_level = none

The certificates are not needed while the security level is "none".

>   [root@mail01 postfix]# postconf -Mf
> ...
>   t121   unix  -   -   n   -   64  smtp
>   -o smtp_bind_address=209.73.152.121
>   -o smtp_helo_name=mail01-t121.raystedman.org
>   -o syslog_name=t121
>   t122   unix  -   -   n   -   64  smtp
>   -o smtp_bind_address=209.73.152.122
>   -o smtp_helo_name=mail01-t122.raystedman.org
>   -o syslog_name=t122
>   t123   unix  -   -   n   -   64  smtp
>   -o smtp_bind_address=209.73.152.123
>   -o smtp_helo_name=mail01-t123.raystedman.org
>   -o syslog_name=t123
>   t124   unix  -   -   n   -   64  smtp
>   -o smtp_bind_address=209.73.152.124
>   -o smtp_helo_name=mail01-t124.raystedman.org
>   -o syslog_name=t124

I think the reason that "collate" is not working is your chose of
"syslog_name", it does not match any of the expected forms:

postfix
postfix-instance
postfix/sometag
postfix-instance/sometag

The Perl RE in question is:

my $instre = qr{(?x)
\A  # Absolute line start
(?:\S+ \s+){3}  # Timestamp, adjust for other time formats
\S+ \s+ # Hostname
(postfix(?:-[^/\s]+)?)  # Capture instance name stopping before 
first '/'
(?:/\S+)*   # Optional non-captured '/'-delimited 
qualifiers
/   # Final '/' before the daemon program name
};


On Wed, May 22, 2024 at 02:10:48PM -0500, Greg Sims wrote:

> Postfix is now configured for logging at /var/log/postfix.
>   * added to main.cf:
>   maillog_file = /var/log/postfix/0522zh.log
>   * added to master.cf
>postlog   unix-dgram n  -   n   -   1   postlogd

Good.

> I then:
> 
>   [root@mail01 0522zh]# perl ../collate.pl 0522zh.log >0522zh.log.collate
>   [root@mail01 0522zh]# ll
>   total 95M
>   -rw-r--r-- 1 root root 2.5M May 22 11:38 0522zh.log
>   -rw-r--r-- 1 root root  92M May 22 11:55 0522zh.log.collate
> 
> The output of collate does not appear to be useful -- it is the same
> as when we are logging to memory.

It fails to matcht he delivery agent log entries.

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Wed, May 22, 2024 at 08:15:41AM -0500, Greg Sims via Postfix-users wrote:

> I am having problems with "collate".  I greped a 10 minute portion of
> our mail.log which created a 6.8M file. I ran "collate" on this file
> and collected the output -- a 796M file.  I looked at the file and it
> seems to be filled with records like the following:

Collate produces blank-line-terminated records, one per input message,
showing all the work associated with delivering that message to all
its recipients.  If there are any partially processed messages in
the input, the corresponding "incomplete" records are output last.

Here's a typical example:

May 22 21:12:44 amnesiac postfix/pickup[3455088]: B46358DF27A: uid=1000 
from=
May 22 21:12:44 amnesiac postfix/cleanup[3455782]: B46358DF27A: 
message-id=
May 22 21:12:44 amnesiac postfix/qmgr[2546418]: B46358DF27A: 
from=, size=2652, nrcpt=1 (queue active)
May 22 21:12:48 amnesiac postfix/smtp[3455784]: Verified TLS connection 
established to list.sys4.de[188.68.34.52]:25: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature 
ECDSA (secp384r1) server-digest SHA384
May 22 21:12:49 amnesiac postfix/smtp[3455784]: B46358DF27A: 
to=, relay=list.sys4.de[188.68.34.52]:25, delay=4.9, 
delays=0.08/0.01/4/0.74, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 
4VkpYG01YKzybg)
May 22 21:12:49 amnesiac postfix/qmgr[2546418]: B46358DF27A: removed

The "log level 1" TLS diagnostic message is included, even though it
does not list the queue-id, it was matched by process name and pid.

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:

main.cf:
maillog_file = /var/log/postfix/log

$ ls -ld /var/log/postfix{,/*}
drwxrwxr-x. 2 root postdrop   47 May 22 23:40 /var/log/postfix
-rw---  1 root root  226 May 22 23:40 /var/log/postfix/log
-rw---  1 root postdrop 25747944 May 22 23:40 
/var/log/postfix/log.20240522-234048.gz

See https://www.postfix.org/MAILLOG_README.html and note that rotation
does not (yet) delete old files, that's up to your cron job.

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Wed, May 22, 2024 at 05:35:25AM -0500, Greg Sims wrote:

> Thank you again for your feedback on this issue.

You're welcome, but I don't see anything in your reply that responds
directly to my requests for more detailed configuration and log data.

> I watched the workload in real time this morning and now have more
> insight into what is happening.  It appears the large ISPs are using
> TLS connection as a way to throttle incoming traffic.

That conclusion seems hasty.  The delays could be for any number of
reasons other than deliberate tarpitting, and it is not clear why such
tarpitting would be TLS-specific.

> I looked at the inbound mail queue and found most of the traffic going
> to gmail.com.  I believe this is because of the 20 & 25 seconds delays
> google.com is injecting into the TLS connection.

To properly understand what is happening, you should first run "collate"
and see if that adds sufficient detail to pin down the delays, and if
not, then "smtp -v", and look for possible "RSET" timeouts.  Perhaps
Gmail drops idle TLS connections faster than Postfix's 2s cache timeout?

Did you by any chance tweak the smtp/scache connection cache timeouts?
Longer timeouts risk the remote end closing the connection first, which
then causes problems trying to reuse it, ... and so raising the idle
timeouts can be rather counterproductive...

I'd be surprised if Google's front-end load-balancers drop TLS sessions
much faster than cleartext connections, ... but first you need to
determine what's happening during those 20s, for which more detailed
logging is needed, with "collate" being the simplest to try.

You may need to tweak the code slightly to match the date format used
by your log server.

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Tue, May 21, 2024 at 08:31:51AM -0500, Greg Sims wrote:

> Changes:
>   * certs back to defaults
>   * smtp_tls_loglevel = 1

Better.  Now it is time to post a more detailed transcript of a single
message (the sender and recipient addresses can be obfuscated if you
wish, the recipient domain would ideally stay untouched).

See:

https://github.com/vdukhovni/postfix/tree/master/postfix/auxiliary/collate

> 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

As noted by Wietse that 25s "connection setup" time is the source of the
problem, but it might represent more than one connection attempt, as it
is the time from the beginning of the delivery attempt to the start of
the mail transaction that delivered that envelope recipient, and so if
there are multiple connections attempted (or DNS lookup issues, ...)
this would include the associated latency.

A complete message history (for one such message) from "collate" may
show some of the associated activity.  You should also check for
any relevant related logs from "tlsproxy".

If that's still not illuminating, it may be helpful to run at least one
smtp(8)-based transport in verbose mode ("-v" flag in master.cf), and
to see all the activity that went on behind the scenes.

Also, do you have a TLS client session cache configured?

I have:

smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

this can substantially speed up TLS handshakes with the remote servers,
and perhaps also avoid running into potential (speculative) TLS session
creation rate limits.

Have you changed any of the SMTP client timeouts?  DNS aside, the only
significant timeout that is south of 20s is:

smtp_rset_timeout = 20s

which is relevant because the first command to sanity-check a cached
connection is "RSET", which is issued just before starting the new mail
transaction.  If for some reason the remote servers are tarpitting
"RSET", that could be the source of the problem.

This is perhaps a good time to ask you for your full configuration,
not just cherry-picked individual settings.  Please post the outputs of:

$ postconf -nf
$ postconf -Mf

with all whitespace (including linebreaks) preserved.

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Tue, May 21, 2024 at 06:51:08AM -0500, Greg Sims via Postfix-users wrote:

> Our main.cf contains:
>   smtpd_tls_cert_file = 
>   smtpd_tls_key_file  = 
>   smtpd_tls_security_level = none

There's no point in configuring SMTP server certificates when TLS is
disabled in the SMTP server.  If the idea is to make tlsproxy(8)
"happy", then try: "smtpd_tls_cert_file = none" and leave the key file
setting at its default empty value.

>   smtp_tls_security_level  = may

Fine.

> We have used connection caching in the past so we added:
>   * smtp_tls_connection_reuse=yes

Presumably, you also have "smtp_connection_cache_on_demand = yes".

>   * uncommented tlsproxy / maxproc = 0 in master.cf
>   * commented smtp_tls_loglevel -- no logging as a result

Level 1 is recommended when TLS is enabled.  The additional logging
overhead is quite modest.

> The outbound message transfer rate of our configuration is less than
> 500 emails per minute.  I noted the following:
>
>   * we have four entries in master.cf for smtp -- each has a
> unique ip address with maxproc=32; these are used with randmap{} in
> main.cf

Fine.

>   * queuing of inbound email is high
> * the inbound email queue contains over 3,000 emails

So that's ~6 minutes of backlog...  Plausibly due to downstream rate
and/or concurrency limits

> * email average delay is over 400 seconds and 1,100
> seconds for google.com where most of the email is delivered

If the backlog isn't growing, can you post the averages of the
delays=a/b/c/d components?

>   * htop shows
> * cpu utilization is low with Load average under 0.10 on
> four physical processors and 4GB memory / 500MB used

CPU was unlikely to be the problem.

> * only one tlsproxy process running -- the highest cpu
> utilization process most of the time

Fine.  More would be spawned if it got too busy to serve client requests
in a timely manner.

> * 20 processes exist for each of our four ip address/smtp
> entries in master.cf with maxproc=32
> 
> I am concerned that the queuing of inbound email is caused by there
> only being one tlsproxy process.

More plausibly the real issue is message delivery latency to the various
destinations.

> maxproc=0 seems to allow for an unlimited number.  We seem to have
> plenty of smtp processes as postfix is not starting more of them to
> reach the maxproc=32.

You could configure separate tlsproxy(8) services for each of the
smtp(8) transports by overriding "tlsproxy_service_name" in master.cf,
that will give you multiple tlsproxy(8) processes, but I guessing won't
change much, if the issue is downstream delays.

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Tue, May 21, 2024 at 08:33:58AM +0100, Adam Weremczuk via Postfix-users 
wrote:

> When I email "bugzi...@mydomain.com" from another account I get "Recipient
> address rejected: User unknown in local recipient table".

If you want this to not happen, see:

https://www.postfix.org/postconf.5.html#local_recipient_maps
https://www.postfix.org/LOCAL_RECIPIENT_README.html

> "May 20 12:05:10 mailserver postfix/local[18768]: EF55B2C022E:
> to=, relay=local, delay=0.92, delays=0.04/0/0/0.88,
> dsn=2.0.0, status=sent (delivered to command:
> /vol/localhome/bugzilla/site/live/email_in.pl -vvv 2>/tmp/bz_emailin.log)"
> 
> Now, I want to modify this configuration and deliver that email to
> email_in.pl located on another host (not locally).

See "DELIVERY METHOD CONTROLS" in , in 
particular
note that delivery to local users is subject to .forward file
processing.

DELIVERY METHOD CONTROLS

   The  precedence  of  local(8)  delivery  methods  from  high to low is:
   aliases,  .forward  files,  mailbox_transport_maps,  mailbox_transport,
   mailbox_command_maps,  mailbox_command, home_mailbox, mail_spool_direc-
   tory, fallback_transport_maps, fallback_transport, and luser_relay.

   alias_maps (see 'postconf -d' output)
  Optional lookup tables with aliases that apply only to  local(8)
  recipients;  this is unlike virtual_alias_maps that apply to all
  recipients: local(8), virtual, and remote.

   forward_path (see 'postconf -d' output)
  The local(8) delivery agent search list for finding  a  .forward
  file with user-specified delivery methods.
   ...

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: recipient_canonical works for orig_to in mydomain but not for orig_to in other.domain

[Viktor Dukhovni via Postfix-users]

On Mon, May 13, 2024 at 11:56:30AM +0200, Peter Uetrecht via Postfix-users 
wrote:

> I have a working multi-instance setup with Postfix version 3.8.4 What
> surprises me is that “recipient_canonical” works for some recipients
> but not for all.  It seems that "recipient_canonical" works for
> orig_to recipients in "mydomain", while it does not work for orig_to
> recipients in "other.domain".
> 
> # postconf -c /etc/postfix-common/ -nf
> ...
> recipient_canonical_maps = pcre:/etc/postfix-common/recipient_canonical
> ...
> /etc/postfix-common/recipient_canonical
> /recipient@host.mydomain/   recipient@subdomain.mydomain
> /recipient@other.domain/recipient@subdomain.mydomain

These RE patterns sorely need "^" and "$" anchors, as well as "\"
escaping of literal "." characters.

> /var/log/maillog
> 2024-05-13 11:05:46 smtp01 postfix-common/smtpd[2085384]: NOQUEUE: reject:
> RCPT from unknown[10.127.0.14]: 554 5.7.1 :
> Recipient address rejected: Access denied; from=
> to= proto=SMTP helo=<10.127.0.14>

Access(5) rules are processed early, prior to address rewriting, and
have nothing to do with accepting or rejecting of the original recipient
address by the smtpd(8) service.  You have a "REJECT" rule matching this
recipient, or all recipients in this domain.

> 2024-05-13 11:05:46 smtp01 postfix-common/smtpd[2085384]: using
> backwards-compatible default setting
> smtpd_relay_before_recipient_restrictions=no to reject recipient
> "recipient@other.domain" from client "unknown[10.127.0.14]"

Possibly via a legacy late application of "smtpd_relay_restrictions".

I repeat, canonical mappings have nothing to do with this.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: TLS Library Problem

[Viktor Dukhovni via Postfix-users]

On Sat, May 11, 2024 at 11:55:14PM -0400, Jason Hirsh via Postfix-users wrote:

> I have they error message
> 
> postfix/smtps/smtpd[39559]: warning: TLS library problem:
> error:14094416:SSL routines:ssl3_read_bytes:
> sslv3 alert certificate unknown:
> /usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:1621:
> SSL alert number 46:

The remote client was unable to validate your certificate.
MUAs connecting to port 465 typicall expect a trusted certificate.

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Sun, May 12, 2024 at 03:59:27AM +0200, Steffen Nurpmeso via Postfix-users 
wrote:

> Well here i am indeed back again, to announce
> 
>   v0.6.1, 2024-05-12:
> - Adds the algorithm big_ed-sha256 which effectively is RFC 8463
>   (aka ed25519-sha256), but performs three digest operations where
>   only two are needed.
>   We keep our two-digest ed25519-sha256 "as-is".
>   (If the big players do not start to support RFC 8463 by fall 2024,
>   i will propose a draft xed25519-sha256 which changes the algorithm
>   accordingly.)
> 
> Ie, the ed25519 keys etc can remain the same and everything, but
> in order to generate ed25519 keys as of RFC 8463, use
> "key big_ed-sha256" instead of "key ed25519-sha256".
> This gives DKIM success for you.

This is not a productive direction.  Please implement only algorithms
that are specified in a published standards track RFC.  Nobody benefits
from ad-hoc non-interperable DKIM signature schemes that just create
confusion.

Your "big_ed-sha256" is just a correct implementation of "ed25519-sha256",
and should be the only choice offered.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Different SMTP access/relay control for ipv4 vs ipv6?

[Viktor Dukhovni via Postfix-users]

On Sun, Apr 28, 2024 at 05:31:21PM -0700, Peter via Postfix-users wrote:

> The ideal end goal would be to use the same general set of controls as
> v4, but to start off I would like to use a more permissive/less
> restrictive set of controls, and initially only enable v6 for
> receiving (as that's where I anticipate the majority of the issues).

Actually, you should not expect more issues while receiving IPv6 mail,
that's typically rather mundane.  On the contrary, the issues you're
more likely to see are with *sending* outbound mail over IPv6, where
some major provider receiving systems are *more* strict (requiring
DKIM, SPF, ...) with IPv6 clients.[

> I'm not entirely sure how to do this, so I am seeking recommendations &
> guidance.

Just turn on inbound IPv6 with the same rules as IPv4, there's no need
to do anything special.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: private/dovecot-lmtp]: Connection refused)

[Viktor Dukhovni via Postfix-users]

On Sat, May 11, 2024 at 11:11:30AM +0200, Benny Pedersen via Postfix-users 
wrote:

> > I am running Postfix/Dovecot/MySQL mail server.   It was doing ok
> > until I tried to improve it., I
> 
> maybe just reboot ? :)

Unlikely to help.  Just restarting dovecot would be about the most
that's needed, but more likely, configuring dovecot correctly, and
then a "systemctl reload dovecot".  There's nothing to suggest the
kernel needs a restart.

> > I am pretty sure I did something wromnhg with TLS/SSL.   Ai was
> > working in certificates,   I have been at the so long my eye are
> > crossed
> 
> in most cases postfix have sanitises settings pr default, so when you add
> unsanitises settings in main.cf you asking for knowledge why its changed

This makes no sense.

> > smtpd_sasl_auth_enable = yes
> 
> remove this in main.cf

Irrelevant.

> > Any ideas or pointers or random thoughts would be appreciated
> 
> world is not random

But one does sometimes run into random advice...

-- 
Viktor.
___
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.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: private/dovecot-lmtp]: Connection refused)

[Viktor Dukhovni via Postfix-users]

On Fri, May 10, 2024 at 08:47:26PM -0400, Jason Hirsh via Postfix-users wrote:

> I am running Postfix/Dovecot/MySQL mail server.   It was doing ok
> until I tried to improve it.

Reverting back to the "unimproved" prior state may be the best course of
action.

> May 10 20:11:27 triggerfish postfix/lmtp[47754]: 172816542AC3: 
> to=, orig_to=, relay=none, delay=38307, 
> delays=38307/0.01/0/0, dsn=4.4.1, status=deferred (connect to 
> triggerfish.theoceanwindow.com[private/dovecot-lmtp]: Connection refused)

The Dovecot LMTP delivery agent is not listening on the

/var/spool/postfix/private/dovecot-lmtp

unix-domain socket.  Either that's not the right path, or there's a
problem on the dovecot side.

> I am pretty sure I did something wrong with TLS/SSL.

Certainly not on the Postfix side, but perhaps dovecot is expecting to
find a working certificate and private key for that service, and that's
why it is not up and running.  However, with a unix-domain socket, in
the access-restricted "private/" directory there's really not much point
in TLS certs.  You should configure dovecot LMTP to not bother with TLS.

Ai was working in certificates,   I have been at the so long my eye are crossed

> root@triggerfish:/home/jason # postconf -n

Nothing to see here.  The issue is not in the Postfix configuration.

> Any ideas or pointers or random thoughts would be appreciated

The issue is on the dovecot side, and you should seek help on the
dovecot list, rather than here.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: recipient_bcc_maps with multi-instance

[Viktor Dukhovni via Postfix-users]

On Fri, May 10, 2024 at 09:47:31PM -0400, Alex via Postfix-users wrote:

> Hi, I'm using postfix-3.7.9 multi-instance on fedora38 and can't figure out
> why always_bcc and recipient_bcc_maps aren't working on the outbound
> instance.
> 
> 127.0.0.1:10025 inet n-   n   -   16smtpd
> -o content_filter=
> -o smtpd_delay_reject=no
> -o smtpd_client_restrictions=permit_mynetworks,reject
> -o smtpd_helo_restrictions=
> -o smtpd_sender_restrictions=
> -o smtpd_recipient_restrictions=permit_mynetworks,reject
> -o smtpd_data_restrictions=reject_unauth_pipelining
> -o smtpd_end_of_data_restrictions=
> -o smtpd_restriction_classes=
> -o mynetworks=127.0.0.0/8,209.111.90.0/24
> -o smtpd_error_sleep_time=0
> -o smtpd_soft_error_limit=1001
> -o smtpd_hard_error_limit=1000
> -o smtpd_client_connection_count_limit=0
> -o smtpd_client_connection_rate_limit=0
> -o 
> receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters,no_address_mappings

   ---
> -o local_header_rewrite_clients=

BCC generation is an address mapping.

-- 
Viktor.


___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Cleanup service adds unexpected characters when replacing header

[Viktor Dukhovni via Postfix-users]

On Tue, May 07, 2024 at 10:07:15AM +0200, Denis Krienbühl via Postfix-users 
wrote:

> Ultimately, I ended up with the following rule, but I have a problem with it 
> (or any other that I've found):
> 
> /^\s*Received:[^\n]+(.*)/  REPLACE Received: from 
> [127.0.0.1] (localhost [127.0.0.1])$1

That "\s*" is best left out.

> This works just fine with postmap:
> 
> cat mail.txt | postmap -h -q - pcre:/etc/postfix/auth_header_checks.pcre
 
> postconf -P
> 
> smtps/inet/cleanup_service_name = privacy_cleanup
> privacy_cleanup/unix/header_checks = 
> regexp:/etc/postfix/auth_header_checks.pcre
   --

I hope those underlines make the problem clear.

> /etc/postfix/auth_header_checks.pcre
> 
> /^\s*Received:[^\n]+(.*)/  REPLACE Received: from [127.0.0.1] 
> (localhost [127.0.0.1])$1

Instead:

/^Received:[^\n]+(.*)/  REPLACE Received: from [127.0.0.1] (localhost 
[127.0.0.1])$1

-- 
Viktor.
___
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?

[Viktor Dukhovni via Postfix-users]

On Mon, May 06, 2024 at 11:37:54AM +0200, Дилян Палаузов via Postfix-users 
wrote:

> My reading is that a domain in virtual_alias_domains can be mentioned
> neither in virtual_mailbox_domains nor as mydestination domain.

Correct, note however, that *all* recipients are subject to virtual(5)
alias rewriting, regardless of the domain, or even whether the domain is
delivered locally or is hosted remotely, by someone else.  It is NOT
necessary to list a domain in virtual_alias_domains just to enable
rewriting.

> What can be put in virtual_alias_domain, when virtual_mailbox_domain
> and mydestination are set?

Unsurprisingly, actual virtual alias domains, that are therefore not
local domains (mydestination) or virtual mailbox domains, ...
The various address classes are disjoint, each domain belongs to at most
one class.

It is fine to have no virtual alias domains, or to have one or more.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Fun with line endings, was Re: Mail text wrapping

[Viktor Dukhovni via Postfix-users]

On Sun, Apr 28, 2024 at 07:15:38PM -0700, Doug Hardie wrote:

> > I suppose, but sending bare LF in SMTP is definitely wrong, so he needs to
> > fix that first.
>
> Well, the header lines are properly terminated by CRLF.  However, the
> text lines are whatever I get from postfix.  Generally that is just a
> LF.  I copied the text and inserted the CRs and sent it to see what
> happens.  I get the same result: = signs at each fold point.

Postfix is NOT an MUA.  It delivers MIME bodies with their original
Content-Transfer-Encoding.  It is wrong to expect Postfix to convert
MIME bodies from quoted-printable to some other encoding.  Your problem
is that whatever is consuming the message is not implemented to handle
MIME correctly.  Some day the content may arrive as Base64, which won't
be "fixed" by converting "=LF" to spaces.  You need a MIME parser, not
a kludge.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Enforce TLS in smtp client sender based?

[Viktor Dukhovni via Postfix-users]

On Fri, Apr 26, 2024 at 07:21:24AM +0200, Tobi via Postfix-users wrote:

> Or would it be possible to use a sender_dependent_relayhost_maps and
> define just the transport ex smtps: (without nexthop) in there so
> postfix would use that transport (to be defined in master.cf) and the
> normal MX of recipient domain? 

See sender_dependent_default_transport_maps, which is the more
fully-featured analogue of sender_dependent_relayhost_maps,
which is therefore no longer needed.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: IMPORTANT, drop "resolve [!UNAVAIL=return]" from Linux nsswitch.conf files

[Viktor Dukhovni via Postfix-users]

On Wed, Apr 24, 2024 at 07:23:00PM +0200, Kim Sindalsen via Postfix-users wrote:

> > Regardless, as things stand, the default Fedora 39 nsswitch.conf
> > makes Postfix restrictions much too fragile, and needs to be
> > avoided.
> 
> files dns is standard on my installation (Gentoo Linux/OpenRC)

Congratulations, your OS distribution did not default to a poor choice
(at least for Postfix) of nsswitch.conf.

> https://man.archlinux.org/man/nss-resolve.8.en seems to say that the
> order should be: mymachines resolve [!UNAVAIL=return] files myhostname

Yes, and that advice is bad for applications that need to distinguish
between hard and soft lookup errors.

> when using/utilizing systemd-resolved - dunno if that changes anything
> really though.

As explained in my posts upthread, following that advice results in
Postfix intermittently rejecting (5XX) legitimate client IPs, that
should have been deferred (4XX) as a result of a transient lookup
glitch.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: IMPORTANT, drop "resolve [!UNAVAIL=return]" from Linux nsswitch.conf files

[Viktor Dukhovni via Postfix-users]

On Wed, Apr 24, 2024 at 07:43:35AM +0200, Reto via Postfix-users wrote:
> On Mon, Apr 22, 2024 at 03:50:34PM GMT, Viktor Dukhovni via Postfix-users 
> wrote:
> > and this (specifically, !UNAVAIL=return) turns soft DNS failures into
> > hard errors.
> > 
> > The solution, on any production mail server, is to remove (with
> > prejudice)
> > 
> > resolve [!UNAVAIL=return]
> 
> This doesn't sound right...
> All that says is once you've gotten a response from systemd-resolve that the 
> lookup
> chain should end, which, if it's actually running, is what you want.
> As the lookup via DNS already happened there after all, there's no reason to 
> repeat it.
> 
> It doesn't have an impact whatsoever on soft vs hard fail, resolve either 
> gives you the
> domain after the lookup or whatever response it got from the upstream server 
> (DNS or what have you).

Whether or not it sounds right, it happens to to be true that "return"
yields a "hard" no such host, even when the last service used
tempfailed.  One might reasonably consider this a glibc bug, but perhaps
they have some use-case to justify this behaviour.

Regardless, as things stand, the default Fedora 39 nsswitch.conf makes
Postfix restrictions much too fragile, and needs to be avoided.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Fun with line endings, was Re: Mail text wrapping

[Viktor Dukhovni via Postfix-users]

On Wed, Apr 24, 2024 at 01:01:46AM -, John Levine via Postfix-users wrote:

> >I must be interpreting this wrong because it appears postfix is not
> >accepting that.  Here is the complete process.  A message arrives at
> >my MTA addressed to a specific address.  Postfix delivers that
> >message to a pipe to my process which reads the pipe and stores
> >everything in a file.  Portions of the text of that message are
> >extracted and then sent using SMTP to port 25 on my MTA with new
> >recipients. ...
> 
> Oh, there's your problem. If you are talking directly to an SMTP
> server, you have to use SMTP line endings \r\n rather than the \n used
> in files on Unix systems.

Maybe, but perhaps this is too literal a reading of the OP's anecdotal
description of the message handling.  One might equally expect that the
problem is with some parser of the message content not expecting to decode
quoted-printable MIME bodies.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Mail text wrapping

[Viktor Dukhovni via Postfix-users]

On Tue, Apr 23, 2024 at 11:46:22AM -0700, Doug Hardie via Postfix-users wrote:

> > RFC 3676 addresses this.
> 
> That was an amazing and helpful response.  RFC 2045 showed exactly
> what caused the problem.  When the message was delivered to a file,
> the CRLFs were replaced by \n.  An = followed by a \n is not a valid
> soft return.  I am going to have to parse the text and fix that.

In a quoted-printable MIME body that is stored in a UNIX mailbox file,
"=" *is* a soft line break.  Your MIME parser  should treat it as
such, accepting not only "=", but also "=".

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] IMPORTANT, drop "resolve [!UNAVAIL=return]" from Linux nsswitch.conf files

[Viktor Dukhovni via Postfix-users]

The isi.edu DNS nameservers were apparently being DoSed today, and
reverse and forward lookups (from my MX host) were failing.  I was
however surprised to then see:

postfix/smtpd[2530673]: NOQUEUE: reject: RCPT from unknown[128.9.29.254]:
550 5.7.1 Client host rejected: cannot find your reverse hostname, 
[128.9.29.254];
from=
to= proto=ESMTP helo=

This should have been a soft error, but with recent-enough Fedora (I
have 39), the default nsswitch.conf has:

hosts:  files myhostname resolve [!UNAVAIL=return] dns

and this (specifically, !UNAVAIL=return) turns soft DNS failures into
hard errors.

The solution, on any production mail server, is to remove (with
prejudice)

resolve [!UNAVAIL=return]

from the "hosts" nsswitch.conf entry.  If you don't want to randomly
reject mail when there's a brief network glitch, your MUST simplify
nsswitch.conf to:

hosts:  files myhostname dns

or even just:

hosts:  files dns

-- 
Viktor.
___
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.

-- 
Viktor
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Is there a way to just quickly deliver "everything" to a file somewhere

[Viktor Dukhovni via Postfix-users]

On Sat, Apr 13, 2024 at 11:14:34AM -0400, Dan Mahoney wrote:

> >>>   virtual_alias_maps = static:allmail@$mydomain
> >>>   default_transport = virtual
> >>>   virtual_mailbox_maps = static:/var/spool/virtual/allmail/
> >>>   virtual_uid_maps = static:12345
> >>>   virtual_gid_maps = static:12345
> 
> I’ve dropped this in, changing only 12345 to the “nobody” UID (65534 on BSD), 
> rather than a UID that doesn’t exist.
> 
> This fails for me with:
> 
> postfix/virtual[3806]: fatal: bad string length 0 < 1: virtual_mailbox_base =
> 
> I’ve chown'd /var/spool/virtual/allmail to that UID/GID of course.

Indeed, you need:

virtual_mailbox_base = /var/spool/virtual
virtual_mailbox_maps = static:allmail/

A detail I overlooked.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Is there a way to just quickly deliver "everything" to a file somewhere

[Viktor Dukhovni via Postfix-users]

On Wed, Apr 10, 2024 at 11:39:24PM -0400, Dan Mahoney via Postfix-users wrote:

> > On Apr 2, 2024, at 10:52, Viktor Dukhovni via Postfix-users 
> >  wrote:
> > 
> > On Tue, Apr 02, 2024 at 04:14:29AM -0400, Dan Mahoney via Postfix-users 
> > wrote:
> >> Hey there all,
> >> 
> >> I’m setting up a staging version of dayjob’s ticket system, and we’d 
> >> basically like postfix to still function, but instead of touching the 
> >> internet at all, just deliver everything to a single file (or a maildir, I 
> >> suppose), regardless of if a file is invoked via sendmail, or a port 25 
> >> connection.  I’d like nothing to leave the box.
> >> 
> >> Is there some kind of transport hack I can use for this?

Complete recipe was posted, quoted below:

> ># No local(8) delivery
> >#
> >alias_database =
> >mydestination =
> >local_transport = error:5.1.2 Mailbox unavailable
> > 
> ># No locally hosted domains, but you may want to set one of these
> ># non-empty to accept mail over SMTP, if mail comes in from outside,
> ># but this could also be via submission, permit_mynetworks, ...
> >#
> >relay_domains =
> >virtual_alias_domains =
> >virtual_mailbox_domains =
> > 
> ># Collapse all recipients to a single address, delivered to a single
> ># maildir.
> >#
> >enable_original_recipient = no
> >virtual_alias_maps = static:allmail@$mydomain
> >default_transport = virtual
> >virtual_mailbox_maps = static:/var/spool/virtual/allmail/
> >virtual_uid_maps = static:12345
> >virtual_gid_maps = static:12345
> 
> I guess I missed something. — I also want it to null route (or route
> to a maildir) all *outbound* mail — so we can examine what our ticket
> system *would* send, is there something in here to do that, or is the
> above only for inbound?

I see no disclaimer that this would only cover "inbound" or "outbound"
mail.  Rather, I see "default_transport = virtual", which sends *all*
mail to the maildir.  Once mail is in the queue it is simply mail to be
delivered, there is no "inbound" or "outbound" when making transport
decisions.

What the recipe comments doe is that the above configuration does not
accept any inbound mail as written, you'd need to allow some clients to
inject mail via SMTP either to "inbound" domains, by e.g. adding some to
"virtual_alias_domains" or "virtual_mailbox_domains" (same result either
way).  Or via "smtpd_recipient_restrictions" to allow some clients to
send mail (just adding them to "mynetworks" would typically suffice).

Your reluctance to test this is puzzling.  Read it, try to understand
it, test it, tweak as needed, repeat.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: old TLS client

[Viktor Dukhovni via Postfix-users]

On Wed, Apr 03, 2024 at 09:23:26AM +0300, Levente Birta via Postfix-users wrote:

> > The other possibility, is that the client never tried TLS 1.3, and was
> > implemented by a clueless keyboard-monkey, who decided to always send
> > the fallback SCSV even though there was no fallback.  That's sad, if
> > true.
> 
> As I said, this is an old (2019/2020) Dahua DVR ... I have doubts that this
> DVR supports TLSv1.3, although I don't remember when TLSv1.3 became largely
> used.

https://www.rfc-editor.org/rfc/rfc7507.html deined the fallback SCSV in
April 2015.  https://datatracker.ietf.org/doc/html/rfc8446, defining TLS
1.3, was published in August 2018.  If the DVR does not support or
attempt to negotiate TLS 1.3, its use of the fallback SCSV is
spectactacularly clueless. :-(

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: old TLS client

[Viktor Dukhovni via Postfix-users]

On Thu, Mar 28, 2024 at 09:58:13AM +0200, Levente Birta via Postfix-users wrote:

> > That's worth a try:
> > 
> >  588 inet ... smtpd
> >  -o smtpd_tls_security_level=encrypt
> >  -o smtpd_tls_mandatory_protocols=TLSv1.2
> >  ...
> 
> Limiting to only TLSv1.2 did the job.

It sure looks like something was causing the client's initial attempt
with TLS 1.3 to not work, and when the client retried with TLS 1.2, the
server objected, since it supported TLS 1.3.  Now that the server
supports TLS 1.2 only, it did not mind the fallback signal,

The other possibility, is that the client never tried TLS 1.3, and was
implemented by a clueless keyboard-monkey, who decided to always send
the fallback SCSV even though there was no fallback.  That's sad, if
true.

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Tue, Apr 02, 2024 at 12:11:03PM -0400, David Mehler wrote:

> 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.

As noted by Wietse, debug (verbose) logging is not useful here.  Just
normal logging is quite sufficient.

> 2024-04-02T09:48:08.293161-04:00 hostname postfix/submission/smtpd[1529]:
> improper command pipelining after EHLO from
> xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]: QUIT\r\n

As noted by Wietse, Postfix is reporting actual improper pipelining by
the client, prior to the EHLO reply.

> This is the port 465 atempt.
> 
> 2024-04-02T09:49:02.419571-04:00 hostname postfix/smtps/smtpd[1575]:
> SSL_accept error from xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]: -1
> 2024-04-02T09:49:02.419716-04:00 hostname postfix/smtps/smtpd[1575]:
> warning: TLS library problem: error:0A000412:SSL routines::sslv3 alert bad
> certificate:../ssl/record/rec_layer_s3.c:1590:SSL alert number 42:

This is also something to attend to, since Thunderbird is unable to
verify your certificate chain, and is sending a "bad certificate" TLS
alert.  Your certificate chain may be incomplete (missing intermediate
CAs) or expired, or not issued by a trusted CA, ...

On Tue, Apr 02, 2024 at 02:24:35PM -0400, Wietse Venema wrote:

> > 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

This covers the port 587 illegal pipelining, but perhaps the bad
certificate on port 465 is part of the story.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Is there a way to just quickly deliver "everything" to a file somewhere

[Viktor Dukhovni via Postfix-users]

On Tue, Apr 02, 2024 at 04:14:29AM -0400, Dan Mahoney via Postfix-users wrote:
> Hey there all,
> 
> I’m setting up a staging version of dayjob’s ticket system, and we’d 
> basically like postfix to still function, but instead of touching the 
> internet at all, just deliver everything to a single file (or a maildir, I 
> suppose), regardless of if a file is invoked via sendmail, or a port 25 
> connection.  I’d like nothing to leave the box.
> 
> Is there some kind of transport hack I can use for this?

# No local(8) delivery
#
alias_database =
mydestination =
local_transport = error:5.1.2 Mailbox unavailable

# No locally hosted domains, but you may want to set one of these
# non-empty to accept mail over SMTP, if mail comes in from outside,
# but this could also be via submission, permit_mynetworks, ...
#
relay_domains =
virtual_alias_domains =
virtual_mailbox_domains =

# Collapse all recipients to a single address, delivered to a single
# maildir.
#
enable_original_recipient = no
virtual_alias_maps = static:allmail@$mydomain
default_transport = virtual
virtual_mailbox_maps = static:/var/spool/virtual/allmail/
virtual_uid_maps = static:12345
virtual_gid_maps = static:12345

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Mon, Apr 01, 2024 at 04:09:34PM -0400, David Mehler via Postfix-users wrote:

> In my master.cf I do have smtpd_tls_wrappermode but it's in the commented
> out service for port 465, I'm using submission.
> 
> I've checked with postconf and smtpd_tls_wrappermode is set to no.

Of course, but Thunderbird might be attempting wrapper-mode (implicit
TLS), which could then be logged as a pipelining violation.

> Is there any additional information I can provide?
> 
> Please keep the suggestions coming.

The full unedited log entry has already been requested.  For meaningful
help, post the log entry.

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Mon, Apr 01, 2024 at 01:45:11PM -0400, David Mehler via Postfix-users wrote:

> 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. 

Instead if reinterpreting/summarising the log message, you should post
it verbatim, and in full.

> # postconf -n
> 
> compatibility_level = 

This is not a good idea.  Set it to 3.6, if you've resolved all the
compatibility issues through that release level.

> maximal_backoff_time = 15m

This is too short IMHO, I'd like to recommend 2 hours.

> maximal_queue_lifetime = 1h

This is absurdly short, make it at least 2 days, the recommended value
is 5 days.

> smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

You don't typically need this, unless you use "secure" or "verify" in
your policy table for some destinations.

> smtp_tls_policy_maps = proxy:mysql:/etc/postfix/sql/tls-policy.cf

> smtpd_tls_eecdh_grade = strong

This should be "auto", the "strong" setting is outdated.

> smtpd_tls_mandatory_exclude_ciphers = aNULL

This is not useful.

> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

Make that:

smtpd_tls_mandatory_protocols = >=TLSv1.2

> tls_high_cipherlist = 
> ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:
>  
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

Not a good idea.  Use the defaults.

> #cat /etc/postfix/master.cf

$ postconf -Mf submission/inet

> submission inet n   -   n   -   -   smtpd
>   -o syslog_name=postfix/submission
>   -o smtpd_tls_security_level=encrypt
>   -o smtpd_sasl_auth_enable=yes
>     -o smtpd_sasl_type=dovecot
>     -o smtpd_sasl_path=private/auth
>   -o smtpd_tls_auth_only=yes
>   -o smtpd_reject_unlisted_recipient=no
>   -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
>   -o smtpd_client_auth_rate_limit=0
>   -o smtpd_client_connection_rate_limit=0
>   -o cleanup_service_name=submission-header-cleanup
>   -o milter_macro_daemon_name=ORIGINATING

No obvious issues.

-- 
Viktor.
___
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 Wed, Mar 27, 2024 at 10:41:08AM -0400, Wietse Venema via Postfix-users wrote:

> 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). 

Yes, that would be simpler, but the audience for this would likely be
narrow (the hopefully legitimate bulk mailers delivering mail for
hopefully legitimate customers), so if this is a lot of work, perhaps it
should be sponsored by a suitably motivated party.

> This may require a non-blocking client that supports multiple
> outstanding requests.

Yes.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: old TLS client

[Viktor Dukhovni via Postfix-users]

On Wed, Mar 27, 2024 at 03:28:38PM +0200, Levente Birta via Postfix-users wrote:

> Please help me out with the following error. It's a not very old DVR
> equipment sending notification emails on submission with TLS.
> 
> Before (with Centos 7 and postfix 3.6) was working, but  now, with rocky 8
> and postfix 3.10-20240310.

Please post a "tshark" decode of the SSL handshake, as explained in:

https://marc.info/?l=postfix-users=166005488423800=2

> postfix/submission/smtpd[1341984]: read from 55BE67365B00 [55BE67426AB3] (5
> bytes => 5 (0x5))
> postfix/submission/smtpd[1341984]:  16 03 01 00
> 96   .
> postfix/submission/smtpd[1341984]: read from 55BE67365B00 [55BE67426AB8]
> (150 bytes => 150 (0x96))
> postfix/submission/smtpd[1341984]:  01 00 00 92 03 03 dc 27|9c 04 2a 57
> 91 c4 fd 9f  ...' ..*W
> [...]

Reading the hex dump is not fun, the tshark output is much easier to
work with.

> postfix/submission/smtpd[1341984]: warning: TLS library problem:
> error:14209175:SSL routines:tls_early_post_process_client_hello:
> inappropriate fallback:ssl/statem/statem_srvr.c:1767:

[ Seems you're using OpenSSL 1.1.1, which emits slightly more detailed
  error strings than OpenSSL 3.x, where the function name is not
  included. ]

It looks like the client's cipherlist indicated (SCSV codepoint) that it
performed a fallback (from TLS 1.3 to TLS 1.2 perhaps):

https://datatracker.ietf.org/doc/html/rfc7507#section-7

and since OpenSSL supports TLS 1.3, the fallback was rejected as a
downgrade attack:

ssl/statem/statem_srvr.c-} else if (SSL_CIPHER_get_id(c) == 
SSL3_CK_FALLBACK_SCSV &&
ssl/statem/statem_srvr.c-   
!ssl_check_version_downgrade(s)) {
ssl/statem/statem_srvr.c-/* 
ssl/statem/statem_srvr.c- * This SCSV indicates that the 
client previously tried
ssl/statem/statem_srvr.c- * a higher version.  We should 
fail if the current version
ssl/statem/statem_srvr.c- * is an unexpected downgrade, as 
that indicates that the first
ssl/statem/statem_srvr.c- * connection may have been 
tampered with in order to trigger
ssl/statem/statem_srvr.c- * an insecure downgrade.
ssl/statem/statem_srvr.c- */
ssl/statem/statem_srvr.c-SSLfatal(s, 
SSL_AD_INAPPROPRIATE_FALLBACK,
ssl/statem/statem_srvr.c: 
SSL_F_TLS_EARLY_POST_PROCESS_CLIENT_HELLO,
ssl/statem/statem_srvr.c- 
SSL_R_INAPPROPRIATE_FALLBACK);
ssl/statem/statem_srvr.c-goto err;
ssl/statem/statem_srvr.c-}

Perhaps there was an earlier TLS handshake attempt that failed for a
different reason (untrusted certificate? Something else).

Try to capture a "fresh" (first attempt) TLS delivery, rather than a
fallback, if the client is indeed performing a fallback.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: strict access restrictions and bounces

[Viktor Dukhovni via Postfix-users]

On Wed, Mar 27, 2024 at 11:57:22AM +0100, Daniel Marquez-Klaka via 
Postfix-users wrote:

> Why my setup looks like this? mail-server1 servs a couple of other mail
> domains, not only the one destined for the mailing lists. An access list
> here would affect all domains, right?

Only if the access rules in question apply to those domains.  You should
be able to use "smtpd_restriction_classes" to apply some rules to just
the domain in question.

smtpd_restriction_classes = list_server_access
smtpd_recipient_restrictions =
check_recipient_access inline:{
{ list.example.org = list_server_access } }
...

list_server_access =
check_sender_access inline:{
{ a.example = permit_auth_destination },
{ b.example = permit_auth_destination },
{ c.example = permit_auth_destination } }

-- 
Viktor.
___
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.

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

[pfx] Re: check_policy_service for customizing routing & load balancing

[Viktor Dukhovni via Postfix-users]

On Tue, Mar 26, 2024 at 05:22:52PM +, Colin McKinnon wrote:

> > What kind of "load balancing"?  Why won't MX records do?  For uneven
> > weights, you can even use SRV records:
> 
> I'm trying to setup load balancing across a cluster of relays for a
> SAAS application. There's several problems I was hoping to solve:
> 
> 1) distributing workload
> 2) IP warm up when adding nodes

As you note below, SRV records with suitably chosen weights can handle
this fine.  The DNS server serving the SRV zone can return highly
dynamic answers with short TTLs (say 30–60s).

> 3) avoiding dilution effects of spreading the workload (I only send a
> few emails to hotmail, for example)

Not sure what that means.

> 4) separating out very badly performing receiving MTAs

Connection caching takes care of this, because more responsive MTAs
handle more of the load, if the delay is felt during the SMTP mail
transaction.

> 5) adapting workload distribution according to host availability and
> current health (load, free memory etc)

This can be an input into the authoritative server serving the SRV
records, but I am sceptical that this is particularly important for
mail.

> Blindly distributing the traffic at the TCP level works for 1&2 but
> DNS is too slow for 5, while 3 & 4 need information about where the
> email is going.

That's fine, the SRV records can be keyed by destination domain.

> Mostly large block lists (you expect users to actually manage their data?).

Some call that listwashing...

> > That's what sender_dependent_default_transport_maps is for.
> 
> Policy server doesn't work in this context.

It does not, and note that while FILTER actions in policy server
responses will trump all other transport decisions, they're "sticky"
for the lifetime of the queued-message, so if it is not delivered
immediately, the same override will be still in place up to days
later, so not at all particularly dynamic once a message sits in the
queue for a while.  Here SRV lookup has the advantage of being fresh
for each delivery attempt.

-- 
Viktor.
___
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 01:52:42PM +, Colin McKinnon via Postfix-users 
wrote:

> I want to provision load balancing for my relays.

What kind of "load balancing"?  Why won't MX records do?  For uneven
weights, you can even use SRV records:

use_srv_lookup = smtp
relayhost = mx.example.com:smtp

Plus there's also "randmap":

https://www.postfix.org/DATABASE_README.html

> 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.

What sort "customised routing"?

> 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.

That's what sender_dependent_default_transport_maps is for.

> 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'.

It isn't actually a good tool for this, since it cannot affect
fine-grained per-recipient routing in multi-recipient messages.
It can only return FILTER actions which affect all recipients,
and the intent is to support content scanning, not fine-tune
routing.

> 1) Can I use check_policy_service in other contexts than
> smtpd_recipient_restrictions? (I don't want to interfere with
> `smtpd_relay_restrictions = permit_mynetworks
> permit_sasl_authenticated defer_unauth_destination` )

NO.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: strict access restrictions and bounces

[Viktor Dukhovni via Postfix-users]

On Mon, Mar 25, 2024 at 04:11:47PM +0100, Daniel Marquez-Klaka via 
Postfix-users wrote:

> I have a problem with check_sender_access that I can't find a solution to.
>
> 2 postfix mail server, one, mail-server1, is connected to the
> internet, the second, calling it list-server1, which serves a few
> mailing lists, is only reachable thru mail-server1.
> 
> On mail-server1 a transport map entry sends everything for
> @list-dom.de to list-server1, list-server1 does his work and sends all
> back to mail-server1 which then delivers to the final destination.
> 
> On list-server1, to prevent the whole world sending mails, I have
> installed a check_sender_access map to accept a few allowed domains,
> reject everything else.

The problem is self-inflicted, the access checks are in the wrong place.
The access(5) checks need to be implemented *at* the edge relay
(server1), not the downstream list server.

> ... bounces, as the are send with empty FROM (<>), as I understand to
> prevent loops, get rejected to. This is a problem because nobody will
> ever notice if there are dead emails in a list. Also, automatic bounce
> handling (I am using mailman3 on list-server1)
> will never do anything.

The vast majority of bounces will happen at the outbound edge relay,
when remote systems reject the outgoing mail.  These will not run into
any access check issues, once they're implemented in the right place.

Some bounces will be remote, you can use a milter to process remote
bounces, parsing the bounce multipart/report.

Bottom line, all filters belong on the relay, not the internal server.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: How to set the minimum number of bits for (non-EC) DH key exchange?

[Viktor Dukhovni via Postfix-users]

On Mon, Mar 25, 2024 at 09:24:23AM +0100, Alexander Leidinger wrote:
> thought-chain could be:

> IF there is no MITM, and IF the session is encrypted, then at least use good
> encrpytion so that an attacker which is only able to listen, is not able to
> get the content.

But, in that case, the vast majority of servers will advertise a DH
group of 2048-bits or more.  Refusing to complete the TLS handshake
will result in a cleartext delivery.

> Also: this is not a specific recommendation for SMTP, it is a generic
> recommendation for encrypted communication independent from the context it
> is used in, so there may be no thought at all about opportunistic TLS.

Exactly, and even then the general case is much too strict in many
contexts, not just opportunistic TLS in SMTP.  Often, the content is not
very sensitive, and communication at "adequate" security levels takes
priority over a maximal security posture.

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Mon, Mar 25, 2024 at 12:00:12PM +0800, Cowbay via Postfix-users wrote:
> On 2024/3/25 10:55, Viktor Dukhovni via Postfix-users wrote:
> > > I checked posttls-finger on my another container which is Ubuntu
> > > 22.04.4, posttls-finger still doesn't support ipv6, weird.
> > 
> > It isn't posttls-finger that does not support "ipv6", but rather your
> > network stack.
>
> It's still weird because I have ipv6 network stack and I can ping 
> smtp.gmail.com's ipv6 address. See below:
> 
> $ host smtp.gmail.com
> smtp.gmail.com has address 173.194.174.108
> smtp.gmail.com has IPv6 address 2404:6800:4008:c1b::6c
> 
> $ posttls-finger -wc -lsecure -F /etc/ssl/certs/ca-certificates.crt -a ipv6 
> "[smtp.gmail.com]:465" smtp.gmail.com
> posttls-finger: smtp.gmail.com[173.194.174.108]:465: matched peername: 
> smtp.gmail.com
> posttls-finger: smtp.gmail.com[173.194.174.108]:465: 
> subject_CN=smtp.gmail.com, issuer_CN=GTS CA 1C3, 
> fingerprint=F7:5F:AA:8D:B5:7A:A7:A4:8A:34:0C:C3:12:18:D8:77:3B:A9:F7:75:E1:EC:76:25:76:79:41:B2:AB:46:34:E1,
>  
> pkey_fingerprint=E9:BB:66:2D:A5:7C:05:FD:C4:EE:2D:CD:33:9C:32:6D:F7:99:7E:66:29:1F:F0:A4:5E:42:05:57:32:10:7C:96
> posttls-finger: Verified TLS connection established to 
> smtp.gmail.com[173.194.174.108]:465: TLSv1.3 with cipher 
> TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature 
> RSA-PSS (2048 bits) server-digest SHA256

The "-a" option is a "preference", but perhaps you have separately
disabled IPv6 via "inet_protocols = ipv4" in main.cf?

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Mon, Mar 25, 2024 at 10:08:59AM +0800, Cowbay via Postfix-users wrote:
> On 2024/3/25 01:12, Viktor Dukhovni via Postfix-users wrote:
> > > If the "posttls-finger" has the identical behavior as postfix, then I
> > > could write a simple cronjob script to "finger" the
> > > smtp.gmail.com:465.
> > 
> > Not necessarily 100% identical, but quite close.
> It seems not perfect. :(

But close enough, that it should be used instead of "openssl s_client".
You can also specify the "-C" option to report the remote chain, which
you can then examine if verification failed.

> I checked posttls-finger on my another container which is Ubuntu
> 22.04.4, posttls-finger still doesn't support ipv6, weird.

It isn't posttls-finger that does not support "ipv6", but rather your
network stack.

> > Certificate verification should be identical, but if the presented chain
> > subtly depends on the client's TLS HELLO message, there could perhaps be
> > a difference if main.cf has "smtp_tls_..." settings that cause the HELLO
> > message to differ between smtp(8) and posttls-finger(1).
>
> Since they are different, my idea to use posttls-finger seems
> unnecessary. I decide to cancel this idea.  But modify my script to
> monitor the postfix log for keyword "self-signed" every minute. I can
> expect that we cannot see any result in a short time.

You read too much into my caveats, the differences should be minor, and
quite likely the issue was a brief configuration blip in Google's
front-end TLS load-balancers.

> it seems that we prefer to believe postfix really got a self-signed
> certificate from smtp.gmail.com last time and maybe one of the cause
> is no SNI name sent.

That's one possible explanation.

> I still decide to add the "servername" attribute to my tls_policy
> while also monitor the postfix log with my modified script. Maybe I
> will never have a result. :)

Good luck, whatever that might be.

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Sun, Mar 24, 2024 at 08:39:16PM +0100, Jack Raats via Postfix-users wrote:

> > master.cf:
> >  smtp .. .. .. .. .. .. smtp
> > -o inet_protocols=ipv6
> 
> What to do if my smtp line ends with postscreen?

That's "smtp inet", while the delivery agent is "smtp unix ...", see my
post for an unabbreviated example.

> I have a new glas fiber internet connection with a new ipv4 address
> which has a very bad reputation.  That's why I want to use ipv6.

I take it you know that many (even large service provider) domains don't 
have IPv6 MX hosts, so using *only* IPv6 you'll find that you won't be
able to reach many potential recipients.

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Sun, Mar 24, 2024 at 04:32:15PM +0100, Jack Raats via Postfix-users wrote:

> Can any help me. I want to recieve email via ipv4 and ipv6. I want to send
> email via ipv6 only.
> I tried using smtp_address_preference = ipv6, but that didn't work.

I have a machine where IPv6 connectivity is second-class (Verizon Fios
does not offer IPv6, so GRE tunnel via Hurricane Electric), and where
historically there was more impedance (stricter inbound policies on
remote servers) for IPv6 SMTP.  So I chose to deliver only via IPv4:

$ postconf -Mf smtp/unix
smtp   unix  -   -   n   -   150 smtp
-o inet_protocols=ipv4

And for a few v6 only domains I have:

$ postconf -Mf ipv6/unix
ipv6   unix  -   -   n   -   150 smtp
-o inet_protocols=ipv6

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Sun, Mar 24, 2024 at 11:34:35PM +0800, Cowbay via Postfix-users wrote:

> > You might not get to observe the problem for quite some time (if ever
> > again).
>
> I'm quite seldom sending mail by gmail via my postfix server.
> 
> If the "posttls-finger" has the identical behavior as postfix, then I
> could write a simple cronjob script to "finger" the
> smtp.gmail.com:465.

Not necessarily 100% identical, but quite close.

> OT: I just tried that my version of "posttls-finger" has no ipv6 support 
> though the man page says it supports. And it always returns 0 even failed.
> 8<-8<-
> $ host smtp.gmail.com
> smtp.gmail.com has address 142.251.8.109
> smtp.gmail.com has IPv6 address 2404:6800:4008:c15::6d
> 
> $ posttls-finger -wc -F /etc/ssl/certs/ca-certificates.crt -a ipv6 
> [smtp.gmail.com]:465

You neglected to specify "-lsecure", and just in case an explicit match
pattern:

$ posttls-finger -wc -lsecure -F /etc/ssl/cert.pem -a ipv6 
"[smtp.gmail.com]:465" smt.gmail.com
posttls-finger: smtp.gmail.com[2607:f8b0:4004:c1d::6c]:465: matched 
peername: smtp.gmail.com
posttls-finger: smtp.gmail.com[2607:f8b0:4004:c1d::6c]:465: 
subject_CN=smtp.gmail.com, issuer=GTS CA 1C3, cert 
fingerprint=F7:5F:AA:8D:B5:7A:A7:A4:8A:34:0C:C3:12:18:D8:77:3B:A9:F7:75:E1:EC:76:25:76:79:41:B2:AB:46:34:E1,
 pkey 
fingerprint=E9:BB:66:2D:A5:7C:05:FD:C4:EE:2D:CD:33:9C:32:6D:F7:99:7E:66:29:1F:F0:A4:5E:42:05:57:32:10:7C:96
posttls-finger: Verified TLS connection established to 
smtp.gmail.com[2607:f8b0:4004:c1d::6c]:465: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature 
RSA-PSS (2048 bits) server-digest SHA256

> posttls-finger: Verified TLS connection established to 
> smtp.gmail.com[142.251.8.109]:465: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 
> (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) 
> server-digest SHA256

It does indeed look like IPv6 is not available on your end.

> $ posttls-finger -wc -F /etc/ssl/certs/ca-certificates.crt 
> "[ipv6:2404:6800:4008:c15::6d]:465" smtp.gmail.com

The "[ipv6:addr]" syntax can be simplified to "[addr]".  You still
should specify "-lsecure".

> If the "posttls-finger" has the identical behavior as postfix about
> verifying the certificate, then I can start to launch this cronjob.

Certificate verification should be identical, but if the presented chain
subtly depends on the client's TLS HELLO message, there could perhaps be
a difference if main.cf has "smtp_tls_..." settings that cause the HELLO
message to differ between smtp(8) and posttls-finger(1).

The cipher grade will default to "medium", and (as in the Postfix
smtp(8) client) an SNI name won't be sent unless you specify one ("-s
smtp.gmail.com").

I am sceptical that monitoring smtp.gmail.com:465 is likely to be
productive, but if you're motivated, this is surely harmless.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: dane.sys4.de

[Viktor Dukhovni via Postfix-users]

On Sun, Mar 24, 2024 at 05:22:26PM +0100, Benny Pedersen via Postfix-users 
wrote:
> Viktor Dukhovni via Postfix-users skrev den 2024-03-24 02:31:
> 
> > The code should be fixed, but nobody has complained loudly enough.
> 
> time out or not, dnssec is green, tlsa is yellow, should smtp test be needed
> when tlsa is not green ?
> 
> if smtp test is not done without tlsa green i think problem is solved for
> the dane testing

This is a topic for the dane-us...@list.sys4.de list.  It is not
Postfix-specific.  If there are no TLSA records, then there is no
sensible information to be gained from an SMTP test.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: dane.sys4.de

[Viktor Dukhovni via Postfix-users]

On Sat, Mar 23, 2024 at 11:43:02PM +0100, Benny Pedersen via Postfix-users 
wrote:

> It go into endless loop if mx is missing, so it does not do a/ failback
> testing, is this a bug ?

This is an off-topic question.  The code behind dane.sys4.de is a Perl
script that tests the correctness of DANE TLSA records for the MX hosts
of remote domains.  I wrote the code, but the contributed version has
a bug where one of the timeouts that was expected to be in milliseconds
is actually a time in seconds,  so the timeout is 1000x too long.

The code should be fixed, but nobody has complained loudly enough.

-- 
Viktor.
___
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?

[Viktor Dukhovni via Postfix-users]

On Sat, Mar 23, 2024 at 12:45:04PM +0100, Matthias Nagel via Postfix-users 
wrote:

> 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?

Superseded by smtpd_tls_cipher_grade and tls_medium_cipherlist,
tls_high_cipherlist.

> I am looking for an option to explicitly set the list of allowed
> cipher suites.

In other words, you want to reduce the effective security of your server
in order to comply with a poorly suited to SMTP external security metric. 
You have my sympathy, but if you're at all at liberty to hold your
ground, do so, and let the defaults stand.


> The deprecated setting `smtpd_tls_cipherlist` allowed
> that. The new setting `smtpd_tls_mandatory_ciphers` only supports to
> enable a selection of cipher suites by defining a lower limit on the
> cryptographic strength (i.e. „low“, „medium“, „high“, ...) and it
> seems I can additionally use `smtpd_tls_exclude_ciphers` to remove
> certain unwanted cipher suites subsequently. For me, that feels a
> little bit cumbersome. Why not provide both ways? Or did I miss
> something?

Almost every attempt at explicit ciphers I've seen has been misguided.
Instead of specifying broad categories, these choose specific individual
code points, eliminating possible future additions that are stronger,
and excluding ciphers that are useful for interoperability.

It really is best to focus on actual security issues, rather than
exotic, if sexy, hypothetical cryptographic attacks.

- Install security patches in a timely manner

- Audit trusted SSH keys, ...

- DNSSEC-sign your domain, and monitor it well, checking for
  unexpectedly soon expiration of at least the core zone apex, if not
  all RRsets.

- Publish DANE TLSA records, and implement outbound DANE.  Monitor
  the correctness of your TLSA records, and make sure the rollover
  process cannot result in deploying a new cert before the matching
  TLSA records have already been published for a few TTLs.

Focus on the basics, tuning cryptographic parameters is a distraction.

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Sat, Mar 23, 2024 at 06:24:50PM +0800, Cowbay via Postfix-users wrote:

> My smtp_tls_policy_maps points to a hash table and the relevant entry is
>   [smtp.gmail.com]:465secure

OK, nothing unusual there.

> > No, the self-signed certificate might have been some root CA that isn't
> > listed in your CAfile.  Or perhaps the Gmail load-balancer did present
> > a self-signed certificate for some reason.
>
> Ok, you should be correct. The more precise statement from the Wikipedia is
> "self-signed certificates are public key certificates that are not issued by
> a certificate authority (CA)." So maybe that once the CA isn't listed in the
> CAfile the Postfix or the ssl library treats it as a self-signed
> certificate.

Postfix just relays what OpenSSL finds.  A certificate is only
self-signed when its subject name and issuer name are equal, absence
from the CA file does not change this, but if found in the CA file,
a self-signed certificate is typically treated as a trust-anchor
and verification succeeds.

Since Gmail does not normally vend any self-signed certificates,
something atypical was in place on the Gmail end at the time.

One possible factor is the handling of TLS connections that don't set
the SNI name (Postfix default, see
).


> > You should try with each of "-servername smtp.google.com" and
> > "-noservername" options.

and also "posttls-finger" as in the example I posted.

> > When I test with s_client, I see the same certificate chain at that
> > address regardless of whether SNI is used:
> >
> >  $ openssl s_client -servername smtp.gmail.com -verify_hostname 
> > smtp.gmail.com -connect 64.233.189.109:465 < /dev/null
> >  ...
> >
> >  $ openssl s_client -noservername -verify_hostname smtp.gmail.com 
> > -connect 64.233.189.109:465 < /dev/null
> >  ...
> >
> > With posttls-finger, I see:
> >
> >  $ posttls-finger -wc -F /etc/ssl/cert.pem -lsecure 
> > "[64.233.189.109]:465" smtp.gmail.com

You might not get to observe the problem for quite some time (if ever
again).

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Sat, Mar 23, 2024 at 08:04:18AM -0400, Wietse Venema via Postfix-users wrote:

> 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.

While true, that should rarely be used or necessary.  An explicit CAfile
and/or CApath is almost always sufficient.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: How to set the minimum number of bits for (non-EC) DH key exchange?

[Viktor Dukhovni via Postfix-users]

On Sat, Mar 23, 2024 at 03:58:15PM +0100, Matthias Nagel via Postfix-users 
wrote:

> So the question still stand, how do I ensure that Postfix uses at
> least 2048bit DH, if TLS 1.2 and FFDH have been negotiated?

As an SMTP server, Postfix uses a 2048-bit build-in group, or else
whatever group you configured in its place.  The current recommendation
is to use the built-in group.  With OpenSSL 3.0, and "auto" for the DH
params, the Postfix SMTP srever lets OpenSSL choose a group that matches
the server's private key strength.

> Unfortunately not. Yes, we are speaking about oppertunistic TLS as I
> am looking at my mail server in the role of an SMTP server for
> incoming mails from the public Internet. I must not make TLS
> encryption mandatory, as there are still a lot of (legacy) systems out
> there which do not support TLS (unfortunately). For the same reason, I
> don‘t want to disable FFDH completely as there are even more legacy
> servers on the public Internet which still do not support EC. At the
> same time, I have to meet certain legal regulations which mandate a
> minimum crypthographic strength. So while it is seemingly fine to not
> use TLS at all on the one hand, TLS must meet certain minimal
> requirements if it is used on the other hand.

These are of course inane, it is up to the sending client to set a
reasonable floor, the server just has to offer a high enough ceiling.

https://www.postfix.org/TLS_README.html#client_tls_limits

> I mean I also disable SSL 3.0, TLS 1.0 and TLS 1.1 and only allow TLS
> 1.2 or 1.3 besides plain transport. From a technical perspective one
> could also argue that leaving SSL 3.0 and TLS <1.2 enabled is still
> better than plain transport.

There are good reasons to disable SSL 2.0, because it is no longer
needed for interop, and exposes servers to potential cross-protocol
attacks such as DROWN.  Similarly, SSL 3.0 is also not needed for
interop, though the risk of issues is much lower, it is basically TLS
1.0 without extensions.

Disabling TLS 1.0 and TLS 1.1 is a judgement call.  There is little
practical risk to SMTP, and a dwindling minority of senders still
only do TLS 1.0, but these are quite rare now.

> I wonder whether setting `smtpd_tls_dh1024_param_file` to a custom
> 2048-bit DH group would help?

It would force the use of that group, which would typically be accepted
by the client, but perhaps (speculatively) some accept only the RFC3526
groups?

> But from my understanding of the docs that should not be necessary as
> Postfix 3.8.5 uses a built-in 2048bit group if left empty.

Yes, with OpenSSL 1.1.1.  But with 3.0, the default is "auto", which
will use of the RFC DH groups based on the certificate strength,
typically also 2048-bit.

> PS: As of January 2024, the German BSI has tighten its recommendation
> for asymmetric algorithms over finite fields to at least 3000 bits
> (i.e. RSA encryption, RSA signatures and FFDH).

With little thought about the opportunistic TLS use-case.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: How to set the minimum number of bits for (non-EC) DH key exchange?

[Viktor Dukhovni via Postfix-users]

On Sat, Mar 23, 2024 at 12:36:23PM +0100, Matthias Nagel via Postfix-users 
wrote:

> I am currently assessing the TLS security of a Postfix mail server and
> among other things sslscan reported that the server allows a (non-EC)
> DH exchange with only 1024 bits.

The Postfix SMTP server uses whatever DH parameters are configured by
the administrator.  With default settings, the Postfix SMTP server uses
a built-in 2048-bit group.

The Postfix SMTP client accepts whatever DH group is accepted by OpenSSL
at the ambient OpenSSL "security level".  For opportunistic TLS (Postfix
TLS security level "may"), and unauthenticated mandatory TLS (Postfix
TLS security level "encrypt") the OpenSSL security level is set to 0,
which will indeed (IMNSHO, correctly) accept 1024-bit DH. 

Since with "may" even cleartext delivery is acceptable, it is
unreasonable to argue that 1024-bit DH is not good enough, it is
definitely stronger than cleartext.

With "encrypt" the connection is not immune to active MiTM attacks, so
any concerns around downgrades hrough weaker DH are misplaced, the
attacker can just terminate TLS, with no special effort to "impersonate"
the target server.  So again 1024-bit DH (if presented by the remote
server is quite sufficient).

At Postfix TLS security levels that actually authenticate the remote
peer, the OpenSSL security level is set to 1, which means crypto
parameters with an equivalent symmetric key size of 80 bits.  Yes,
this still accepts 1024-bit FFDH groups.

Perhaps the SSL security level for authenticated destinations could be
configurable, with level 2 (112-bit symmetic ~ 2048-bit RSA/DH) an
available option.  But frankly, I am very sceptical of fears that
an effective and cost-efective realtime MiTM attack against 80-bit DH 
is a practical concern for SMTP.

> While one solution would be to only
> allow ECDH(E) and disable DH(E) entirely, I would rather like to keep
> support for DH(E) for compatibility reasons but only enforce a lower
> limit on the size of the finite group (maybe 2048 bit, or even 3072
> bits preferably). How do I do that with Postfix? I cannot find any
> smptd_tls_... setting which seems related to that aspect.

There is no such setting, and I'd like to politely suggest that your
time is better spent elsewhere.  Many real security issues to attend to,
while 1024-bit DH is not one of them.

-- 
Viktor.
___
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?

[Viktor Dukhovni via Postfix-users]

On Sat, Mar 23, 2024 at 01:57:39PM +0100, Matthias Nagel via Postfix-users 
wrote:

> Also note, that the file which is configured in
> `smtpd_tls_chain_files` is only a symbolic link, e.g.
> 
> # ls -lha /etc/letsencrypt/live/my-host.my-domain.tld:smtps/fullchain.pem
> lrwxrwxrwx 1 root root 51 11. Mar 21:44 
> /etc/letsencrypt/live/my-host.my-domain.tld:smtps/fullchain.pem -> 
> ../../archive/my-host.my-domain.tld:smtps/fullchain3.pem

Note that with `certbot`, the `fullchain.pem` file (its symlink target)
contains only the certificate chain, without the private key, which is
still in a separate file (the symlink target of): `privkey.pem`.

So you don't get atomicity from `certbot`.  I don't consume `certbot`
files directly, rather I use:

https://github.com/tlsaware/danebot

Which works very well in steady-state.  What's missing are features like
built-in support for changing the list of domains to be renewed, which
sadly requires low-level fiddling with "cerbot certonly --csr ...".

For example, I had recently needed to use:

# Create a private key and CSR with the desired names
...

# Obtain a new certificate
certbot certonly --webroot --cert-name $(uname -n) --csr csr.pem \
--cert-path $PWD/staging/$(uname -n)/newcert.pem \
--fullchain-path $PWD/staging/$(uname -n)/newfull.pem \
--chain-path $PWD/staging/$(uname -n)/newchain.pem

# Then integrate these files into the archive directory, making
# new symlinks, ...

This would ideally be automated, but requires tricky logic if it is to
support more than just --webroot, and even that requires a bit of extra
logic to specify the webroots correctly for existing and any new
domains.

Perhaps I should be looking to switch to one of the other ACME clients.

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Wed, Mar 20, 2024 at 10:25:26PM +0800, Cowbay via Postfix-users wrote:

> I'm using debian 10, an old debian distribution. The Postfix version is
> 3.4.23.

The base 4.0 release is ~5 years old, but not materially different in
its core TLS functionality.  You'd see the same results with the latest
Postfix 3.9.0.

> I found below in the log, it says "certificate verification failed for
> smtp.gmail.com[64.233.189.109]:465: self-signed certificate"
> 8<8<8<
> Mar 20 21:27:38 SERVER postfix/qmgr[12913]: DC7D0140531:
> from=, size=122883, nrcpt=1 (queue active)
> Mar 20 21:27:38 SERVER postfix/smtp[15534]: certificate verification failed
> for smtp.gmail.com[64.233.189.109]:465: self-signed certificate
> Mar 20 21:27:38 SERVER postfix/smtp[15534]: Untrusted TLS connection
> established to smtp.gmail.com[64.233.189.109]:465: TLSv1.3 with cipher
> TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature
> RSA-PSS (2048 bits) server-digest SHA256
> Mar 20 21:27:38 SERVER postfix/smtp[15534]: DC7D0140531:
> to=, relay=smtp.gmail.com[64.233.189.109]:465, delay=2789,
> delays=2789/0.08/0.06/0, dsn=4.7.5, status=deferred (Server certificate not
> trusted)

Perhaps this is a result of not sending SNI?

> I have configured sender_dependent_default_transport_maps so the mail sender
> @gmail.com would use smtp.gmail:[smtp.gmail.com]:465
> 
> The smtp.gmail is below
> 8<8<8<
> smtp.gmail   unix  -   -   n   -   -   smtp
> -o smtp_generic_maps=regexp:/etc/postfix/smtp_generic_maps
> -o smtp_header_checks=pcre:/etc/postfix/smtp_header_checks
> -o smtp_helo_name=localhost
> -o smtp_tls_wrappermode=yes
> -o smtp_tls_CAfile=/etc/ssl/certs/ca-certificates.crt
> 8<8<8<

What is the "security level"?  You must have something in
"smtp_tls_policy_maps" to require TLS for this destination.  What is the
relevant entry there?  What is the main.cf value of
"smtp_tls_security_level"?

> I believe my transport and sasl configurations are well since the
> problem is postfix thinks smtp.gmail.com:465 uses self-signed
> certificate.

No, the self-signed certificate might have been some root CA that isn't
listed in your CAfile.  Or perhaps the Gmail load-balancer did present
a self-signed certificate for some reason.

> Do you have idea to solve this problem?

If it isn't reproducible, it is unlikely that much can be determined
long after the fact.

Please share your TLS policy table entry, and when comparing Postfix
against openssl sclient, specify the same IP address as the target host,
at most minutes after observing any failure to verify the chain from
Postfix. For example:

openssl s_client ... -verify_hostname smtp.gmail.com -connect 
64.233.189.109:465

You should try with each of "-servername smtp.google.com" and
"-noservername" options.

On Sat, Mar 23, 2024 at 12:20:40AM +0800, Cowbay via Postfix-users wrote:

> Today the problem was vanished. Postfix can connect to smtp.gmail.com:465
> without problem.

There are many datacentres in which smtp.gmail.com might be found, and
they don't necessarily always present the same certificate (rollouts of
new cert chains and software take place earlier in some locations than
others).

> I found that this time the IP address of smtp.gmail.com becomes
> 74.125.23.109 and its certificate is different from last time.

There are many more.

> This means there exists some cases that Postfix will make a mistake to
> detect the certificate as self-signed.

No, Postfix correctly reports what it finds.  There was no "mistake",
don't blame the messenger.

> In gmail's case, the mail might eventually be sent as long as the DNS
> resolves to certain IP address that has compatible certificate for Postfix.
> 
> Of course it's my bad that use such old Postfix and Debian, sorry.

Postfix 3.4 is a bit dated, but there is no reason to expect any issues.

When I test with s_client, I see the same certificate chain at that
address regardless of whether SNI is used:

$ openssl s_client -servername smtp.gmail.com -verify_hostname 
smtp.gmail.com -connect 64.233.189.109:465 < /dev/null
...
Certificate chain
 0 s:CN = smtp.gmail.com
   i:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
   v:NotBefore: Feb 26 08:18:13 2024 GMT; NotAfter: May 20 08:18:12 2024 GMT
 1 s:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug 13 00:00:42 2020 GMT; NotAfter: Sep 30 00:00:42 2027 GMT
 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 19 00:00:42 2020 

[pfx] Re: smtpd_discard_ehlo_keyword_address_maps all but internal

[Viktor Dukhovni via Postfix-users]

On Thu, Mar 21, 2024 at 11:06:12AM -0500, Noel Jones via Postfix-users wrote:

> > Surely the generalisation is:
> > 
> >smtpd_discard_ehlo_keyword_address_maps =
> >cidr:{
> >  {if 0.0.0.0/0}
> >  # Private IPv4 addresses
> >  {!10.0.0.0/8  silent-discard,dsn}
> 
> Seems to me 172. and 192. would match the above line.
> Does cidr support DUNNO?

Oops, indeed you're right, but this is solvable:

if 0.0.0.0/1
!10.0.0.0/8 silent-discard,dsn
endif
if 128.0.0.0/2
!172.16.0.0/12 silent-discard,dsn
endif
if 192.0.0.0/2
!192.168.0.0/16 silent-discard,dsn
endif

DUNNO is not a table-layer "no result" primitive, it is an access(5) RHS
keyword, so does not apply with ehlo keyword discard rules.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: smtpd_discard_ehlo_keyword_address_maps all but internal

[Viktor Dukhovni via Postfix-users]

On Thu, Mar 21, 2024 at 03:20:23PM +0100, Matus UHLAR - fantomas via 
Postfix-users wrote:

> > Wietse Venema via Postfix-users:
> > > smtpd_discard_ehlo_keyword_address_maps =
> > > cidr:{ {!10/8  silent-discard,dsn} }
> 
> On 23.02.24 11:12, Wietse Venema via Postfix-users wrote:
> > But that does not generalize to hosts with IPv4 and IPv6. In that case,
> > your approach will be more suitable.

Surely the generalisation is:

  smtpd_discard_ehlo_keyword_address_maps =
  cidr:{ 
{if 0.0.0.0/0}
# Private IPv4 addresses
{!10.0.0.0/8  silent-discard,dsn}
{!172.16.0.0/12  silent-discard,dsn}
{!192.168.0.0/16  silent-discard,dsn}
{endif}
{if ::/0}
# Unique local, site and link local IPv6 addresses
{!fc00::/7  silent-discard,dsn}
{!fe80::/9  silent-discard,dsn}
{endif}
}

Each set of negative rules can be constrained to its address family by
enclosing it in an if..endif block.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Trouble with qmqp

[Viktor Dukhovni via Postfix-users]

On Wed, Mar 20, 2024 at 09:40:56PM +, Brad Koehn via Postfix-users wrote:

> 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. 

Can you be more specific about what you mean by "deliver using `qmqpd`"?
The qmqpd(8) service in Postfix is NOT a delivery agent.  It is an
alternative to smtpd(8) for injecting mail into the queue from a remote
client.  Specifically optimised for bulk mail delivery to lists.

There is no corresponding qmqp(8) delivery agent in Postfix, so Postfix
cannot initiate delivery over QMQP and can only be on the receiving end
of a QMQP connection.

> Curiously, if I deliver the same email directly to Dovecot via LMTP,

Now lmtp(8) is on the other hand a delivery agent, that can initiate
outbound mail delivery, and in this case Postfix does not include a
corresponding listener, so LMTP is outbound-only, while QMQP is
inbound-only.

> 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. 

So you are comparing very unlike things, and the questions make no sense
without the technical details.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Feature request

[Viktor Dukhovni via Postfix-users]

On Wed, Mar 20, 2024 at 09:17:58AM -0400, Viktor Dukhovni via Postfix-users 
wrote:

> With bash <(command) inline file syntax, make the RHS unique on the fly:
> 
> $ keystr=...
> $ remap=/etc/postfix/...
> $ postmap -q "$keystr" pcre:<(perl -pe 's/$/ LINE $./ unless 
> m{^(if|endif|#)?\s}' "$remap")
> 
> Better yet, don't be lazy, include a fingerprint string in your RHS
> reject rule values.

Note that the recipe isn't correct for multi-line extended regular
expressions.  It appends the tag to the first rather than last line.

But you're probably not using these.  If you are, you'd need a fancier
Perl (or Python, ...) script to read folded logical lines from the input
file, and append at the end of a logical line.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Feature request

[Viktor Dukhovni via Postfix-users]

On Wed, Mar 20, 2024 at 01:42:16PM +0100, Ralf Hildebrandt via Postfix-users 
wrote:
> 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.

With bash <(command) inline file syntax, make the RHS unique on the fly:

$ keystr=...
$ remap=/etc/postfix/...
$ postmap -q "$keystr" pcre:<(perl -pe 's/$/ LINE $./ unless 
m{^(if|endif|#)?\s}' "$remap")

Better yet, don't be lazy, include a fingerprint string in your RHS
reject rule values.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: postfix and from

[Viktor Dukhovni via Postfix-users]

On Tue, Mar 19, 2024 at 11:39:29AM +0100, natan via Postfix-users wrote:
> Hi
> I have one question regarding the RFC of the FROM field: in the message
> header.
> 
> Is there any restriction that will force the FROM field to be correct
> according to the RFC?

Nothing builtin to Postfix.

> I'm asking because one client "parses e-mails strangely" and his application
> hangs and instead of correcting it, he sends me to block such e-mails using
> Postfix.

A milter can reject message headers using any criteria it chooses.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Help please on converting SENDMAIL VIRTUSERTABLE to postfix

[Viktor Dukhovni via Postfix-users]

On Mon, Mar 18, 2024 at 12:20:09AM -0700, Glenn Tenney via Postfix-users wrote:

> > transport:
> > u...@domain.nameerror:5.1.1 purported to not exist
> >
> >
> 
> Thank you very much. A question please… the above two “solutions” seem to
> accomplish very similar tasks: to reject user@domain.example issuing an
> error to the sender… but…

Yes, quite similar, though not completely identical.

> It would seem that the 2nd solution using transport_maps is simpler to
> implement,

Only if you don't already have any access(5) checks.  Either way, you
add an entry to a table.

The transport(5) approach makes the recipient *undeliverable* even for
locally submitted mail, and even after alias expansion, but either way
only the *verabatim* recipient address is rejected after SMTP "RCPT TO".

> but there may be a variety of reasons to choose one solution
> over the other.

Mostly a matter of taste, the recipient restrictions are the more common
approach, but the transport(5) mapping to "error" is also fine.

> Is there some relatively straightforward criteria to consider which of
> your two “solutions” is better or more efficient?

Neither is noticeably more "efficient", either way a cheap table lookup.

> It’s clear that there are going to be multiple ways to accomplish the
> same task.

Yes, many ways, and overlap with per-address class valid recipient
tables, ... (local_recipient_maps, virtual_mailbox_maps,
relay_recipient_maps).

Which is why just cargo-cult is difficult to specify without the full
picture of your entire setup, but that's too much work to take in unless
you hire a paid consultant.  In your place, I'd have stuck with Sendmail
on FreeBSD, while you're learning to use Postfix on some toy machines,
reading docs more deeply, ...

Another option is a turnkey solution, such as: https://mailinabox.email

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Help please on converting SENDMAIL VIRTUSERTABLE to postfix

[Viktor Dukhovni via Postfix-users]

On Mon, Mar 18, 2024 at 12:50:18AM -0700, Glenn Tenney via Postfix-users wrote:
> On Monday, March 18, 2024, Benny Pedersen via Postfix-users <
>
> > Victor gave a vierd config :)
> >
> > postfix must not return any result on non existsing users, so if this
> > gives no result user is unknown, with in turn gives postfix user not found,
> > to keep things very simple mydestination must only have unix users where @
> > is not auth without realm-domain, when this is in place you  can in
> > virtual_alias_maps map remote mail recipient to system users mailbox, of
> > not all is virtual_domained
> >
> 
> 
> Thanks. I’m hosting several domains: a couple need to accept any user@
> except some that specifically need to be rejected delivering locally; some
> domains are more normal, just accept specific users & deliver to some local
> user (sometimes using procmail to forward some or save some to files); and
> a few domains that will deliver to some-other domain (kinda relay). So only
> the first of these need to return a result (reject) specific users.

Benny is at times too eager to answer more questions than he can give
justice to.  Tread with care.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Help please on converting SENDMAIL VIRTUSERTABLE to postfix

[Viktor Dukhovni via Postfix-users]

On Sun, Mar 17, 2024 at 09:52:10PM -0700, Glenn Tenney via Postfix-users wrote:

> > It is a reserved domain name, (one of many) that you can use internally,
> > without clashing with *real domains*.
> 
> Wow. Once you KNOW it's there, you can find out about "local.invalid".
> BUT if you didn't know it was there, finding out about "local.invalid"
> would be difficult.

The entire "invalid" TLD is reserved by IANA, this isn't a Postfix
thing.  I use it for various internal routing tricks without stepping
on real domains.  E.g. rewrite some recipients to "discard.invalid"
which is routed in my transport(5) to the discard(8) transport.

> Based on "local.invalid" knowledge from Viktor, am I correct that
> entering the following line in virtual would block that email address?

> user@some.domain   user@local.invalid

No.  The opposite.  This would definintely accept the mail, which would
typically bounce, unless you make it deliverable.  As explained, the
access(5) and transport(5) tables are available to reject and/or bounce
some recipients, while virtual(5) is just for aliasing.

> For virtually hosted domains is there any way to "rewrite" any email
> address to a specific email? e.g.
> @some.domain user@another.domain

Just like that.


> > - You can reject SMTP recipients via various restriction checks
> >   that perform access(5) lookups against tables of your choice.
> 
> How can I do it not based on the network or domain name but a specific
> u...@domain.name?

By putting that address in an access(5) table with "REJECT " as
the RHS.  Then add:

main.cf:
indexed = ${default_database_type}:${config_directory}/
smtpd_recipient_restrictions = 
permit_mynetworks,
reject_unauth_destination,
check_recipient_access ${indexed}rcpt-access

rcpt-access:
# Postmap after each change
user1@domain.example REJECT 5.1.1 purported to not exist
user2@domain.example REJECT 5.7.1 access denied
...

> > - You can route some recipients to the error(8) transport, and
> >   this will also lead them to be rejected at SMTP time.
> 
> I DID look it up. How do I do this? I don't see a way to use error(8)
> table to do it.

There is no error(8) table, that's delivery agent.  There's a transport
table:

main.cf:
# See "indexed =  ..." above
transport_maps = ${indexed}transport

transport:
u...@domain.nameerror:5.1.1 purported to not exist

> > No, it also supports user@domain.
> 
> it sure would be nice if that was in that man page!

It is.  Look under "TABLE SEARCH ORDER".

> > > ACCESS seems to allow only a domain name or IP (again, without a
> > > user@) on the LHS. This doesn't seem to apply to my query.
> >
> > No, it also supports user@domain.
> 
> it sure would be nice if that was in that man page!

It is.  Look under "EMAIL ADDRESS PATTERNS".

> > By mapping a user to the error transport.
> 
> Oh, PLEASE... just tell me how to map a user to the error transport...

By adding an entry to the transport(5) table, see above.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Help please on converting SENDMAIL VIRTUSERTABLE to postfix

[Viktor Dukhovni via Postfix-users]

On Sun, Mar 17, 2024 at 04:28:00PM -0700, Glenn Tenney via Postfix-users wrote:

> Are you saying that if I want "username1" at my local domain to be
> delivered to "user2" at my local domain, that that should be in the
> virtual table and not in aliases? That's a 1-to-1 rewrite, not a
> 1-to-many.

1-to-many includes 1-to-1 as a special case.  And it does not matter
whether the domain is "local" or not, virtual(5) rewrites all recipient
addresses as each message is received.

https://www.postfix.org/OVERVIEW.html
https://www.postfix.org/ADDRESS_REWRITING_README.html

> I had thought that 1-to-many (e.g. email address "adiscussion" to be
> send to user a, user b, & user c) would be done in alises.

The virtual(5) table is an alias table, one that is used as messages
are received, before they enter the active queue, and are resolved
to a delivery transport. See:

https://www.postfix.org/ADDRESS_REWRITING_README.html

> But you're saying that 1-to-many should be done in virtual, but that
> "lists" would be in aliases. That's very very confusing to me as
> simple lists (without a listserver) would've seemed to be done via
> aliases.

No, only lists that need an owner-alias or use ":include:" syntax.
These are lists with a dynamic or large subscriber count, or that
forward out to remote recipients, and have a list owner-address, ...

> > Add "local.invalid local" to the transport(5) table,  and rewrite
> > anything that needs local(8) delivery to mailbox@local.invalid.
> 
> I honestly re-read the above sentence several times and have no clue
> what it means nor why to do it. "local.invalid" is not something I've
> come across.

It is a reserved domain name, (one of many) that you can use internally,
without clashing with *real domains*.

> In my reading previously, I had not come across "the transport(5)
> table" so, again, that'll take a while to understand.

See the OVERVIEW documentation, and read Patrick and Ralf's book.
The transport(5) table maps (mostly domains, but also optionally
user@domain) to a transport and optional nexthop.

> > The syntax of virtual(5) is documented in that manpage.
> 
> There is NOTHING in there that I could find about how to say
> "user@somehosted.domain is to be rejected".

Precisely, so you can't use it to reject mail.  That's what
access(5) is for, though transport(5) can also do that, by
mapping some addresses to the "error" transport, which will
also cause bounces when mail is submitted locally, while access(5) is
only used to reject SMTP recipients.  See:

https://www.postfix.org/SMTPD_ACCESS_README.html

> Since that's what I've got
> in my sample "virtusertable" and in my comments, that is a specific
> need that I could not locate in postfix documentation of how to do it.

But you're looking at the problem from the wrong end, just asking for
magic recipes whose quality you cannot assess, because you've not
studied the available mechanisms.  The more productive approach is
to take the time to understand all of

OVERVIEW
ADDRESS_REWRITING_README
VIRTUAL_README

> e.g. searching for the word "reject" or "error" is postfix.org is not
> helpful. Hence this query email. Once again, I thought that my
> situation and query was quite clear.

Start at: https://www.postfix.org/documentation.html

Read the various relevant tutorials.

> > This is not a rewrite, and so goes into the transport(5) table (also
> > see error(8)).
> 
> It was not at all clear that "virtual" is used to rewrite only.

Linked from virtual(5):

The main applications of virtual aliasing are:

(https://www.postfix.org/ADDRESS_REWRITING_README.html#virtual)

   o  To redirect mail for one address to one or more addresses.

   o  To  implement  virtual  alias  domains  where  all addresses are
  aliased to addresses in other domains.

> And as I said, there wasn't any clear "pointer" (i.e. no clue) of how
> in postfix to designate some email address to be rejected.

Start at documentation.html, then the sections under "SMTP Relay/access
control", and some of the ones that look relevant under "General
configuration" and any other sections.

> > See above, but transport and access(5) table entries don't use a leading
> > "@".
> 
> My "comment" above from my virtusertable is: block all other email of
> a hosted domain, so again I thought that my query of what I wanted to
> do but did not know how to do it was clear...

See the access control docs, but also note that:

- In a virtual alias domain (if you configure any), all names not
  mapped to some recipient in another domain are rejected.

- You can reject SMTP recipients via various restriction checks
  that perform access(5) lookups against tables of your choice.

- You can route some recipients to the error(8) transport, and
  this will also lead them to be rejected at SMTP time.

> If I have many lines in virtual mapping several email addresses for a
> 

[pfx] Re: Help please on converting SENDMAIL VIRTUSERTABLE to postfix

[Viktor Dukhovni via Postfix-users]

On Mon, Mar 18, 2024 at 02:04:55PM +1100, Phil Biggs via Postfix-users wrote:

> Monday, March 18, 2024, 1:52:46 PM, Glenn Tenney via Postfix-users  wrote:
> Not sure about the rest of your requirements but perhaps
> 
> smtpd_recipient_restrictions = reject_unverified_recipient
> 
> https://www.postfix.org/ADDRESS_VERIFICATION_README.html
> 

NO, there's no need for that.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Help please on converting SENDMAIL VIRTUSERTABLE to postfix

[Viktor Dukhovni via Postfix-users]

On Sun, Mar 17, 2024 at 01:22:29PM -0700, Glenn Tenney via Postfix-users wrote:

> I have to convert all of my "virtusertable" entries over to postfix.
> I've read through
> https://www.postfix.org/VIRTUAL_README.html &
> https://www.postfix.org/postconf.5.html &
> https://www.postfix.org/virtual.5.html and my questions aren't
> resolved...
> 
> Question 1: Am I correct that all (or most) of this be done with a
> virtual_alias_maps table (i.e. hash:/usr/local/etc/postfix/virtual)?
> If not, then: HOW?

Most of what?  You need to be specific, it's been some decades since
many of us have looked at Sendmail.  Much depends on what sort of
mappings you're looking to emulate.

For 1-to-many recipient rewrites, the best vehicle is indeed virtual(5),
but if you also use local aliases(5), and $myorigin is listed in
$mydestination, then you need to be sure that any RHS recipients in
in aliases(5) that require virtual(5) rewriting are qualified with
a domain that is not listed in $mydestination.  Otherwise, local(8)
will deliver these directly, despite any virtual(5) overrides.

My general advice is to use aliases(5) very sparingly, just for lists
that require an "owner-" or ":include:" lists.  All other rewrites
should be via virtual(5), and perhaps even keep $mydestination empty!

Add "local.invalid local" to the transport(5) table,  and rewrite
anything that needs local(8) delivery to mailbox@local.invalid.

> Question set 2: Here's an excerpt (sanitized) of my "virtusertable".
> Does this just go into my hash:/usr/local/etc/postfix/virtual as-is?
> or what?

The syntax of virtual(5) is documented in that manpage.

> Am I correct that this table needs to have all specific user
> entries for a domain appear before the "@domain" entry for all other
> users at that domain?

Entry order does not matter for source files of indexed tables (hash,
btree, cdb).

> # should this be an alias? (I don't recall how/why/when it ended up in
> my virtusertable)
> auser@mylocal.domainanotheruser@mylocal.domain

This is a fine entry for virtual(5) aliases.

> # do all of the other entries just go into
> hash:/usr/local/etc/postfix/virtual ???

Well, they go into the source file, the "postmap" command then
builds the hash table.  See postmap(1) for details.

> # just wanting to block email to a local user
> user1@mylocal.domainerror:nouser 550 No such user here now or ever

This is not a rewrite, and so goes into the transport(5) table (also 
see error(8)).

user1@mylocal.domainerror:5.1.1 No such user here now or ever

and/or an acess(5) table referenced in your recipient restrictions:

user1@mylocal.domainREJECT 5.1.1 ...

> # send all other email of mylocal.domain to a specific user here
> @mylocal.domain another2user@mylocal.domain

Wildcard rewrites are supported, but strongly discouraged.

> # block all email to a specific user at a hosted domain
> user2@hosted1.domainerror:nouser 550 Getting too much spam

See above.

> # send all email to a specific user at a hosted domain to a user at
> the local domain
> user3@hosted1.domainsomeuser@mylocal.domain

Fine, the domin is irrelevant.

> # block all other email of a hosted domain
> @hosted1.domainerror:nouser 550 Getting too much
> spam userid changed

See above, but transport and access(5) table entries don't use a leading
"@".

> # send all email for a hosted domain to some other email somewhere
> @somehosted3.domain someuser@someother.domain

See above.  Overall, read (and if unclear ask) about the functionality
and syntax of various Postfix features, rather than whether some random
Sendmail syntax does or does not translate directly to virtual(5).

Once you what virtual(5) does (rewrite an input envelope recipient
address to one or more recipient addresses), your questions are
answered.  Similar advice for transport(5), (various) access(5), ...
tables.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: postfix not working with squarespace domains

[Viktor Dukhovni via Postfix-users]

On Sun, Mar 17, 2024 at 09:38:27AM -0500, Paxton Houston via Postfix-users 
wrote:

> i'm trying to set up a mail server using postfix. i currently have a
> squarespace domain and are using mailutils to send the email. do i need to
> set up some kinda dns record? thanks bye

For novice users wanting a self-hosted mail server, I'd like to
recommend a turnkey approach: https://mailinabox.email

One still needs appropriate IP connectivity and DNS delegations,
but this should be covered by the documentation.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Behavior of smtp_tls_security_level = dane

[Viktor Dukhovni via Postfix-users]

On Sun, Mar 17, 2024 at 03:19:02PM +0100, Dirk Stöcker via Postfix-users wrote:
> Hallo,
> 
> > On my machine, the authoriative server (BIND) only listends on the
> > the ethernet IP interface, while the recursive server (unbound)
> > listends only on 127.0.0.1.  It validates queries for my own domain,
> > just like for any other.
> 
> I wanted to prevent installing and caring for two software instances on such
> a minor system.

Both resolvers can be BIND if you prefer, I just like unbound as a
recursive resolver, and it is easier to not confuse the two when
they use different software and control utilities.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Behavior of smtp_tls_security_level = dane

[Viktor Dukhovni via Postfix-users]

On Sat, Mar 16, 2024 at 11:04:46PM +0100, Dirk Stöcker via Postfix-users wrote:

> From the server which has the local name server the answer has the
> aa flag, but not the ad flag.

That's expected when the nameserver in question is authoritative for the
requested domain, no DNSSEC validation is performed, since the data is
(presumably) from a trusted source.  It is up to recursive servers to
validate it as needed.

Your configuration where the same server is both authoritative and
recursive is not supported.  The risk with trusting that AA-bit is that
the server might be a secondary server for the zone, with an insecure
channel for zone transfers, in which case the AA bit cannot be trusted.

Postfix only trusts the AD bit from a validating local resolver, and
trusting the AA bit would have be a new configuration option, but
simpler to never mix authoritative and recursive service in the same
nameserver process.

On my machine, the authoriative server (BIND) only listends on the
the ethernet IP interface, while the recursive server (unbound)
listends only on 127.0.0.1.  It validates queries for my own domain,
just like for any other.


> So two tasks for me:
> a) fix the internal DNSSEC issue

Nothing to fix in DNSSEC, rather, split the auth and recursive
resolvers.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Behavior of smtp_tls_security_level = dane

[Viktor Dukhovni via Postfix-users]

On Fri, Mar 15, 2024 at 10:13:01PM +0100, Dirk Stöcker via Postfix-users wrote:

> I recently did a misconfiguration of an internal mail server for a test
> system and as a result broke the TLSA record.

Exactly *how* was the TLSA record broken? Logs? And were alternative MX
hosts available for the destination domain? ... Without technical
details, your anecdotal experience can at best just elicit sympathy.

> Postfix still delivered mail to the system now with Trusted instead of
> Verified (BTW I find these two outputs texts misleading, each time I
> check the logs I look for a reference server to know which of the two
> is which, couldn't you find something more explicit?).

That's not generally expected, because the default is not trust any
WebPKI CAs, but perhaps you explicitly specified a non-empty
smtp_tls_CAfile or smtp_tls_CApath?

> That was a really unexpected behavior for me so I looked in the
> documentation for "smtp_tls_security_level = dane" in
> https://www.postfix.org/TLS_README.html#client_tls_dane and really there it
> says "If TLSA records are published for a given remote SMTP server (implying
> TLS support), but are all "unusable" due to unsupported parameters or
> malformed data, the Postfix SMTP client will use mandatory unauthenticated
> TLS."

Well, were the TLSA records unusable (bad usage, selector or matching
type parameters or bad data), or were they usable, but simply did not
match the presented certificate chain?  The former will lead to
"encrypt", the latter will skip the MX host and either defer delivery
or use another MX host.

> Now I understand the rationale behind this.

Still unclear what "this" is.  Unusable TLSA records are treated as a
signal to "encrypt", but do not signal an (impossible) authentication
requirement.

> You want to prevent mail breaking because of too many bad
> configurations, but in this case I think a more strict DANE setting is
> missing:

If you want DANE for a particular destination, you can use "dane-only".

If you want opportunistic DANE TLS (RFC7672), for random destinations
with no *prior* expectation of security, then treating unusable
parameters as "encrypt" makes sense.

> * I agree that at the moment it can be a good idea not to enforce DANE for
> "unsupported parameters" or "malformed data" (even though I think there
> should be a way to make this an error).

We'll agree to disagree about that.

> * But I would expect that DANE is enforced when data is well-formed and with
> supported parameters but simply wrong, like in my case old.

That's actually the case.  Well-formed, but "simply wrong" (not matching
the cert chain) TLSA records are strictly enforced.  Otherwise, what'd
be the point of DANE TLSA records?

> Would it be possible to add a "dane-strict" setting which enforces
> correct DANE always, when there are TLSA records or at least
> acceptable but not matching TLSA records (I assume changing "dane"
> option is out of the question)?

DANE TLSA records are strictly enforced when "well-formed", where
well-formed also requires a plausible TLSA "associated data" field
(expected length for SHA2-256 and SHA2-512 digests and valid DER
encoding of certs or keys for matching type Full(0)).

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Dynamic transport?

[Viktor Dukhovni via Postfix-users]

On Wed, Mar 13, 2024 at 04:29:19PM +, Colin McKinnon via Postfix-users 
wrote:

> In my previous question [1] Viktor Dukhovni suggested
> 
> > you could use a policy service to impose rate limits per SASL login, or
> > sender address
>
> as a means of preventing active queue congestion.

http://www.postfix.org/SMTPD_POLICY_README.html

> This took me down a bit of a rabbit hole looking at SMTP Access Policy
> delegation and tcp_tables.

You don't need "tcp_tables" here, the protocol for policy services is
described in:

http://www.postfix.org/SMTPD_POLICY_README.html#protocol

There are multiple examples of existing policy services.

> However I have not managed to find much
> (ANY???!!!) information on what the server responses should look like.

See the protocol definition linked above.

> Although I don't yet know exactly what they look like, I have only seen
> mention of accepting or rejecting emails at submission using SMTP Access
> Policy delegation.

Or deferring, with 4XX, if submission is from an MTA that can queue for
a later retry.

> I really want to be able to generate, on a per message basis, the
> behaviours that I currently have statically defined in a transport map.
> These are:
> 
> (condition1)   customtransport:

Unclear how this avoids active queue congestion.

> (condition2)   smtp:[othernode]

Or this.  If a much larger queue size limit and much larger delivery
agent limit don't solve the problem, you need backpressure to reduce
the input rate, which tweaking output parameters will not achieve,
unless somehow you get much better latency for some destinations (which
is fine to do of course).

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix + Dovecot FreeBSD - a problem

[Viktor Dukhovni via Postfix-users]

On Mon, Mar 11, 2024 at 10:30:19PM -0700, Glenn Tenney wrote:

> > Right, the missing "client=" is because the message was not accepted,
> > and so no queue id was assigned.  It seems this was before the changes
> > to master.cf were made effective.
> 
> Ok... that does sound like it's always been this way...
> So, any idea of what's causing that?

As I mentioned, "client=" is logged for messages that are accepted, that
wasn't yet the case in the examples you posted.  So nothing to see here,
move along.

> Just wondering, could it maybe be "-o
> smtpd_sasl_security_options=noanonymous" -- I'm just asking because I
> saw "Anonymous TLS connection established from
> mail-ua1-f50.google.com[209.85.222.50]" in the logs I've sent.

Your intuiting is way off base, best to resist the temptation to make
guesses.  If you don't know, that's fine, no need to waste time chasing
shadows, just ask.

> > Well, if you've restarted Postfix after those changes, it should now
> > work (a "reload" should actually suffice, but a restart is harmless for
> > a low-volume personal server).
> 
> Oh, I always do "sudo postmap main.cf" when editing it and then, again
> always, do "sudo service postfix restart" after every change before
> every test.

That's pointless, "main.cf" is not a table that needs to be indexed.
What you should be running through "postmap" is various "hash:" or
"btree", ... tables defined in your configuration, after changing the
source file.

Well, at this point, post in one message:

- Logging of a submission failure postdating your most recent
  changes and "postfix restart".
- Output of: postmap -q au...@domain.name $(postconf -xh 
smtpd_sender_login_maps)
- Output of: postconf -nf
- Output of: postconf -Mf

And do double-check that the (I assume obfuscated in your posts) "auser"
in the log entries match the lookup key used in the postmap query, and
the reported value matches the logged mismatch.

Mar 8 20:41:08 MACHINE postfix/submission/smtpd[28831]: NOQUEUE:
reject: RCPT from mail-oo1-f41.google.com[209.85.161.41]: 553 5.7.1
: Sender address rejected:

That's the envelope sender address that should be the lookup key in your
table.

not owned by user auser;

That's the authenticated SASL user name that should be the corresponding
value.

from= to=
proto=ESMTP helo=

This is is just context.  Clearly the lookup table did NOT return
"auser" for that address, otherwise the message would not have been
reject as a sender-login mismatch.

Where is your configuration directory?  Are you editing
"/etc/postfix/main.cf", or /usr/local/etc/postfix/main.cf?

Which "postfix" command are you running, "/usr/sbin/postfix" or
"/usr/local/sbin/postfix"?  You probably have Postfix both in the base
system and from ports.  Make sure you're editing the files and using the
commands from /usr/local...  And that the Postfix that is running
(master process, and service daemons) are also the ones from
/usr/local/libexec...

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix + Dovecot FreeBSD - a problem

[Viktor Dukhovni via Postfix-users]

On Mon, Mar 11, 2024 at 07:50:22PM -0700, Glenn Tenney via Postfix-users wrote:

> > You should also remove the "smtpd_sasl_auth_enable = yes" from
> > "mail.cf", leaving just the "-o smtpd_sasl_auth_enable=yes" above, and
> > in main.cf set:
> 
> No "mail.cf", but only "-o" is left...

I meant "main.cf" of course...

> > Well, it has to be there, unless your syslog configuration filters it
> > out.  Here's an example (long line folded) from my system:
> >
> > Mar 10 18:28:39 amnesiac postfix/submission/smtpd[555754]:
> > 00D8B893CE0: client=, sasl_method=,
> > sasl_username=
> 
> I truly have no clue why my maillog is so different than yours. I set
> "smtpd_tls_loglevel = 2" and here's the log (on the machine running
> postfix @ domain.name) from gmail connecting, and logging in as
> "auser" and then trying to send an email as "auser" back to me here at
> gmail:

So you decided to add more hay to stack to hide the needle? :-)
Best to set the log level back to 1.

> Mar 11 18:57:11 MACHINE postfix/submission/smtpd[40225]: NOQUEUE:
> reject: RCPT from mail-ua1-f50.google.com[209.85.222.50]: 553 5.7.1
> : Sender address rejected: not owned by user auser;
> from= to= proto=ESMTP
> helo=

Right, the missing "client=" is because the message was not accepted,
and so no queue id was assigned.  It seems this was before the changes
to master.cf were made effective.

> And with all of the various changes made, here's the most recent postconf -Mf
> 
> smtp   inet  n   -   y   -   -   smtpd
> submission inet  n   -   n   -   -   smtpd
> -o syslog_name=postfix/submission
> -o smtpd_tls_wrappermode=no
> -o smtpd_tls_security_level=may
> -o smtpd_sasl_auth_enable=yes
> -o 
> smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
> -o milter_macro_daemon_name=ORIGINATING
> -o smtpd_sasl_type=dovecot
> -o smtpd_sasl_path=private/auth
> -o smtpd_sasl_security_options=noanonymous
> -o smtpd_sasl_local_domain=$myhostname
> -o smtpd_client_restrictions=permit_sasl_authenticated,reject
> -o smtpd_sender_restrictions=reject_sender_login_mismatch

Well, if you've restarted Postfix after those changes, it should now
work (a "reload" should actually suffice, but a restart is harmless for
a low-volume personal server).

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix + Dovecot FreeBSD - a problem

[Viktor Dukhovni via Postfix-users]

On Mon, Mar 11, 2024 at 03:17:01PM -0700, Glenn Tenney via Postfix-users wrote:

> So, the actual SASL login is "auser"? (which is what I've told gmail
> to use to login)

I don't know what it is, the logs will tell the true story.  Please post
both the "client=" and the "reject:" log entries for one one the failed
attempts from Gmail to use your server as an outbound relay.

> > No, the issue is the content of your sender login table.
> 
> My current guess is that the virtual or senderlogin files are wrong
> and that's my problem...

The actual problem was stated above, I'm puzzled why you're still
"guessing"...

> Sorry, I forgot to include the contents of my smtpd_sender_login_maps file:
>   # senderlogin
>   au...@domain.name   auser
>   au...@machine.domain.name   auser

The reject message in your original post was:

Mar 8 20:41:08 MACHINE postfix/submission/smtpd[28831]: NOQUEUE:
reject: RCPT from mail-oo1-f41.google.com[209.85.161.41]: 553 5.7.1
: Sender address rejected: not owned by user auser;
from= to=
proto=ESMTP helo=

Which means that the lookup key "au...@domain.name" does not in fact map
to "auser" in the indexed (hash table) file:

smtpd_sender_login_maps = hash:/usr/local/etc/postfix/senderlogin

You can examine the hash table with:

postmap -q au...@domain.name hash:/usr/local/etc/postfix/senderlogin

> And here's /etc/virtual (again, my best guess of what it should be)

Irrelevant to the reported problem.

> > If you post also the "client=" log entry for the transaction of
> > interest, the "postconf -Mf" output and the content of the sender login
> > table, more help will be possible.
> 
> I don't see "client=" anywhere in the logs... but here's the "postconf
> -Mf" after making the changes you suggested above:

Well, it has to be there, unless your syslog configuration filters it
out.  Here's an example (long line folded) from my system:

Mar 10 18:28:39 amnesiac postfix/submission/smtpd[555754]:
00D8B893CE0: client=, sasl_method=,
sasl_username=

> submission inet  n   -   n   -   -   smtpd
> -o syslog_name=postfix/submission
> -o smtpd_tls_wrappermode=no
> -o smtpd_tls_security_level=may
> -o smtpd_sasl_auth_enable=yes
> -o 
> smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
> -o milter_macro_daemon_name=ORIGINATING
> -o smtpd_sasl_type=dovecot
> -o smtpd_sasl_path=private/auth
> -o smtpd_sasl_security_options=noanonymous
> -o smtpd_sasl_local_domain=$myhostname
> -o smtpd_client_restrictions=permit_sasl_authenticated,reject
> -o smtpd_sender_login_maps=hash:/etc/virtual
> -o smtpd_sender_restrictions=reject_sender_login_mismatch

This is where you're requiring the envelope sender address to match the
expected login, and have for no particular reason included:

> -o smtpd_sender_login_maps=hash:/etc/virtual

Which explains the source of the problem.  Just remove that erroneous
setting.  The virtual(5) alias table is not your sender -> sasl login
table.

You should also remove the "smtpd_sasl_auth_enable = yes" from
"mail.cf", leaving just the "-o smtpd_sasl_auth_enable=yes" above, and
in main.cf set:

smtpd_tls_auth_only = yes

Also in the above submission service set:

smtpd_tls_security_level=encrypt

(not "may").

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix + Dovecot FreeBSD - a problem

[Viktor Dukhovni via Postfix-users]

On Sun, Mar 10, 2024 at 09:19:09PM -0700, Glenn Tenney via Postfix-users wrote:

> Gmail can login to the imap as "auser", but...  when it tries to send
> as "au...@domain.name" I get the following error:
> 
> Mar 8 20:41:08 MACHINE postfix/submission/smtpd[28831]: NOQUEUE:
> reject: RCPT from mail-oo1-f41.google.com[209.85.161.41]: 553 5.7.1
> : Sender address rejected: not owned by user auser;
> from= to=
> proto=ESMTP helo=

You've implemented smtpd_sender_login_maps and
reject_sender_login_mismatch or an equivalent variant, but the entry
for that sender address does list the actual SASL login used (which
is shown in an earlier log entry for the same SMTP transaction).

> I'm guessing that the issue is that postfix/dovecot sees only "auser"
> and if instead it saw "au...@domain.name" it would work, but I
> couldn't find any way to be able to login that way.

No, the issue is the content of your sender login table.

> (2) Postfix sends to gmail, but does not encrypt when sending.

You need to enable outbound STARTTLS, possibly mandatory for
"smtp.gmail.com", ideally even with certificate checks, to avoid leaking
the account password in case of an MiTM attack.  Is this submission
traffic, or traffic to random gmail users?

> shlib_directory = /usr/local/lib/postfix
> smtp_tls_CApath = /etc/ssl/certs
> smtp_tls_loglevel = 1

Missing "smtp_tls_security_level = may".  And if doing submission via
GMail, ideally also a TLS policy table entry for "[smtp.gmail.com]:587",
though it is not yet clear how you route mail to the GMail submission
service.

> smtpd_sasl_auth_enable = yes

Best done only for the TLS submission ports, in master.cf and left
disabled on port 25.

> smtpd_sender_login_maps = hash:/usr/local/etc/postfix/senderlogin

This (combined with unposted definitions, postconf -Mf, of the
submission services in master.cf) is the source of breakage in #1.

> smtpd_tls_protocols = !SSLv2, !SSLv3

Just use the default.

> smtpd_tls_security_level = may
> smtpd_use_tls = yes

The second is redundant and obsolete (deprecated).

If you post also the "client=" log entry for the transaction of
interest, the "postconf -Mf" output and the content of the sender login
table, more help will be possible.

-- 
Viktor.
___
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:58:38PM -0500, Wietse Venema via Postfix-users wrote:
> 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

OK, so that'd then be: postfix/relay/smtp.  [ "collate" will handle
that gracefully. ]  One can search for "postfix[^ ]*/smtp" or
"postfix/relay/", ... depending on the goal in mind.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: mta-sts and smtp_tls_security_level

[Viktor Dukhovni via Postfix-users]

On Sat, Mar 09, 2024 at 07:21:53PM +0100, Joachim Lindenberg via Postfix-users 
wrote:

> I thought almost all cloud providers use anycast these days,
> elminating the need to serve different IPs per region.

No. That's not the case.  Anycast is a useful tool, but isn't the whole
story.  The responses vary by location and over time within the same
location.

- NYC:

$ dig +short -t a www.google.com
142.250.65.196

... a few minutes later ...

$ dig +short -t a www.google.com
142.250.176.196

- LAX:

$ dig +short -t a www.google.com
142.250.72.132

... a few minutes later ...

$ dig +short -t a www.google.com
142.250.188.228

- MEL:

$ dig +short -t a www.google.com
142.250.70.228

- MUC:

$ dig +short -t a www.google.com
142.250.186.164

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: mta-sts and smtp_tls_security_level

[Viktor Dukhovni via Postfix-users]

On Sat, Mar 09, 2024 at 10:46:17AM +0100, Joachim Lindenberg via Postfix-users 
wrote:
> > Viktor Dukhovni:
> > not sufficient market pressure to make it a priority.
> Unfortunately yes, not yet.
> > various load balancers would need to do online DNSSEC signing
> Can you please elaborate why that should be required?

Some of the load balancing is DNS-based, directing users to "nearby"
datacentre locations, that are currently up and not experiencing
overload.  So names like "www.google.com" have return addresses with
short TTLs and different content for different queries.

Static DNSSEC signing is a poor fit for this, so signing needs to be
on-the-fly.  Cloudflare does this, so there a proof of concept, but
it is a non-trivial implementation requiring some engineering effort,
well beyond just spinning up BIND or Knot for a statically signed zone.

-- 
Viktor.
___
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.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: mta-sts and smtp_tls_security_level

[Viktor Dukhovni via Postfix-users]

On Fri, Mar 08, 2024 at 11:11:40PM +0100, Joachim Lindenberg via Postfix-users 
wrote:

> But is there any reason that prevents google to use DNSSEC other than
> the arrogance of power?

My read is that there is not sufficient market pressure to make it a
priority.  Robust implementation at scale is non-trivial, (various
load balancers would need to do online DNSSEC signing) and resources
for work that is not a business priority are scarce.

I can more easily see "gmail.com" being signed, but even there the
incentives need to get stronger before that happens.  Yes, mta-sts is an
ugly hack that makes it possible to somewhat sweep the problem under the
rug.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: mta-sts and smtp_tls_security_level

[Viktor Dukhovni via Postfix-users]

On Fri, Mar 08, 2024 at 10:01:29PM +0100, Joachim Lindenberg via Postfix-users 
wrote:

> Imho you get pretty close to mta-sts if you use verify together with a
> DNSSEC-validating resolver. You just validate the "authorized" MTAs by
> different means.

Yes, but google.com and yahoo.com (the domains mentioned by the OP), are
not presently DNSSEC-signed. :-(

-- 
Viktor.
___
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 -".
:-)

-- 
Viktor.
___
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 09:23:19PM +0200, Mailinglists35 via Postfix-users 
wrote:

> 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 problem is with the "postmap" command, not the regular expression.

$ printf "foo\nbar\n" | postmap -q - "pcre:{{/foo/ a}, {/bar/ b}}"
foo a
bar b

By default, postmap reads a separate key from each input line.  For
simulating reading of message headers, you need the "-h" option:


$ printf "X: foo\n\tbar\n" | postmap -hq - "pcre:{{/foo.*bar/ a}, {/bar/ 
b}}"
X: foo
bar a

And you DO NOT want or need a "/m" option for your pattern.  Your use of
"^" should match only at the start of the logical header, not at the
start some folded line.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: mta-sts and smtp_tls_security_level

[Viktor Dukhovni via Postfix-users]

On Fri, Mar 08, 2024 at 01:28:00PM -0500, Michael W. Lucas via Postfix-users 
wrote:

> Realistically, Gmail and Yahoo do not care about my MTA-STS
> reports. All they care about is that I validate their X.509 certs.
> 
> Is there any reason to use something like mta-sts-daemon in that
> transport instead of just setting smtp_tls_security_level=verify ?

Just using verify leaves you more vulnerable to DNS-based MiTM attacks,
because "verify" uses unvalidated MX hostnames as the "reference
identifiers" in certificate matching.

With "mta-sts", you are expected to obtain a trusted copy of the MX host
list via HTTPS (trusting one of various WebPKI CAs to authenticate the
website).  The attacker first has to obtain a forged certificate for
"mta-sts.", and then forged certificates for one of the
MX hosts.

If you independently obtain, and periodically recheck, the list of MX
hosts for one or more domains, you can use a TLS policy that lists
those names as the names to check, with either "verify" or "secure",
which are identical once you explicitly specify the match names.

example.com secure match=mx1.example.com:mx2.example.com

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Active queue congestion

[Viktor Dukhovni via Postfix-users]

On Thu, Mar 07, 2024 at 01:11:09PM -0500, Wietse Venema via Postfix-users wrote:

> > 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.

A million messages on a typical modern server system with 100+ GB of RAM 
should not be a problem.  If a typical message costs ~10k of RAM, that'd
still be "just" 10GB, which should be fine.  Somewhere north of that
you'd start to run out of room.

But it is of course best to not let a small set of users "hog" the queue
to the tune of of multiple 100k messages.  Hence rate limits.  If the
limits are sufficiently well explained to the users, they may/should be
able to tune their submission rates to avoid hitting the limits.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: verifying postfix github repo source tarballs?

[Viktor Dukhovni via Postfix-users]

On Thu, Mar 07, 2024 at 05:26:08PM -0500, pgnd via Postfix-users wrote:

> I understand the "only official" release sources are the tarballs,
> 
>   TARBALL DL FROM MIRROR SITE
>   wget 
> https://mirror.reverse.net/pub/postfix-release/official/postfix-3.8.6.tar.gz
>   sha1sum postfix-3.8.6.tar.gz
>   19a387be8e3c2be239d7b4009a6b0b4af96b5c23  
> postfix-3.8.6.tar.gz
>   tar zxvf postfix-3.8.6.tar.gz
>   sha1sum $(find -type f -iname "postfix.c")
>   deb2575c7788ea1703e3b306333dbd4a3cf3f3cf  
> ./postfix-3.8.6/src/postfix/postfix.c
> 
> For my own workflow/convenience, my pref is to grab Viktor Dukhovni's
> (unofficial?) git mirror release-tag's archive tarball,

My github repo is not an official alternative distribution mechanism.
It primarily serves my own needs, and secondarily the needs of
developers or users who want a convenient way to examine Postfix
development history.

> Is there a convenient/reliable method to similarly verify the entire
> archive tarball, &/or the github repo source ?

I do not sign the release tags, so no there is no way to check that they
match Wietse's code, other than by comparing against Wietse's signed
tarballs.

If Wietse some day chooses to release Postfix via github, he may at that
point choose to generate signed release tags.

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Thu, Mar 07, 2024 at 04:24:56PM +0100, Ralf Hildebrandt via Postfix-users 
wrote:
> * Matus UHLAR - fantomas via Postfix-users :
> 
> > > envelope sender address and number of recipients.
> > 
> > not authenticated user? ;-)
> 
> Yes, I'm also checking if the come from our exchangeserver.
> 
> > if you want to see/process mail size, using it in
> > smtpd_end_of_data_restrictions is necessary.
> > if not, you can use it in smtpd_data_restrictions.
> 
> Then I shall try that instead, since I don't care about the size of
> the mail.
> 
> > However, I'd say the optimal place is where you need it.  Before
> > smtpd_data_restrictions you don't see recipient_count either.
> 
> Yup.

Note that if you want the actual recipient addresses, (not just a
count), you'll need to also intercept recipient restrictions.  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).

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Active queue congestion

[Viktor Dukhovni via Postfix-users]

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

[pfx] Re: DNSBL rank log messages after HANGUP

[Viktor Dukhovni via Postfix-users]

On Thu, Mar 07, 2024 at 01:06:53PM +1100, Phil Biggs via Postfix-users wrote:

> Today I noticed that, occasionally, I see a syslog message stating "blocked 
> using zen.spamhaus..." but no matching "DNSBL rank ..." message. 
> 
> A couple of examples from the past two days:
> 
> postfix/postscreen 84893 - - CONNECT from [43.157.61.211]:30092 to 
> [192.168.11.2]:25
> postfix/dnsblog 84894 - - addr 43.157.61.211 listed by domain 
> zen.spamhaus.org as 127.0.0.11
> postfix/postscreen 84893 - - HANGUP after 3.2 from [43.157.61.211]:30092 in 
> tests before SMTP handshake

-
> postfix/postscreen 84893 - - DISCONNECT [43.157.61.211]:30092
> 
> Some other syslog records do have the DNSBL rank.  For example:
> 
> postfix/postscreen 86907 - - CONNECT from [185.242.226.22]:49012 to 
> [192.168.11.2]:25
> postfix/dnsblog 86910 - - addr 185.242.226.22 listed by domain 
> zen.spamhaus.org as 127.0.0.3
> postfix/postscreen 86907 - - DNSBL rank 2 for [185.242.226.22]:49012
> postfix/postscreen 86907 - - HANGUP after 0.8 from [185.242.226.22]:49012 in 
> tests after SMTP handshake

 

The client hung up too early for a rank to be logged.

-- 
Viktor.
___
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?

-- 
Viktor.
___
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

[Viktor Dukhovni via Postfix-users]

On Wed, Mar 06, 2024 at 07:12:18PM -0500, Alex via Postfix-users wrote:

> 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?

Keep the configurations in a git repository and pull them as root, using
an SSH key in batch mode with a preseeded known-hosts file.  Pull only
the source files for tables, and then run "make" to run "postmap", ...

You could use an 'https' git remote URL, but without additional
configuration that trusts too many CAs, so SSH is better.

> 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.

That'd be a mistake, Postfix configuration files should belong to root.

> Postifx complains when changing ownership of these files to a regular
> user, so I thought of using setfacl on the individual files I need. Will
> that cause a problem?
> 
> # setfacl -m g:appuser:rwx /etc/postfix
> # setfacl -m g:appuser:wx /etc/postfix/client_checks.cidr
> # setfacl -m g:appuser:wx /etc/postfix/recipient_checks
> 
> $ postmap recipient_checks
> $ ls -l recipient_checks*
> -rw-rwxr--+ 1 rootroot1065 Nov 15  2020 recipient_checks
> -rw-r--r--  1 appuser appuser 2305 Mar  6 18:37 recipient_checks.cdb

Avoid pushing computed binary artefacts, pull the source and run make..

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Resolve sender domains in file before resorting to database

[Viktor Dukhovni via Postfix-users]

On Wed, Feb 28, 2024 at 12:17:27PM -0600, Joshua Flanagan via Postfix-users 
wrote:

> Anyone else have suggestions on how to make sure postfix queries a file
> table _by domain_ while still having a remote database lookup table as a
> backup/last resort?

To restrict database lookups to a subset of domains use the "domain = "
table property.  IIRC you may be able to negate the condition to exclude
all but a given set of domains, or do that with 'if !/pattern/' in regex
tables.

domain = !hash:/some/table
domain = !inline:{ {example.org = skip}, ... }
domain = pcre:{
{ if !/^example\.org$/ },
{ /^/ use },
{ endif }
}

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Configuration Settings for TLS 1.2 and 1.3 with No Weak Ciphers

[Viktor Dukhovni via Postfix-users]

On Fri, Mar 01, 2024 at 08:58:07AM +0100, Alexander Leidinger wrote:

> > > tls_high_cipherlist=ALL:!RSA:!CAMELLIA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SHA1:!SHA256:!SHA384;
> > 
> > Not recommended. It disables all non-AEAD ciphers, and aNULL ciphers,
> > which are fine to use.
> 
> From the OpenSSL man page:
> ---snip---
> aNULL
> The cipher suites offering no authentication. This is currently the
> anonymous DH algorithms and anonymous ECDH algorithms. These cipher suites
> are vulnerable to "man in the middle" attacks and so their use is
> discouraged. These are excluded from the DEFAULT ciphers, but included in
> the ALL ciphers. Be careful when building cipherlists out of lower-level
> primitives such as kDHE or AES as these do overlap with the aNULL ciphers.
> When in doubt, include !aNULL in your cipherlist.
> ---snip---

That OpenSSL manpage is not aimed at opportunistic TLS, so is a poor fit
for SMTP STARTTLS.  The Postfix TLS_README and postconf(5) manpage are
more fit for purpose.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Configuration Settings for TLS 1.2 and 1.3 with No Weak Ciphers

[Viktor Dukhovni via Postfix-users]

On Fri, Mar 01, 2024 at 12:26:33AM +0100, Steffen Nurpmeso wrote:

> i still use the
> 
>   # super modern, forward secrecy TLSv1.2 / TLSv1.3 selection..
>   tls_high_cipherlist = EECDH+AESGCM:EECDH+AES256:EDH+AESGCM:CHACHA20

I don't recommend cargo-culting random cipher lists.

>   smtpd_tls_mandatory_ciphers = high
>   smtpd_tls_mandatory_exclude_ciphers = TLSv1

In pratice, this boils down to

ECDHE-ECDSA-AES256-SHA  TLSv1 Kx=ECDH Au=ECDSA Enc=AES(256)  Mac=SHA1
ECDHE-RSA-AES256-SHATLSv1 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128)  Mac=SHA1
ECDHE-RSA-AES128-SHATLSv1 Kx=ECDH Au=RSA  Enc=AES(128)  Mac=SHA1

Which should all be fine (better than cleartext) for email.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Configuration Settings for TLS 1.2 and 1.3 with No Weak Ciphers

[Viktor Dukhovni via Postfix-users]

On Thu, Feb 29, 2024 at 06:36:09AM -0500, Scott Hollenbeck wrote:

> Sorry, context is important. This server needs to pass a Payment Card
> Industry (PCI) compliance scan. Their definition of weak: "key lengths of
> less than 112 bits, or else use the 3DES encryption suite". Opportunistic
> TLS is NOT a goal.

Many of The anon-DH ciphers are quite strong by that metric, they use
AES-128 or AES-256.

> > What do you consider weak?
> 
> All of the anonymous Diffie-Hellman suites with an "F" score. How can
> eliminate the following:

Who's assigning the "F" scores?  Do they in fact line up with the PCI
requirements?  As explained in:

https://www.postfix.org/TLS_README.html#client_tls_limits
https://datatracker.ietf.org/doc/html/rfc7672#section-8.2

there is nothing wrong with leaving anon-DH ciphers enabled on servers.
They can however be disabled to comply to with clueless auditors by
setting:

smtpd_tls_exclude_ciphers = aNULL

or (if applicable only with mandatory TLS):

smtpd_tls_mandatory_exclude_ciphers = aNULL

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Configuration Settings for TLS 1.2 and 1.3 with No Weak Ciphers

[Viktor Dukhovni via Postfix-users]

On Thu, Feb 29, 2024 at 08:59:44AM +0100, Alexander Leidinger via Postfix-users 
wrote:

> # grep tls main.cf | grep -vE '^#'

> smtp_tls_security_level = encrypt
> smtpd_tls_ask_ccert = yes
> smtpd_tls_CApath = $smtp_tls_CApath

Not generally applicable.

> smtp_tls_mandatory_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1
> smtp_tls_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1
> smtpd_tls_mandatory_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1
> smtpd_tls_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1

Obsolete syntax.

> tls_random_source = dev:/dev/urandom
> smtpd_tls_eecdh_grade = auto

Best defaulted.

> smtp_tls_CApath = /etc/ssl/certs

Pointless except when the security level is "secure" (or "verify").

> tls_high_cipherlist=ALL:!RSA:!CAMELLIA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SHA1:!SHA256:!SHA384;

Not recommended. It disables all non-AEAD ciphers, and aNULL ciphers,
which are fine to use.

> tls_preempt_cipherlist = yes

This is actually a reasonable setting for a change.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Configuration Settings for TLS 1.2 and 1.3 with No Weak Ciphers

[Viktor Dukhovni via Postfix-users]

On Wed, Feb 28, 2024 at 08:55:04AM -0500, Scott Hollenbeck via Postfix-users 
wrote:

> Would someone please describe the configuration settings needed to support
> TLS 1.2 and 1.3 with no weak ciphers? Here's what I currently have in my
> configuration files:

This is not the right question.  Some "weak" ciphers are appropriate in
opportunistic TLS, because they are better than cleartext.  This applies
when they are still the best available to a non-negligible set of peers.

- Provided your system prefers stronger ciphers, and the offered
  "weak" ciphers don't put the integrrity of the handshake at
  risk, weak ciphers are fine, provided strong ones are preferred.

> smtpd_tls_dh512_param_file = /etc/ssl/private/dh512.pem

This is not needed.  Consider setting "tls_preempt_cipherlist = yes".

> Here's what I see when I use nmap to retrieve the supported ciphers (note
> that there are only TLS 1.2 ciphers listed, and some are weak):

What do you consider weak?

> 587/tcp open  submission
> | ssl-enum-ciphers:
> |   TLSv1.2:
> | ciphers:
> |   TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
> |   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
> |   TLS_DHE_RSA_WITH_AES_128_CCM (dh 2048) - A
> |   TLS_DHE_RSA_WITH_AES_128_CCM_8 (dh 2048) - A
> |   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
> |   TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
> |   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
> |   TLS_DHE_RSA_WITH_AES_256_CCM (dh 2048) - A
> |   TLS_DHE_RSA_WITH_AES_256_CCM_8 (dh 2048) - A
> |   TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
> |   TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256 (dh 2048) - A
> |   TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384 (dh 2048) - A
> |   TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
> |   TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (dh 2048) - A
> |   TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
> |   TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 (dh 2048) - A
> |   TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (dh 2048) - A
> |   TLS_DH_anon_WITH_AES_128_CBC_SHA - F
> |   TLS_DH_anon_WITH_AES_128_CBC_SHA256 - F
> |   TLS_DH_anon_WITH_AES_128_GCM_SHA256 - F
> |   TLS_DH_anon_WITH_AES_256_CBC_SHA - F
> |   TLS_DH_anon_WITH_AES_256_CBC_SHA256 - F
> |   TLS_DH_anon_WITH_AES_256_GCM_SHA384 - F
> |   TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA - F
> |   TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256 - F
> |   TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA - F
> |   TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256 - F
> |   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
> |   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
> |   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
> |   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
> |   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
> |   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
> |   TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 (secp256r1) - A
> |   TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 (secp256r1) - A
> |   TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (secp256r1) - A
> |   TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 (secp256r1) - A
> |   TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
> |   TLS_ECDH_anon_WITH_AES_128_CBC_SHA - F
> |   TLS_ECDH_anon_WITH_AES_256_CBC_SHA - F
> |   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
> |   TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
> |   TLS_RSA_WITH_AES_128_CCM (rsa 2048) - A
> |   TLS_RSA_WITH_AES_128_CCM_8 (rsa 2048) - A
> |   TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
> |   TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
> |   TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
> |   TLS_RSA_WITH_AES_256_CCM (rsa 2048) - A
> |   TLS_RSA_WITH_AES_256_CCM_8 (rsa 2048) - A
> |   TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
> |   TLS_RSA_WITH_ARIA_128_GCM_SHA256 (rsa 2048) - A
> |   TLS_RSA_WITH_ARIA_256_GCM_SHA384 (rsa 2048) - A
> |   TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
> |   TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 (rsa 2048) - A
> |   TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
> |   TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 (rsa 2048) - A

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postconf.5 smtp_tls_loglevel 2

[Viktor Dukhovni via Postfix-users]

On Wed, Feb 21, 2024 at 08:32:49AM +, Rune Philosof via Postfix-users wrote:
> It seems a bit unclearly phrased
> > 2 Also log levels during TLS negotiation.

Indeed this is not very helpful.  See the description of the "-L" option
in .

> Should it be
> > 2 Also log certificate trust\-chain verification errors even if server 
> > certificate verification is not required

Not, this is basically everythingbut the raw packet dumps.  So handshake
states, sesion cache operations, certificate matching, and more...

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org