[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

[pfx] Re: removing Authentication-Results, how?

[Viktor Dukhovni via Postfix-users]

On Tue, Feb 20, 2024 at 06:02:22PM -0500, Wietse Venema via Postfix-users wrote:

> - You'd better add $$ at the end of the pattern, to anchor the regular 
> expression.

Actually, that hostname is typically followed by additional data
separated by whitespace or a ';'.

>   header_checks = pcre:{ {/^Authentication-Results: \Q$myhostname\E$$/ 
> IGNORE} }
> 
> Note that pcre, not regexp.

Indeed PCRE is best here:

header_checks = pcre:{ {/^Authentication-Results: \Q$myhostname\E[\s;]/ 
IGNORE} }

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

[pfx] Re: What features to deprecate

[Viktor Dukhovni via Postfix-users]

On Tue, Feb 13, 2024 at 01:20:00PM -0500, Wietse Venema via Postfix-users wrote:

> > Obsoleted by automatic negotiation in the SSL code:
> > 
> > - smtpd_tls_dh1024_param_file = auto
> > - smtpd_tls_eecdh_grade = auto
> > 
> > [ We could delete the underlying support code for the explicit choices,
> >   and always use 'auto' with a warning if the configuration specifies
> >   a different choice.  Mind you, automatic DH group negotiation is
> >   prone to choosing largish > 2048-bit groups, when the server will sign
> >   with a large RSA private key, but this feels somewhat justifiable. ]
> 
> Isn't that TLS version dependent, or have we already lost support for 
> the old way?

For EECDH, "auto" has worked for a long time, and is basically an
interoperability requirement!

Automatic (FF)DH group selection in the SSL stack requires OpenSSL 3.0,
but recent Postfix versions emulate "auto" by using a compiled in DH
group, which is quite "good enough" in practice.  So "auto" already
works.

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

[pfx] Re: What features to deprecate

[Viktor Dukhovni via Postfix-users]

On Tue, Feb 13, 2024 at 06:32:14PM +0100, Geert Hendrickx via Postfix-users 
wrote:

> On Tue, Feb 13, 2024 at 12:23:32 -0500, Wietse Venema via Postfix-users wrote:
> > - masquerade_domains complicates table-driven address validation.
> > Log a deprecation warning with compatibility_levels>=3.9.
> 
> 
> What's the alternative for masquerade_domains ?

It is canonical_maps, ideally with explicit mappings for each expected
non-canonical address.  For an outbound-only Postfix relay or submission
instance, the canonical mapping could use wildcards or regular
expression mappings.  Though in the same context (no inbound mail) the
use of "masquerade_domains" has little down-side.

Of course it is best dealt with at the source by configuring the
client systems to use the correct domain.

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

[pfx] Re: What features to deprecate

[Viktor Dukhovni via Postfix-users]

On Tue, Feb 13, 2024 at 12:23:32PM -0500, Wietse Venema via Postfix-users wrote:

> Over 25 years, Postfix has accumulated some features that 
> are essentially obsolete.
> 
> - permit_mx_backup is fundamentally incompatible with recipient
> address validation. There is no way to work around that with
> reject_unverified_recipient, because that requires that a domain
> is reachable, and in that case permit_mx_backup is not needed.
> Log a deprecation warning with compatibility_levels>=3.9.
> 
> - masquerade_domains complicates table-driven address validation.
> Log a deprecation warning with compatibility_levels>=3.9.
> 
> - disable_dns_lookups can be migrated to smtp_dns_support_level
> which implements a superset of the functionality. Log a deprecation
> warning with compatibility_levels>=3.9.
> 
> What else needs to go?

Obsoleted by TLS security levels:

- lmtp_enforce_tls
- lmtp_use_tls
- postscreen_enforce_tls
- postscreen_use_tls
- smtp_enforce_tls
- smtp_use_tls
- smtpd_enforce_tls
- smtpd_use_tls
- tlsproxy_client_enforce_tls
- tlsproxy_client_use_tls
- tlsproxy_enforce_tls
- tlsproxy_use_tls

Obsoleted by TLS policy maps:

- lmtp_tls_per_site
- smtp_tls_per_site
- tlsproxy_client_per_site

Obsoleted by automatic negotiation in the SSL code:

- smtpd_tls_dh1024_param_file = auto
- smtpd_tls_eecdh_grade = auto

[ We could delete the underlying support code for the explicit choices,
  and always use 'auto' with a warning if the configuration specifies
  a different choice.  Mind you, automatic DH group negotiation is
  prone to choosing largish > 2048-bit groups, when the server will sign
  with a large RSA private key, but this feels somewhat justifiable. ]

Perhaps more controversial:

- parent_domains_matches_subdomains

This should IMHO be empty, with all parent-domain rules being explicit.
Its convenience is offset by not entirely infrequent user confusion
about where ".domain" is required (transport(5) table) and where it is
not by default (access(5) table).

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

[pfx] DANE: ATTENTION: Let's Encrypt drops DST X3 from default chain, breaking "depth 2" ISRG "2 1 1" TLSA records...

[Viktor Dukhovni via Postfix-users]

As of roughly the start of this month, the DANE survey at
 is seeing a steady stream
of validation failures for MX hosts that rely only on:

_25._tcp.mail.domain.example. IN TLSA 2 1 1 
0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3

[ Some also list a no-longer valid "3 1 1" record that broke
  when the unerlying EE key was rotated, because they failed to ensure
  that certificate renewals do not automatically rotate the key. ]

As promised by Let's Encrypt some months back, Let's Encrypt have
dropped the expired DST X3 cross-certificate from the default generated
"fullchain.pem" file, which now contains just the leaf (EE) certificate
(depth 0) and the intermediate CA (depth 1) issuer (R3, R4, E1 or E2),
the parent ISRG root CA is implicit and there's no longer a legacy
cross certificate from DST for outdated Android devices.

Domains whose MX hosts relied only on the "2 1 1" record for the
ISRG root CA (present in the cross certificate, but absent from
the new chain) are no longer passing DANE TLSA validity checks.

My notices to these domains include the below advice:

[ Perhaps consider: ?

  Your TLSA record designates a root CA key, but, as is common, the root
  CA certificate is not included in your certificate chain.  It would need
  to be incuded to work with DANE-TA(2), but simpler to use an intermediate
  CA hash instead.  See:

https://github.com/Mailu/Mailu/issues/2138
http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html
https://dane.sys4.de/common_mistakes#4
https://datatracker.ietf.org/doc/html/rfc7671#section-5.2.3

  Important information about certificate issuance changes at Let's Encrypt
  discussed at the links below:

  
https://list.sys4.de/hyperkitty/list/dane-us...@list.sys4.de/message/HESAY65XEKEW52UXYFELODTD44P25VIW/
  
https://list.sys4.de/hyperkitty/list/dane-us...@list.sys4.de/message/GLRVY2CRHYLTBNXOBRKPG7LFZKYWF7BS/
  
https://list.sys4.de/hyperkitty/list/dane-us...@list.sys4.de/message/X4SS2EEDGIYVQOHI2ZX65PIBYR652DPR/
 ]

The issues can be resolved by removing or updating the associated DNS
DANE TLSA records.

- "3 0 [12]" vs. Let's Encrypt:
  
https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022/17

- Best practice "3 1 1" rollover methodology:
  https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html

- Monitoring code snippet:
  
https://list.sys4.de/hyperkitty/list/dane-us...@list.sys4.de/thread/NKDBQABSTAAWLTHSZKC7P3HALF7VE5QY/

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

[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive

[Viktor Dukhovni via Postfix-users]

On Mon, Feb 12, 2024 at 09:05:12PM -0600, Jakob Cornell via Postfix-users wrote:

> Can we improve this so it's easier to get this right on the first try
> as a newcomer, and make it more clear what's happening at run time? It
> looks like a code change to skip the logging along with the actual
> table lookups might be in order, and some clarification in the docs.
> I'm happy to create patches for some docs changes at least if that's
> useful. Not sure what the contribution policy of the project is.

That'd be a layer-violation.  The logging code lives outside the
individual table drivers and with "_maps" parameters that support
multiple tables, above any individual table lookup.  It does not
make a lot of sense to push the logging down into each table.

Some tables support partial keys, other do not, as documented
under in regexp_table(5):

TABLE SEARCH ORDER
   Patterns are applied in the order as specified in the table,
   until a pattern is found that matches the input string.

   Each pattern is applied to the entire input string.  Depending on
   the application, that string is an entire client hostname, an
   entire client IP address, or an entire mail address.  Thus, no
   parent domain or parent network search is done, and user@domain
   mail addresses are not broken up into their user and domain
   constituent parts, nor is user+foo broken up into user and foo.

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

[pfx] Re: masquerade_domains does not work for relayed domain

[Viktor Dukhovni via Postfix-users]

On Mon, Feb 12, 2024 at 04:28:41PM +0100, Aleksandar Ivanisevic via 
Postfix-users wrote:
> 
> Is it true that masquerade_domains does not work for header From: in relayed 
> emails? I have a fairly generic setup:
> 
> masquerade_classes = envelope_sender, header_sender, header_recipient
> masquerade_domains = mydomain.com
> 
> that does indeed rewrite envelope from, but not header from, and subsequently 
> DKIM signer (opendkim) in my relay does not match and does not sign the email.
> 
> if this is true, how do i properly masquerade header from in relayed emails?
> 
> header_checks? Does not seem to have regexp groups replace so
> 
> /From: (.*)@.*?mydomain.com/  REPLACE From: 
> $1...@mydomain.com 
> 
> does not seem to work and it does not really cover all cases like From: “some 
> name “ , etc.

Add the outbound relay domain mail clients (those whose mail should be
DKIM signed, rather than verified) to:

https://www.postfix.org/postconf.5.html#local_header_rewrite_clients

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

[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive

[Viktor Dukhovni via Postfix-users]

On Sun, Feb 11, 2024 at 07:42:24PM -0600, Jakob Cornell via Postfix-users wrote:

> smtpd_recipient_restrictions =
>   check_sender_access regexp:/etc/postfix/db/sender_access_table
>   ...

As documented regexp, pcre, ... tables don't do "partial key" lookups.
This is deliberate and correct behaviour.

> /^jcornell\.net$/ reject_sender_login_mismatch, permit

This is just the domain part of an address, and would match in an
indexed file or similar table, not in a regexp, pcre, ... table.


> This works fine for ja...@jcornell.net, but my ultimate goal is to
> configure delivery for *.m.acorn.ignorelist.com too (arbitrary
> subdomain),

See access(5).  In indexed files, domains by default also match
their sub-domains, but see:

https://www.postfix.org/postconf.5.html#parent_domain_matches_subdomains

and preferably set it empty and then list:

access:
blocked.example REJECT
.blocked.exampleREJECT

> Could this be a bug in regexp table lookup?

Works as intended.

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

[pfx] Re: How to forward submitted mails under the identity of an email alias to all other members of that alias?

[Viktor Dukhovni via Postfix-users]

On Sun, Feb 11, 2024 at 10:59:37AM +0100, Matthias Nagel via Postfix-users 
wrote:

> How do I forward submitted mails under the identity of an email alias
> to all other members of that alias? Is that even possible with Postfix
> only?

Yes, with sender_bcc_maps, and with the proviso that the BCC will be to
all the members of that "alias", rather than just "the other members".

> I found the configuration parameter sender_bcc_maps. At first glance,
> that looked promising, however it neither supports mail aliases nor
> more than one address.

Bcc the alias to itself.  While you can't specify multiple addresses
*directly*, the specified address *is* subject to alias expansion.

> Just for the sake of clarity, I give a simplified example with only
> two mail accounts to illustrate what I want to achieve. Lets assume
> there are the virtual mail accounts `jane@my-domain.tld` and
> `john@my-domain.tld` as well as the alias `d...@my-domain.tld`
> which resolves to both mail accounts:

main.cf:
virtual_alias_maps = inline:{
{ doe@bcc.example = john.doe@bcc.example, jane.doe@bcc.example }
}

sender_bcc_maps = inline:{
{ doe@bcc.example = doe@bcc.example }
}

Replace the inline tables with equivalent tables of your choice,
holding all the desired aliases and bcc mappings.

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

[pfx] Re: Understanding log entries

[Viktor Dukhovni via Postfix-users]

On Sun, Feb 11, 2024 at 07:13:38PM +1300, Peter via Postfix-users wrote:

> Right, and further to that a 554 response at connection time is a rejection
> of the *connection*.  No attempt was ever made to send the *message*, so in
> a manner of speaking the message is still valid and a different connection
> might accept it (e.g. by attempting a different MX).  An MTA that wants to
> reject the message should should wait until after the RCPT TO command to
> reject the actual message.

Rejection is equally valid after "MAIL FROM", since that the start of
the "mail transaction".  The receiving system then can't log which
recipients did not get the message, but perhaps that's OK in some cases.

Bottom line the message can be rejected by rejecting:

- MAIL FROM
- RCPT TO (for each recipient)
- DATA
- END OF DATA (a.k.a. "dot").

With BDAT one can reject all the chunks after some first chunk that is
sufficient grounds to do that.  Because of PIPELINING, one needs to be
willing to receive and reject some subsequent chunks.

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

[pfx] Re: Alias forwarding request

[Viktor Dukhovni via Postfix-users]

On Thu, Feb 08, 2024 at 07:08:35PM +0100, Maurizio Caloro via Postfix-users 
wrote:

> To forwarding alias to emailaddress, mysql are setuped followed:
> 
> Files :
> 
> * /etc/folder/mysql-virtual_alias_maps.cf
> * /etc/folder/mysql-virtual_mailbox_domains.cf
> * /etc/folder/mysql-virtual_mailbox_maps.cf

For meaningful help, post configuration details and relevant logs:

* https://www.postfix.org/DEBUG_README.html#mail

- postconf -nf output
- postconf -Mf output
- logs of a few specific deliveries that are doing and/or not
  doing what you want.

> query = SELECT domain FROM domain WHERE domain='%s' and backupmx='0' and 
> active='1'

Are you sure that "0" and "1" should be quoted strings?  Perhaps in your
actual schema they are numbers?

With a language barrier, and a rambling post that does not appear to ask
a specific question, you're not making it possible for anyone to give an
actionable response.

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

[pfx] Re: Server etiquette

[Viktor Dukhovni via Postfix-users]

On Wed, Feb 07, 2024 at 11:21:10AM -0500, John Hill via Postfix-users wrote:

> I use fail2ban as well. I'm just going to see if the sender sever will give
> up!

I prefer to have logs that record what I'm blocking.  With firewall
rules there's not sufficient forensic evidence left behind.

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

[pfx] Re: Server etiquette

[Viktor Dukhovni via Postfix-users]

On Wed, Feb 07, 2024 at 07:59:44AM -0500, John Hill via Postfix-users wrote:

> Do mail servers as a whole stop sending an email after a few errors?

For a single message, surer

On soft errors (4XX), most retry, typically stopping after a maximal
delay.  The retry strategy varies, but 4,000 retries in one day is
atypical, since that averages out to retrying approximately every 20
seconds, without backoff.

Sendmail, and IIRC Exim, retry at fixed intervals, with IIRC 30minutes
being somewhat popular.  Postfix performs exponential backoff from an
initial (default 300s) minimal backoff time to a (default 4000s) maximum
backoff time.

> I have a server I have blocked in my firewall. It continues to try and is
> blocked as many as 4000+ times a day.

If you drop packets from a system that has multiple messages to send,
then none of the messages will be rejected outright, and they'll all
queue up.  Once there are enough messages queued, you can easily see
thousands of TCP SYN attempts a day because:

- Even a single application-level connection attempt will send
  multiple TCP SYNs until the connection times out.

- Each message will be retried periodically.

- Meanwhile more messages can arrive, or be already queued.

> If postscreen was set to deny it, would that signal the server and limit the
> attempts?

With a legitimate MTA, SMTP-layer reject would indeed be more effective.
(But then perhaps you should not be rejecting the mail???).

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

[pfx] Re: One user unable to send email

[Viktor Dukhovni via Postfix-users]

On Tue, Feb 06, 2024 at 10:27:17PM -0500, Ken Wright via Postfix-users wrote:

> I honestly don't know if this is an issue with Postfix or Roundcube,
> but I thought I'd start here.
> 
> I'm running Postfix 3.8.1 on Ubuntu Server 23.10 and I'm hosting a
> friend's website and email in addition to my own.  My problem is, my
> friend (who usually accesses her email on her phone via Roundcube) is
> unable to send email, getting a 451 error when she tries.  She can
> receive emails without difficulty.  I am able to send and receive
> emails, both through a conventional mail client (Evolution) and the
> Roundcube webmail interface.  I know there are ways to throttle
> Postfix, but I can't find them in either main.cf or master.cf.  Can
> anyone offer any insights?

Curious anecdote (je suis désolé), but if you're looking for help, and
not sympathy:

http://www.postfix.org/DEBUG_README.html#mail

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

[pfx] Re: why tls library problem?

[Viktor Dukhovni via Postfix-users]

On Tue, Feb 06, 2024 at 06:50:28PM +0100, Maurizio Caloro via Postfix-users 
wrote:

> Feb6 time P postfix/tlsproxy[300980]: warning: TLS library problem:
>   error:1417A0C1:SSL routines:tls_post_process_client_hello:
>   no shared cipher:../ssl/statem/statem_srvr.c:2283:

This looks like a client connection to your server, that was mediated by
tlsproxy(8) on behalf of postscreen(8).   The remote client's TLS client
hello message did not list any ciphers that are enabled in your
configuation and supported by your server's underlying OpenSSL library.

If the client were on the postscreen whitelist, the connection would
have been immediately handed off to smtpd(8), well before STARTTLS.
Therefore, this was either a blacklisted client, or else a "new" client,
whose IP address has either expired from the cache or has never before
connected.

It could also, for example, be one of the security scanners (shodan,
...) that specifically tests deprecated ciphers.

That said, you've provided no information about your configuration:

https://www.postfix.org/DEBUG_README.html#mail

so more specific advice is not possible.

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

[pfx] Re: Forward mails if user unknown in local recipient table

[Viktor Dukhovni via Postfix-users]

On Tue, Feb 06, 2024 at 10:31:06PM +0530, Akshay Pushparaj via Postfix-users 
wrote:

> I would like to know if i can configure postfix to forward mails if user not
> found in local recipient table.

That's not the right question.  The right question is:

- How to deliver some users for a domain locally and and some to a
  remote server?

For that, I'd typically configure the domain as a relay domain, and
*rewrite* the addresses that should be delivered locally to a local
or virtual mailbox (mydestination or virtual_mailbox_domains) domain.

My actual preference is to make such domains be virtual alias domains,
and rewrite both the forwarded and the local recipients to internal
domains, with some forwarded and some delivered locally.  But that's
a bit more complicated when the relay destination expects unmodified
envelope recipients.  It may be possible to give the relay recipients
*additional* internal addresses and rewrite to that form...

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

[pfx] Re: postscreen segfault since 3.8.4

[Viktor Dukhovni via Postfix-users]

On Sun, Feb 04, 2024 at 08:12:56PM -0500, Christophe Kalt via Postfix-users 
wrote:

> These are the alpine packages themselves, but I'm not familiar with how
> they're built so I can't rule out a bad build. It's also possible that I
> didn't let the 3.8.3 version run long enough for it to crash as it happens
> irregularly.
> 
> Anyways, spent some time building 3.8.5 from source and am now waiting to
> see if it happens with that build.

Whether with your own build, or the distro, if you enable core dumps
from setuid programs (really most programs that change/drop privs),
you may be able to obtain a backtrace, ideally from a build with
debugging symbols.

If this were easy to reproduce, I ask for a verbose log, but that's
not practical when looking for a rare event (if these are rare).

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

[pfx] Re: postscreen segfault since 3.8.4

[Viktor Dukhovni via Postfix-users]

On Sun, Feb 04, 2024 at 05:06:22PM -0500, Viktor Dukhovni via Postfix-users 
wrote:

> > - 3.8.4 on alpine 3.19.0
> > - 3.8.5 on alpine 3.19.1
> > 
> > but apparently not for 3.8.3 on alpine 3.18.3
> 
> There's perhaps an issue in the OpenSSL or other library dependencies.
> For further info we'd need a coredump and backtrace, as well as ldd
> output for the executable, and list of mapped objects from the core
> file.

Scratch that, TLS (and so use of the OpenSSL library) is handled by
tlsproxy(8) not postscreen(8).

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

[pfx] Re: postscreen segfault since 3.8.4

[Viktor Dukhovni via Postfix-users]

On Sun, Feb 04, 2024 at 01:37:18PM -0500, Christophe Kalt via Postfix-users 
wrote:

> /usr/libexec/postfix/postscreen pid 93 killed by signal 11
> 
> These connections are from an SMTP probe that goes EHLO STARTTLS EHLO QUIT
> 
> I've not run postscreen previously, so I cannot tell whether this is new,
> but some testing shows it happens for the following versions:
> 
> - 3.8.4 on alpine 3.19.0
> - 3.8.5 on alpine 3.19.1
> 
> but apparently not for 3.8.3 on alpine 3.18.3

There's perhaps an issue in the OpenSSL or other library dependencies.
For further info we'd need a coredump and backtrace, as well as ldd
output for the executable, and list of mapped objects from the core
file.

How is Postfix built on these systems?

On Sun, Feb 04, 2024 at 04:44:23PM -0500, Wietse Venema via Postfix-users wrote:
> 
> postcreen source code has not changed since postfix-3.8.0:
> 
> $ diff -ur postfix-3.8.0/src/postscreen postfix-3.8.5/src/postscreen
> [no output]
> 
> The SMTP smuggling changes are in code that is not used in postscreen.
> postscreen has a different SMTP engine implementation.
> 
> I therefore suspect a bad build, or bad library dependency.

Ditto.

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

[pfx] Re: Adjusting smtpd_recipient_restrictions

[Viktor Dukhovni via Postfix-users]

On Sun, Feb 04, 2024 at 01:22:45PM +0200, Mark via Postfix-users wrote:

> Is it better to list reject_unauth_destination after;
> 
> permit_mynetworks,
> permit_sasl_authenticated,
> 
> Or before these? And why?

Best practice is to require submission users sending outbound mail do so
via ports 465 and/or 587.  If also the MTA instance in question is *not*
a "smarthost" outbound relay for some set of "internal" machines
authorised by IP address, then you simply don't need either of:

permit_mynetworks,
permit_sasl_authenticated

instead, the simplest setting of "smtpd_relay_restrictions" can be

smtpd_relay_restrictions = reject_unauth_destination

If however some "trusted IP" clients or some "authenticated" users are
using port 25 to send outbound mail, then you need to add either or both
of:

permit_mynetworks,
permit_sasl_authenticated

*before* rejecting mail for external domains.

> And finally, here are my helo and sender restrictions;
> 
> smtpd_helo_restrictions =
>   permit_mynetworks,
>   permit_sasl_authenticated,
>   reject_invalid_helo_hostname,
>   reject_non_fqdn_helo_hostname,
>   permit
> 
> smtpd_sender_restrictions =
>   reject_non_fqdn_sender,
>   reject_unlisted_sender,
>   permit_mynetworks,
>   permit_sasl_authenticated,
>   reject_unknown_sender_domain,
>   permit
> 
> You might wish to give your opinions on these above as well?

Whatever works for you, so long as you understand what these do,
and these meet your goals.  The main thing is to configure
separate rules for port 25 and (via master.cf overrides) for
submission on port 465 and 587.  I have:

submission inet  n   -   n   -   -   smtpd
-o syslog_name=postfix/submission
-o smtpd_sasl_auth_enable=yes
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_dh1024_param_file=${config_directory}/dh2048.pem
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
-o smtpd_recipient_restrictions=
-o smtpd_data_restrictions=
-o smtpd_end_of_data_restrictions=
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_milters=$mua_milters
-o always_add_missing_headers=yes
-o header_checks=$submit_header_checks
-o body_checks=

> I'm trying to be as restrictive as possible, against haux
> hostnames/helo attempts, spammers and attackers.

Best to go with: as restrictive as reasonably practical.  Some junk will
get through, that's OK, provided it does not drown users in in a torrent
of spam, dominating legitimate mail.

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