[pfx] Re: Adjusting smtpd_recipient_restrictions

[Viktor Dukhovni via Postfix-users]

On Fri, Feb 02, 2024 at 08:26:20AM +0300, Mark via Postfix-users wrote:

> I'm trying to adjust my smtpd_recipient_restrictions so that any emails
> coming to a non-existent account on my server would be rejected BEFORE the
> attempt reaches RBLs/RBL queries.

If you're using Postfix 3.6 or later, you probably have a "yes" setting
for:

smtpd_relay_before_recipient_restrictions = ${{$compatibility_level}  Thus, before I activate my settings, I wanted to ask for your opinions, so
> here how it goes;
> 
> smtpd_recipient_restrictions =
>   reject_non_fqdn_sender,
>   reject_non_fqdn_recipient,
>   reject_non_fqdn_helo_hostname,
>   reject_invalid_helo_hostname,
>   reject_unlisted_recipient,
>   permit_mynetworks,
>   permit_sasl_authenticated,
>   reject_unauth_destination,
>   reject_rbl_client zen.spamhaus.org=127.0.0.[2..11],
...

This looks fine.

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

[pfx] Re: milter: how about a SMFIP_NOQUIT?

[Viktor Dukhovni via Postfix-users]

On Wed, Jan 31, 2024 at 12:13:51PM -0500, Wietse Venema via Postfix-users wrote:

> - The MTA then needs to keep the Milter connection open while watting
> for new work. Once there is work, the MTA sends SMFIC_CONNECT and
> so on.
> 
> - This sounds like the MTA needs a Milter connection cache that
> keeps a connection open for up to $max_idle seconds, because it
> seems to make no sense to cache such state inside individual smtpd
> (or cleanup) processes.

I am not convinced that a shared cache makes sense.  All mail passing
through a given process is subjected to milter inspection, and a milter
session lasts for the entire mail transaction, which on my system
averages to O(100ms), vs.  typical table lookup latency of O(1ms).  I'd
be inclined to cache milter connections in-process.

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

[pfx] Re: Are multiple white spaces allowed in a date in headers?

[Viktor Dukhovni via Postfix-users]

On Wed, Jan 31, 2024 at 01:00:56PM +0100, Michael Storz via Postfix-users wrote:

> day =   ([FWS] 1*2DIGIT FWS) / obs-day
> 
> This says a day can consist of one or two digits preceded by an optional
> folding white space (FWS):
> 
> FWS =   ([*WSP CRLF] 1*WSP) /  obs-FWS
> 
> A FWS can be a single WSP or a folded line.

No, 1*element, means one *or more* instances of the element.

   https://datatracker.ietf.org/doc/html/rfc5234#section-3.6

   The operator "*" preceding an element indicates repetition.  The full
   form is:

 *element

   where  and  are optional decimal values, indicating at least
and at most  occurrences of the element.

   Default values are 0 and infinity so that * allows any
   number, including zero; 1* requires at least one;
   3*3 allows exactly 3; and 1*2 allows one or two.

> Therefore the date "Fri,  5 Jan 2024 16:48:37 -0500 (EST)" is syntactically
> incorrect,

No, it is therefore syntactically correct.  And the day can be specified
with either 1 or digits, so is neither invalid nor obsolete.

https://datatracker.ietf.org/doc/html/rfc5322#section-3.3

day =   ([FWS] 1*2DIGIT FWS) / obs-day

What's obsolete is insertion of comments around elements of the date.

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

[pfx] Re: problem to add, alias failed

[Viktor Dukhovni via Postfix-users]

On Tue, Jan 30, 2024 at 07:57:18PM +0100, Maurizio Caloro via Postfix-users 
wrote:

> if adding a new user with postfixadmin 3.3.8 or with cli this will run
> without problem.
> 
> GRANT ALL PRIVILEGES ON mailserver.* TO markus@'domain.com
>  ' IDENTIFIED BY
> '***';

That SQL syntax is for adding a database *administrator* account, not
for adding an email mailbox or alias...  Why are you attempting to
give the user database access privileges?

> postfix/lmtp[102470]: 3E101208A1: to= 
> mar...@domain.com, relay=mail.domain.com[private/dovecot-lmtp],
> delay=0.12, delays=0.06/0.01/0.02/0.02, dsn=5.1.1, status=bounced (host
> mail.domain.com[private/dovecot-lmtp]
> said: 550 5.1.1 mar...@domain.com   User doesn't
> exist: mar...@domain.com   (in reply to RCPT TO
> command))

Postfix is not the responsible party here, just the messenger.  It is
dovecot LMTP that is rejecting the user, and you should seek help
primarily on the Dovecot list.

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

[pfx] Re: different queue time based on the sender address

[Viktor Dukhovni via Postfix-users]

On Sat, Jan 27, 2024 at 12:01:55PM +0100, Aleksandar Ivanisevic via 
Postfix-users wrote:

> in main.cf
> sender_dependent_default_transport_maps = hash:/etc/postfix/relay_by_sender
> 
> in /etc/postfix/relay_by_sender
> mysender.com smtp:[localhost]:588

The listening SMTP service for that port would have to be part of a
different Postfix "instance":

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

> in master cf
> 588   inet n   -   n   -   -   smtpd -o 
> maximal_queue_lifetime=1d -o sender_dependent_default_transport_maps=

With the parameters in question set in the main.cf file of that
instance.  You can only override parameters that are documented
as relevant to the service (smtpd(8)) in question, and even then
only to the extent that they're exclusively used by that service,
otherwise (as with e.g. virtual_alias_maps, used in both smtpd(8)
for recipient validation, and cleanup(8) for address rewriting)
you may not get the results you expected.

See the smtpd(8) manpage for the list of parameters known to smtpd(8),
and qmgr(8) and trivial-rewrite(8) for the parameters that are
"queue-wide", and can only be set per-Postfix-instance, rather than
per-SMTP-service.

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

[pfx] Re: Log/Capture outbound messages?

[Viktor Dukhovni via Postfix-users]

On Fri, Jan 26, 2024 at 07:51:31PM -0500, Wietse Venema via Postfix-users wrote:
> joe a via Postfix-users:
> > Postfix  3.5.9-5.9.2
> > 
> > Perhaps not a postfix question at all.  Looking for a way to capture 
> > outbound email, for troubleshooting purposes.
> > 
> > Is "smtp-sink" the way to do this?
> 
> That could be, if you are interested in outbund SMTP deliveries.
> smtp-sink has a crude option to save messages to file.
> 
> If you want to save am "extra" copy for investigation, consider
> using always_bcc, sender_bcc_maps or recipient_bcc_maps.

Or just deliver the messages to a maildir.  The OP rather failed to
specify clearly what "capture" or "outbound mail" meant.

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

[pfx] Re: ldap + 550 5.1.1

[Viktor Dukhovni via Postfix-users]

On Fri, Jan 26, 2024 at 03:41:10PM +0100, Karsten Schmid via Postfix-users 
wrote:

> So how would an appropriate entry in virtual_alias_maps look like?

https://www.postfix.org/ldap_table.5.html

> root@creampuff [/etc/postfix/ldap] # postfix reload
> /usr/sbin/postconf: fatal: /etc/postfix/ldap/virtual-alias-maps.cf, line
> 1: missing '=' after attribute name: "root?fed...@example.net"

line isn't of the form:

attribute = value

for one of the documented ldap table attributes:

domain = ...
server_host = ...
server_port = ...
search_base = ...
query_filter = ...


> root@creampuff [/etc/postfix/ldap] # postfix reload
> /usr/sbin/postconf: warning:
> ldap:/etc/postfix/ldap/virtual-alias-maps.cf: unused parameter:
> root=fed...@example.net

Random fuzzing of the file will not give good results.  Do read the
docs.

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

[pfx] Re: [postfix] 3.4.23: virtual, pipe and ${original_recipient} vs. ${recipient}

[Viktor Dukhovni via Postfix-users]

On Thu, Jan 25, 2024 at 04:48:39PM -0500, Bill Cole via Postfix-users wrote:

> > - Are you expected exactly one recipient per-invocation of the
> >   spamassassin filter?  I'm not sure how spamc handles multiple
> >   recipients after "-u".
> 
> It doesn't. The argument to '-u' is a key to identify a user-specific
> ruleset. The spamc too (and SA generally) has no mechanism to split
> envelopes or to provide multiple responses to a single submission.

In that case, the OP should probably have specified a recipient limit of
1 for the transport... as well as used "--" after "-f ${sender}".

Though pipe(8) manpage does not explicitly say so, it is possible to
handle repeatable options that take a recipient address provided the
option supports a syntax that does not use whitespace:

-u{$recipient}

or 

--user=${recipient}

will each be repeated as many times as there are recipients:

command -u -u ...
command --user= --user= ...

which is useful for commands that can correctly handle multiple
recipients via one option per-recipient.  More typical is to
use argv positional arguments for the envelope recipients, with
resubmission via "sendmail" handled transparently internally.

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

[pfx] Re: Different rules for submission(s)

[Viktor Dukhovni via Postfix-users]

On Thu, Jan 25, 2024 at 09:13:22PM +0100, Paul van der Vlis via Postfix-users 
wrote:

> Op 25-01-2024 om 20:40 schreef Viktor Dukhovni via Postfix-users:
> > On Thu, Jan 25, 2024 at 08:31:44PM +0100, Paul van der Vlis via 
> > Postfix-users wrote:
> > > Hello,
> > > 
> > > Since over 20 years I use Postfix, but some things I don't understand...
> > > 
> > > I want different rules for mail what comes through submission(s) and what
> > > comes from other mailservers using port 25. What is the correct way to do
> > > that?
> > 
> > > From the stock master.cf file (see also the master(5) manpage and/or
> > <https://www.postfix.org/master.5.html>):
> > 
> >  # Choose one: enable submission for loopback clients only, or for any 
> > client.
> >  #127.0.0.1:submission inet n -   n   -   -   smtpd
> >  #submission inet n   -   n   -   -   smtpd
> 
> Normally I've removed the # before submission.

Naturally, the stock file contains *commented-out templates* that you
uncomment, and tune to your needs.  Each "-o foo=bar", or, lately "-o {
foo = bar }", option *overrides* the corresponding main.cf or default
settings.

> >  # here, and specify mua__restrictions in main.cf (where
> >  # "" is "client", "helo", "sender", "relay", or "recipient").
> >  #  -o smtpd_client_restrictions=
> >  #  -o smtpd_helo_restrictions=
> >  #  -o smtpd_sender_restrictions=
> >  #  -o smtpd_relay_restrictions=
> >  #  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
> >  #  -o milter_macro_daemon_name=ORIGINATING
> 
> I understand what you mean. But what is after this?

Any other parameters that smtpd(8) supports, which for the particular
service (submission, etc.) you want to have a setting that is different
than what's in main.cf or the default.

> Are then the lines in main.cf used, like smtpd_relay_restrictions or
> smtpd_milters?

Anything you don't override gets the main.cf or built-in default value.

> And where is the point that the mail is accepted?

These are not smtpd access restrictions, these are parameter overrides,
so there is no "point that the mail is accepted".

> > I have, for example:
> > 
> >  submission inet  n   -   n   -   -   smtpd
> >  -o smtpd_milters=
> >  -o smtpd_sasl_auth_enable=yes
> >  ...
> 
> This is interesting for me, I would expect such lines here. But in the
> examples they are not there.  And maybe end with "-o permit" ?

No, because these are parameter overrides, not restriction lists.  You
clearly haven't yet read the master(5) manpage.  Please do so next.

> > Welcome to master.cf overrides, congratulations on managing to get by
> > without them for 20 years.
> 
> ;-)
> 
> And what about lines for port 25. Better to put them in master.cf?

No, put as little in master.cf as possible/necessary, only to the extent
that different services need different values of the same parameter.

> What's left for main.cf then?  Only the mail from localhost?

Again, these are not access controls.  The main.cf file lists the
non-default site-specific values of most parameters that don't need
per-service overrides, and even for these one of the services can
use the main.cf (or default) values with overrides only for the
special cases.

> Or is "smtpd_relay_restrictions =" not used for incoming mail from
> submission(s)?

It is, which is why you might want to override it in master.cf. I have:

$ postconf -Mf submission/inet
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 smtpd_tls_ask_ccert=yes
-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=

The "mua_milters" custom parameter is defined in main.cf, and specifies
just the DKIM signing milter, without any of the milters intended for
inbound mail.

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

[pfx] Re: Different rules for submission(s)

[Viktor Dukhovni via Postfix-users]

On Thu, Jan 25, 2024 at 08:31:44PM +0100, Paul van der Vlis via Postfix-users 
wrote:
> Hello,
> 
> Since over 20 years I use Postfix, but some things I don't understand...
> 
> I want different rules for mail what comes through submission(s) and what
> comes from other mailservers using port 25. What is the correct way to do
> that?

>From the stock master.cf file (see also the master(5) manpage and/or
):

# Choose one: enable submission for loopback clients only, or for any 
client.
#127.0.0.1:submission inet n -   n   -   -   smtpd
#submission inet n   -   n   -   -   smtpd
#  -o syslog_name=postfix/submission
#  -o smtpd_tls_security_level=encrypt
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_tls_auth_only=yes
#  -o local_header_rewrite_clients=static:all
#  -o smtpd_reject_unlisted_recipient=no
# Instead of specifying complex smtpd__restrictions here,
# specify "smtpd__restrictions=$mua__restrictions"
# here, and specify mua__restrictions in main.cf (where
# "" is "client", "helo", "sender", "relay", or "recipient").
#  -o smtpd_client_restrictions=
#  -o smtpd_helo_restrictions=
#  -o smtpd_sender_restrictions=
#  -o smtpd_relay_restrictions=
#  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
# Choose one: enable submissions for loopback clients only, or for any 
client.
#127.0.0.1:submissions inet n  -   n   -   -   smtpd
#submissions inet  n   -   n   -   -   smtpd
#  -o syslog_name=postfix/submissions
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o local_header_rewrite_clients=static:all
#  -o smtpd_reject_unlisted_recipient=no
# Instead of specifying complex smtpd__restrictions here,
# specify "smtpd__restrictions=$mua__restrictions"
# here, and specify mua__restrictions in main.cf (where
# "" is "client", "helo", "sender", "relay", or "recipient").
#  -o smtpd_client_restrictions=
#  -o smtpd_helo_restrictions=
#  -o smtpd_sender_restrictions=
#  -o smtpd_relay_restrictions=
#  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

> E.g. I don't want a check on blacklists on the submission ports.
> And I don't want authentication on port 25.
> 
> And what about milters, how can I configure them so that they are only used
> for e.g. SMTP on port 25?

I have, for example:

submission inet  n   -   n   -   -   smtpd
-o smtpd_milters=
-o smtpd_sasl_auth_enable=yes
...

with a non-empty set of milters (default, so simply ommitted
smtpd_sasl_auth_enable=no) in main.cf

Welcome to master.cf overrides, congratulations on managing to get by
without them for 20 years.

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

[pfx] Re: [postfix] 3.4.23: virtual, pipe and ${original_recipient} vs. ${recipient}

[Viktor Dukhovni via Postfix-users]

On Thu, Jan 25, 2024 at 12:04:38PM +, hawky--- via Postfix-users wrote:

> we're in the process to integrate SpamAssassin in our mail system. We
> decided to use the after-queue attempt with
> 
> > smtpd -o content_filter=

> The problem we're facing right now is that pipe is getting the alias
> name as recipient instead of the username - both are the same:

You probably have "receive_override_options = no_address_mappings" or
similar configured in the before-queue smtpd.

> mydestination = hexa, localhost.localdomain, localhost $myhostname
> 
> --master.cf--
> 192.168.73.200:25 inet n -   y   -   -   smtpd -v
> -o content_filter=spamassassin
> -o receive_override_options=no_address_mappings

There you are.

> pickup unix  n   -   y   60  1   pickup
> spamassassin unix - n   n   -   -   pipe -v
>   user=debian-spamd argv=/usr/bin/spamc -u ${recipient} -f -e 
> /usr/sbin/sendmail -oi -f ${sender} ${recipient}

For efficiency, most users use the "advanced" SMTP-based content filter,
rather than the "simple" pipe-based filter.

- Are you expected exactly one recipient per-invocation of the
  spamassassin filter?  I'm not sure how spamc handles multiple
  recipients after "-u".

- You're missing the "--" before ${recipient}, relying only on
  "allow_min_user = no" to protect the sendmail(1) command-line
  from option argument injection.

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

[pfx] Re: Feature Request: Adjustable Header Log Size Limit in INFO/WARN/REJECT Header_Check

[Viktor Dukhovni via Postfix-users]

On Wed, Jan 24, 2024 at 08:27:53PM +0100, Matthias Schneider via Postfix-users 
wrote:

> Using a Milter is an option, but it often involves correlating
> information from both the milter process and the log for a
> comprehensive view.

Everything of interest can be added as a message header.

> For example, capturing TLS details from both the smtp client process
> and smtpd pid, along with recipient information and specific Headers
> is crucial.

You can PREPEND the TLS details for inspection by a milter.  Why is this
"crucial"?  Postfix SMTP server TLS logging is fairly terse.  Other than
that TLS was used, what is so crucial to correlate with message headers?

> As far as I know, there are currently no other supported protocols for
> event streaming. Therefore, relying on syslog (nearly real-time) or
> reading logs from a file (with some delay) remains the most effective
> solution for obtaining delivery information.

A milter can stream its findings to some central collection point using
any protocol of its choice, including syslog.

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

[pfx] Re: Documentation on upgrade 2.10 to 3.5

[Viktor Dukhovni via Postfix-users]

On Wed, Jan 24, 2024 at 11:17:16AM -0500, Viktor Dukhovni via Postfix-users 
wrote:

> > > 2) The leapp output mentions a compatibility option.  I think I need to
> > > use that.  Is there documentation on it?
> 
> https://www.postfix.org/postconf.5.html#compatibility_level
> https://www.postfix.org/COMPATIBILITY_README.html

The native compatibility level for Postfix 3.0 through 3.5 is "2".  But
the parameter defaults to "0".  You need to explicitly set it to "2",
once you've either accepted the new defaults, or chosen explicit
overrides.

main.cf:
compatibility_level = 2
# Set non-default values for any of the below, only as-needed.
# append_dot_mydomain = ???
# mynetworks_style = ???
# smtpd_relay_restrictions = ???
# relay_domains = ???
# ?smtputf8_enable = ???

In Postfix 3.6 the syntax changed and it became "3.6", which is still
the level in the latest 3.9 snapshots.  There are very few parameters
whose defaults changed incompatibly.  The current list is:

append_dot_mydomain = ${{$compatibility_level} 

[pfx] Re: Documentation on upgrade 2.10 to 3.5

[Viktor Dukhovni via Postfix-users]

On Wed, Jan 24, 2024 at 09:38:06AM -0600, Bill Gee via Postfix-users wrote:

> > 1) Is there any documentation about moving from Postfix 2 to 3?  I
> > looked on the web site but saw nothing obvious.

The RELEASE NOTES:

https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-2.11
https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-3.0
https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-3.1
https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-3.2
https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-3.3
https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-3.4
https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-3.5

> > 2) The leapp output mentions a compatibility option.  I think I need to
> > use that.  Is there documentation on it?

https://www.postfix.org/postconf.5.html#compatibility_level
https://www.postfix.org/COMPATIBILITY_README.html

> > 3) Would it be useful to set up a test machine (of which I have several)
> > and try the configuration files on it?  I think there is no good way to
> > actually run messages through it, but I can at least see if the Postfix
> > service starts.

Your choice.

> 4) Probably not a PostFix question, but it is related.  One big reason for
> doing an in-place upgrade is because I do not know how to move my mailbox
> from the old server to something new.  Is that just a matter of copying a
> $HOME directory?

What you copy rather depends on where mail is stored.  If you turn off
incoming mail and no user is able to modify their mailbox (delete
messages, ...) then copying the files to corresponding locations on a
new system will work.

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

[pfx] Re: Feature Request: Adjustable Header Log Size Limit in INFO/WARN/REJECT Header_Check

[Viktor Dukhovni via Postfix-users]

On Wed, Jan 24, 2024 at 03:10:03PM +0100, Matthias Schneider via Postfix-users 
wrote:

> Initially, I experimented with a Milter for logging the required
> headers, but I found that employing a larger %s printf value proved to
> be a more efficient solution. However, I'd like to point out that the
> default configuration for MaxMessageSize in rsyslog is often set to
> 8k, with the potential to increase it to 64k when using TCP.
> Therefore, the syslog aspect can handle larger messages effectively.

Why is syslog the right medium for accurate message header recording?
What sort of key/value pairs are you looking to extract from headers?

When ~2 decades ago I implemented header logging (actually MIME-skeleton
logging, that recorded also the header of all nested MIME parts), I
recorded the MIME skeletons of each message (separated by blank lines)
to a daily disk file.  Syslog was not a good vehicle for faithful
recording of message metadata.

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

[pfx] Re: Enabling TLS1.3 and allow sending over SMTPS/465

[Viktor Dukhovni via Postfix-users]

On Mon, Jan 22, 2024 at 02:57:16PM -0500, Bill Cole via Postfix-users wrote:

> The reason implicit TLS isn't useful for SMTP (MTA-MTA) use is that port 25
> must always be backwards-compatible and so MUST start with a plaintext
> server greeting, NOT a TLS handshake. Establishing a new secure port would
> mean either every MTA trying to connect twice to sites that have yet to
> upgrade or we'd have to finally switch to SRV records for SMTPS, forcing
> every MTA to replace its whole DNS logic. Also, the info disclosure of
> MTA-MTA STARTTLS vs implicit TLS is less meaningful than it is for MUA-MTA,
> where it exposes end user info.

Perhaps, some day, someone will specify a SVCB profile for MTA-to-MTA
SMTP, and this could finally carry enough information to signal implicit
TLS on a suitable port.  For now, there is little reason to go there,
STARTTLS is quite adequate for server-to-server SMTP.

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

[pfx] Re: Enabling TLS1.3 and allow sending over SMTPS/465

[Viktor Dukhovni via Postfix-users]

On Mon, Jan 22, 2024 at 11:44:40AM -0300, Taco de Wolff via Postfix-users wrote:

> Two questions really, one is that I can't enable TLS1.3 whatever I try.
> Running CentOS8 with OpenSSL v1.1.1k-FIPS and Postfix v3.5.8, I confirm
> that TLS1.3 ciphers are available:

Protocol version negotiation is up to OpenSSL.  The only non-trivial
fact about the Postfix SMTP server, is that is permissive and sets the
SSL security level to 0 unless you set "smtpd_tls_req_ccert = yes", in
which case security level 1 is used.  I would not expect a permissive
security level to cause TLS 1.3 negotiation to be disabled.  Perhaps
your certificate is somehow not compatible with TLS 1.3.

> # postconf
> smtpd_tls_cert_file = /path/to/crt

Can you share the public certificate?

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

The more up-to-date syntax for that is:

# Note: no whitespace between ">=" and the TLS version!
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_protocols = >=TLSv1.2

> tls_medium_cipherlist =
> TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256: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:DHE-RSA-CHACHA20-POLY1305

Drop the first three elements, TLS 1.3 bulk encryption ciphers are not
the TLS 1.0–2 ciphersuites and have no effect in any of the "cipherlist"
parameters.  Better yet, don't override the list at all...

> smtpd_tls_security_level = encrypt
> smtpd_tls_wrappermode = yes

These should only be set in master.cf, not main.cf

> $ openssl s_client -connect server.hostname:465 -tls1_3
> Connecting to [IPADDRESS]
> CONNECTED(0003)
> 40879BE5F97F:error:0A00042E:SSL routines:ssl3_read_bytes:tlsv1 alert
> protocol version:ssl/record/rec_layer_s3.c:861:SSL alert number 70

This is not possible with OpenSSL 1.1.1 from the upstream openssl.org
source.  It must be part of the crypto-policy patches from RedHat.
Upstream there are no protocol version alerts in rec_layer_s3.c, the
only such alerts in OpenSSL_1_1_1-stable are in:

ssl/record/ssl3_record.c:SSLfatal(s, 
SSL_AD_PROTOCOL_VERSION, SSL_F_SSL3_GET_RECORD,
ssl/record/ssl3_record.c:SSLfatal(s, 
SSL_AD_PROTOCOL_VERSION,
ssl/statem/statem_clnt.c:SSLfatal(s, SSL_AD_PROTOCOL_VERSION, 
SSL_F_TLS_PROCESS_SERVER_HELLO,
ssl/statem/statem_lib.c:SSLfatal(s, SSL_AD_PROTOCOL_VERSION, 
SSL_F_SSL_CHOOSE_CLIENT_VERSION,
ssl/statem/statem_lib.c:SSLfatal(s, SSL_AD_PROTOCOL_VERSION,
ssl/statem/statem_lib.c:SSLfatal(s, SSL_AD_PROTOCOL_VERSION,
ssl/statem/statem_lib.c:SSLfatal(s, SSL_AD_PROTOCOL_VERSION,
ssl/statem/statem_lib.c:SSLfatal(s, SSL_AD_PROTOCOL_VERSION,
ssl/statem/statem_lib.c:SSLfatal(s, SSL_AD_PROTOCOL_VERSION, 
SSL_F_SSL_CHOOSE_CLIENT_VERSION,
ssl/statem/statem_srvr.c:SSLfatal(s, SSL_AD_PROTOCOL_VERSION,
ssl/statem/statem_srvr.c:SSLfatal(s, SSL_AD_PROTOCOL_VERSION,
ssl/statem/statem_srvr.c:SSLfatal(s, 
SSL_AD_PROTOCOL_VERSION,

> Has this something to do with FIPS mode? I don't think so because the
> ciphers show up in OpenSSL. Why is TLS1.3 not getting enabled?

Ask RedHat.

> Second question came up while fixing a blocked outbound port 25 with my
> ISP. I've noticed that mail gets sent to DANE enabled servers, I suppose
> because it uses port 587 using STARTTLS.

You're probably misreading the evidence.  Perhaps the outbound block is
IPv4-specific, and you're getting through on port 25 over IPv6 to
servers that are IPv6-enabled, run by tech-savvy operators, which could
somewhat correlate with DANE support.

> I wonder if postfix allows sending mail over the recommended implicit
> TLS port 465 between mail servers?

Nothing of the sort is either remote correct or implemented.

> ... setting smtp_tls_wrappermode=yes would force using implicit TLS
> (right?),

It would, but then none of the outbound mail would be delivered, since
there are no SMTP servers that do implicit TLS on port 25.

On Mon, Jan 22, 2024 at 12:34:18PM -0300, Taco de Wolff via Postfix-users wrote:

> Sorry, this was a problem with the system-wide cryptographic policies. I
> set it to DEFAULT and it works. This is unexpected though, since at least
> two TLS1.3 ciphersuites are enabled with FIPS:OSPP and TLS1.3 works with
> Nginx (Dovecot is similar to Postfix though and both are fixed with this
> crypto setting).

There may be a specific policy for Nginx.  I build my own Postfix and
OpenSSL from source, so haven't had to fight the crypto-policy excesses.

> Surely, somewhere in how Postfix/Dovecot use OpenSSL is
> getting blocked when using FIPS mode. Is that a bad configuration or a bug
> perhaps?

No, just 

[pfx] Re: Preparation of switch from OpenSMTPd to Postfix -> syntax/behaviuor of virtual_alias_maps

[Viktor Dukhovni via Postfix-users]

On Sun, Jan 21, 2024 at 11:35:39PM +0100, Simon Hoffmann via Postfix-users 
wrote:

> > DO NOT use the deprecated "virtual_domains" parameter, it mixes
> > classification of domains with address mappings.
> 
> I have read that and I thought I understood it.

Simply put, use "virtual_alias_domains" to enumerate any virtual alias
domains, and "virtual_alias_maps".  DO NOT reply on the
backwards-compatible (with Postfix 1.x 20+ years ago) default value of
"virtual_alias_domains":

virtual_alias_domains = $virtual_alias_maps

Instead, set "virtual_alias_domains" explicitly, either empty or a
non-empty list of such domains.

> I have also read http://www.postfix.org/VIRTUAL_README.html and this states 
> that with
> virtual alias mode I can have the same local part in an email address and 
> deliver
> them to different unix users,

You're not reading on its own merit, rather letting your prior
expectations obscure the message.  Try to forget everything you know
about the OpenSMTP virtual table as a model of what virtual mappings do,
all you should carry forward is an understanding of the functionality of
the individual lines that you want to translate in a suitable manner to
Postfix.

The Postfix virtual(5) table is *very* different, and to avoid
confusion, on this list, lets reserve virtual table for the Postfix
version, and your OpenSMTPd configuration file is just some file
with lines that implement various behaviours which you'll want to
match one line at a time...

Note:

0. The virtual(5) mapping applies to ALL envelope recipient addresses,
   regardless of address class.  The domainpart does not need to be
   listed in virtual_alias_domains!

1. The virtual(5) table is a 1-to-many mapping of input rfc822 recipient
   addresses to output *addresses*.  Nothing you put on the RHS of
   the *Postfix* virtual(5) file directly causes deliveryu to some
   file or to a user, or causes a recipient to be rejected...

2. virtual(5) is JUST a one-to-many  address mapping.

3. On the RHS, bare "localpart" addresses with no domain part are
   implicity rewritten to  "localpart@$myorigin"

4. The mapping is recursive!  Each RHS value is again subject to
   virtual(5) rewriting, until there's no match, or an address
   maps to itself (after appening @$myorigin if necessary).

5. Input adresses with a domain part that matches "$myorigin"
   that don't match as-is, are retried with just the localpart
   as a lookup key, but the termination check (self-mapping) is
   based on the full input address.

Sepately, Postfix supports virtual_alias_domains, which cannot hold any
directly deliverable mailboxes, instead, each address in such a domain
must be rewritten to some list of addresses in other domains.

> but i can still use local unix users.

You want to see "unix users" on the RHS of the table, but what's there
are email address localparts, that get an implicit domain when none is
explicitly specified.

> The first method on that page does not allow me to route
> localp...@domain1.com to a different user than localp...@domain2.org

This is wrong.  You can map any address to some list of addresses.
With virtual(5), just write:

us...@domain1.com   us...@domain.org

> (with the exact same localpart) and the third mode on that page does
> not use unix users and their home directory to store mails but just a
> directory structure, which is also not what i want.

With virtual_mailbox_domains you can indeed to deliver to logical users
that aren't tied to system accounts.  You may need to get a copy of the
Postfix book by Patrick Koetter and Ralph Hildebrandt and spend a few
days reading the background topics.

You need to understand local(8) delivery, and virtual(8) delivery or
delivery via an LDA or LMTP to some appropriate mail store.

> > It is best to not use the same terminology for two different things.
> > Instead let go of the old terminology and focus on function.
> 
> The file that maps an email address to a unix user or another email address 
> in OpenSMTPd
> is literally stated in the config with the keyword "virtual".

This is actually a big part of the problem.  You need to let go of the
diea that these serve the same function.  They don't.

> > Actually to simon@$myorigin, which may or may not go to the UNIX user,
> > depending on how that's handled.
> 
> With the information from http://www.postfix.org/VIRTUAL_README.html I 
> understand
> that this line means that this email address is delivered to the unix user on 
> the
> RHS. Why would I need to specify a domain on the RHS if i want the unix user 
> simon to
> get the mail?

No.  It is delivered to wherever that address happens to be routed,
which depends on the transport to which the address is resolved, which
depends on the domainpart's address class or matching data in the
transport(5) table.


> Or is specifying @$myhostname the actual (and only?)  way to tell
> postfix to 

[pfx] Re: Preparation of switch from OpenSMTPd to Postfix -> syntax/behaviuor of virtual_alias_maps

[Viktor Dukhovni via Postfix-users]

On Sun, Jan 21, 2024 at 07:21:26PM +0100, Simon Hoffmann via Postfix-users 
wrote:

> The old virtual_domains file just lists all domains (one per line), and can 
> directly be used in
> virtual_alias_domains.

You're going about this the wrong way, by tryign to translate low-level
artefacts from one system to somewhat related, but different low-level
artefacts in Postfix.  Instead you need to implement a functional at a
higher layer.

Postfix support virtual alias rewriting (for all envelope recipient
addresses), and virtual alias domains (which make rewriting mandatory,
since there are no actual mailbox recipients in the domain, just aliases
to mailboxes in *other* domains).

You need to read and understand:

- ADDRESS_CLASS_README
- ADDRESS_REWRITING_README
- The virtual(5) manpage
- The postconf(5) descriptions of:
* virtual_alias_domains
* virtual_alias_maps

DO NOT use the deprecated "virtual_domains" parameter, it mixes
classification of domains with address mappings.

> However, in my virtual aliases table on OpenSMTPd, I have the following 
> line-types

It is best to not use the same terminology for two different things.
Instead let go of the old terminology and focus on function.

> si...@simonhoffmann.net simon
>
> The first line is obvious. Mail addressed to the email address is delivered 
> to the
> UNIX user.

This is an address mapping, best practice is to also specify a domain on
the RHS, which by default gets qualified with "@$myorigin", but if you
have a specific domain in mind, specify it here.

Actually to simon@$myorigin, which may or may not go to the UNIX user,
depending on how that's handled.

> @list.simonhoffmann.net simon
>
> The second line is also obvious, as this is a catchall for a domain. In 
> Postfix this
> has also the lowest priority so I don't break my current alias file.

Catchalls are best avoided.  If you have a specific list of valid
addresses, best to specify each one.

> simon   simon

> For the third line, the documenation under 
> http://www.postfix.org/virtual.5.html
> specifies

You're looking at the wrong documentation, that line from OpenSMTPD,
what is supposed to achieve?  Then figure out whether it is needed,
and how to get equivalent *functionality* (not syntax) from Postfix.

> So I am not sure if this would work and the third line would be an accepted 
> line or
> if I need to replace this line with a user@domain line for every virtual 
> domain.

What is the "simon" entry supposed to achieve?  How does it augment the
functionality of the first line?

> nore...@simonhoffmann.net   /dev/null
> The fourth line in the old alias file silently discard a mail.

Postfix virtual(5) aliases are (rfc822) address-to-address mappings.
You cannot use "/dev/null" or similar here.  That's a feature of local
aliases(5).  But far better:

valias:
nore...@simonhoffmann.net   noreply@discard.invalid

transport:
discard.invalid discard:silently

master.cf
# Should already have a "discard" transport


> OpenSMTPd allows the right hand site to be either a unix user, a
> different email address or simply a path to a file to which it will
> append the new email.

That's what local aliases do in Postfix, but best to avoid the legacy
Sendmail-compatible local delivery agent as much as possible.  Use it
only for outbound delivery to mailing lists, where "owner-alias" and
":include:/member-file", ... are useful features.

For address-to-address rewriting use virtual(5).

> Thus /dev/null on the right hand site would mark the email as
> successfully received to the sending server, but then discards the
> mail internally. Is this possible with postfix as well?

See above.

> s...@simonhoffmann.net  error:550 no spam here!
>
> Lastly, the fifth line bounces the email with the given error code and
> the given message. I have used this to disable specific address on an
> otherwise catch all domain. The spam example above is only an example,
> I have used this for address that were previously used but are not any
> longer and I would like the sender to know that this address is no
> longer in use. Is something like this possible as well?

This goes in the transport(5) file, better as:

s...@simonhoffmann.net  error:5.1.1 Mailbox unavailable

and/or an access(5) table with "check_recipient_access":

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

rcpt-access:
s...@simonhoffmann.net  REJECT 5.1.1 Mailbox unavailable

> And then I have read the following in the documentation:
> 
> /etc/postfix/virtual:
>virtual-alias.domainanything (right-hand content 

[pfx] Re: Preparation of switch from OpenSMTPd to Postfix -> behaviour of smtpd_sender_login_maps pattern matching

[Viktor Dukhovni via Postfix-users]

On Sun, Jan 21, 2024 at 06:53:58PM +0100, Simon Hoffmann via Postfix-users 
wrote:

> > This copies only the message headers and body, but fails to capture the
> > message envelope, which contains the true recipient list.  With
> > per-recipient addressing in "recipient_bcc_maps", and provided the
> > archive system captures the message envelope, you don't lose that (IMHO
> > essential) information.
> > 
> > MAIL FROM:
> > RCPT TO:
> > RCPT TO:
> > DATA
> > From:
> > To: 
> > Subject: Let's commit fraud
> > 
> > ...
> > .
> > 
> > With "always_bcc" one might assume that the message went to
> > "fake-recipient", where in real-life it was sent to "bcc1" and "bcc2".
> > With per-recipient bcc addresses that are captured by the archive,
> > this is not the case.
> 
> MailStore only states the "always_bcc" approach in their manual
> https://help.mailstore.com/en/server/index.php?title=Archiving_Emails_from_Linux-based_Email_Servers#Archiving_Incoming_and_Outgoing_Emails_Directly

That's a nuisance to overcome... :-(

> AFAIK, Mailstore only support this "basic mode" where it uses the header 
> information
> when importing from generic servers or the specific Exchange/Office365 
> Journaling
> format. 
> 
> Additionally, I have only a single destination email address available
> to import into the archive, as each email address specifies which
> (customer) archive this mail should be imported as this is a multi
> tenant software.  With your approach, I would need a catchall at the
> archive software if I understand correctly.

You'll need to deliver to a proxy delivery agent that converts the BCC
recipient addresses to suitable headers, and then reinjects the modified
message for delivery to just the single archive address.

> We could however try to implement the Exchange Journal format.

That's the right solution.

> This creates a new email, adds the envelope from and to address to the
> body, and then attaches the actual email as an eml attachment. So I
> could either write a script as a milter or use a service in master.cf
> that calls a script and passes the envelope and mail data to the
> script and the script then builds a new email in Exchange Journal
> format and transfers it directly to the archive gateway server without
> going through postfix again.

Correct.  This is what what was implemented at a previous employer when
I played a role in making archiving work.

> If you're bored feel free to send in suggestions for the script :) ^^
> Otherwise I'll use always_bcc for now and try to figure out the script
> in a few weeks when I have more time.

The always_bcc approach is flawed, so best to implement the
encapsulation delivery agent promptly.  The recipient_bcc_maps generated
recipients become arguments to the script, which just has to prepend a
stock header and MIME boundary, output the envelope encoding, then
the message, and append the closing MIME boundary.  This is rather
simple.  You don't need to parse the input message.

Various-Headers: ...
Content-Type: multipart/...; boundary = $longish-random$

--$longish-random$
Content-Type: 



--$longish-random$
Content-Type: message/rfc822



--$longish-random$--

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

[pfx] Re: How to reject messages on submission with typo in To address?

[Viktor Dukhovni via Postfix-users]

On Sun, Jan 21, 2024 at 09:39:06AM +0100, Paul Menzel via Postfix-users wrote:

> pg.de is currently a parked domain, so our users will not going to
> email there, and I would like to reject such messages submitted to us,
> that the email client shows an error as it’s done, when, for example,
> users submit a message to a colleague at our institute, and we now
> that address does not exist, because the account was closed or it does
> not exist.
> 
> Could you recommend a way how to best set this up, best with a custom error
> message per domain? For example:
> 
> Reject: Address has a typo: Should .pg.de .mpg.de?
> 
> `master.cf` currently contains:
> 
> 141.14.17.8:submission  inetn   -   n   -   - smtpd
> -o myhostname=mx.molgen.mpg.de
> -o smtpd_recipient_restrictions=$mx_smtpd_recipient_restrictions
> -o smtpd_client_recipient_rate_limit=50

main.cf:
indexed = ${default_database_type}:${config_directory}/
transport_maps = ${indexed}transport

transport:
.pg.de   error:5.1.2 Typo domain .pg.de should be .mpg.de

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

[pfx] Seeking contact with Postfix SELinux policy maintainers...

[Viktor Dukhovni via Postfix-users]

I am looking to make contact with the maintainers of the SELinux policy
profile for Postfix on Fedora (presumably ultimately also RHEL), Debian
and other systems that ship with pre-installed SELinux policy rules for
Postfix.

If you're a maintainer of such policy rules please reach out.  I had a
rather frustrating time trying to make SELinux + Postfix work on a
Fedora 39 system, but gave up and turned off SELinux.  Perhaps in the
future this can be made easier, so that others might expend less effort
and succeed.

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

[pfx] Re: Preparation of switch from OpenSMTPd to Postfix -> behaviour of smtpd_sender_login_maps pattern matching

[Viktor Dukhovni via Postfix-users]

On Sat, Jan 20, 2024 at 05:44:25PM +0100, Simon Hoffmann wrote:

> > > I am currently planning to switch from OpenSMTPd to postfix for two 
> > > reasons
> > > 
> > > - smtpd_sender_login_maps functionality not really implemented in 
> > > OpenSMTPd
> > > - always_bcc not possible on OpenSMTPd
> > 
> > FWIW, I'd like to recommend "recipient_bcc_maps" over always_bcc.
> > 
> > - You will perhaps before long want to make exceptions.
> 
> This is a Company Mail Server, and in Germany there is a rule to copy all 
> mails to a
> special archive. This my use of always_bcc to copy all mails going through 
> the server
> to the archive software import mailbox.

> > - You may want to "preserve the envelope", by generating a
> >   recipient-specific bcc address.  Just "always_bcc" fails
> >   to record "bcc" recipients, and may record header recipients
> >   who weren't actually (envelope) recipients of the message.
> 
> could you please elaborate on that (off-list is okay with me), because I 
> don't seem
> to understand your point here. 

This copies only the message headers and body, but fails to capture the
message envelope, which contains the true recipient list.  With
per-recipient addressing in "recipient_bcc_maps", and provided the
archive system captures the message envelope, you don't lose that (IMHO
essential) information.

MAIL FROM:
RCPT TO:
RCPT TO:
DATA
From:
To: 
Subject: Let's commit fraud

...
.

With "always_bcc" one might assume that the message went to
"fake-recipient", where in real-life it was sent to "bcc1" and "bcc2".
With per-recipient bcc addresses that are captured by the archive,
this is not the case.

> > Postfix tables present a key/value abstraction.  A single key in a
> > single result out.  For file-based hash tables, there is no natural key
> > "order", and any given key can match only once.
> 
> But if I [have] two *sources* specified (either two files, or one sql
> and a file, ...) postfix processes those sources in the order
> specified in main/master.cf, and never looks at the second source if
> the first source results in a match (no matter if that match means the
> user is allowed to send with that address not not).

As expected.

> So in general, if I need postfix to query *both* sources, I need to
> use a unionmap, correct?

Yes, of course.

> yes. each user can also have a few aliases, so I would either provide
> correct regexps (and would escape a dot if any actual address would
> have it)

And use "^" and "$" anchors, which is easy to forget for most (mis)users
of RE patterns.

> or would provide a hash table.

That's generally the mor robust and more scalable approach.

> > This is more simply expressed as:
> > 
> > static:internal-software-user
> 
> used in a unionmap, right?

Wherever you want an output that does not depend on the lookup key,
possibly as part of a unionmap, sure.

> Sometimes I send notifications to customers directly without using the ticket 
> system
> because they are just notifications and a ticket is only needed if the 
> customer has
> questions and replies to my notification email. But I could achieve that by 
> stating
> 
>   supp...@example.com ticket-system, myuser
> 
> in the hash map, right?

As documented.

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

[pfx] Re: Preparation of switch from OpenSMTPd to Postfix -> behaviour of smtpd_sender_login_maps pattern matching

[Viktor Dukhovni via Postfix-users]

On Sat, Jan 20, 2024 at 03:42:52PM +0100, Simon Hoffmann via Postfix-users 
wrote:

> I am currently planning to switch from OpenSMTPd to postfix for two reasons
> 
> - smtpd_sender_login_maps functionality not really implemented in OpenSMTPd
> - always_bcc not possible on OpenSMTPd

FWIW, I'd like to recommend "recipient_bcc_maps" over always_bcc.

- You will perhaps before long want to make exceptions.

- You may want to "preserve the envelope", by generating a
  recipient-specific bcc address.  Just "always_bcc" fails
  to record "bcc" recipients, and may record header recipients
  who weren't actually (envelope) recipients of the message.

So a more "sophisticated" approach is:

main.cf:
pcre = pcre:${config_directory}/
recipient_bcc_maps = ${pcre}bcc.pcre

bcc.pcre:
if !/\.bcc\.invalid$/   
# More specific patterns/exceptions as needed
/(.*)/  ${1}.bcc.invalid
endif

  and then deliver all addresses ending in ".bcc.invalid" to the
  archive

main.cf:
indexed = ${default_database_type}:${config_directory}/
transport_maps = ${indexed}transport

# No need to "split the envelope" when archiving
archive_recipient_limit = 1000

# Every message goes to the archive, give it more
# concurrency.  Ideally, low latency should help avoid
# congestion: throughput = concurrency/latency.
archive_concurrency_limit = 50

transport:
.bcc.invalidarchive:[archive.example]

master.cf:
archive unix ... smtp
  # Safety net, nothing should be rejected here...
  -o soft_bounce=yes

> While reading up on the postfix manual for smtpd_sender_login_maps I've read 
> that
> postfix stops at the first match, so if you specify two files you should use a
> unionmap or those files may not have any pattern in common.

Postfix tables present a key/value abstraction.  A single key in a
single result out.  For file-based hash tables, there is no natural key
"order", and any given key can match only once.

First match logic is however appropriate for PCRE and CIDR tables, used
e.g. with access(5) where a "DUNNO" result allows for exceptions to a
subsequent general rule.

Bottom line, yes, for pattern-based tables, where multiple keys can
match a result, the first match is natural and least surprising.

> I have users on the server that should only be allowed to send with
> their own address, but then there is a ticket system that should
> impersonate a few addresses (like sales@, support@, ...).  Furthermore
> I have a user to send email from internal software that should be able
> to impersonate all user accounts.
> 
> So if I understand correctly, a simple pcre with the following content
> would not be working for me?

Correct.

> /user@domain.com/ user@domain.com
> /user@domain.com/ user@domain.com
> /user.th...@domain.com/ user.th...@domain.com
> /sa...@domain.com/ zammad-user
> /supp...@domain.com/ zammad-user

Yet another misuse of regular expressions, I hope that in a real
deployment you'd either write:

/^user\.one@domain\.com$/ user@domain.com
/^user\.two@domain\.com$/ user@domain.com
/^user\.three@domain\.com$/ user.th...@domain.com
/^sales@domain\.com$/ zammad-user
/^support@domain\.com$/ zammad-user

or, better still, for exact matches of literals use a "hash" or "cdb"
table:

user@domain.com user@domain.com
user@domain.com user@domain.com
user.th...@domain.com   user.th...@domain.com
sa...@domain.comzammad-user
supp...@domain.com  zammad-user
...

> /.*/ internal-software-user

This is more simply expressed as:

static:internal-software-user

I should also be mention that naturally sender_login_mismatch
presumes a login, so only works at the first hop MSA to which the user's
MUA authenticates.  It won't work at a smarthost relay.

> Another alternative I thought of would be to create three separate
> pcre file and use a unionmap.

Replacing "pcre" with better/safer equivalents as much as possible, yes.

$ postmap -q foo 'unionmap:{inline:{ {foo = bar} }, inline:{ {foo = baz} }, 
static:that}'
bar,baz,that

> In the first file I would list all named/personal users with their email
> addresses and their login names,

Using instead simple "hash" or "cdb" tables and "static" as appropriate:

main.cf:
sender_login_maps =
unionmap: {
${indexed}sender-login,
${indexed}ticket-sender,
static:internal-software-user
}

sender-login:
us...@example.com   user1
us...@example.com   user2
...

ticket-sender:
tick...@example.com ticket-system
tick...@example.com ticket-system
...

without any PCRE tables at 

[pfx] Re: client checks with suspect IPs

[Viktor Dukhovni via Postfix-users]

On Tue, Jan 16, 2024 at 02:28:50PM -0500, Alex via Postfix-users wrote:

In addition to other comments, beware sloppy and inappropriate use of
"regular" expressions:

> /etc/postfix-118/client_checks.pcre:
> /74\.203\.184\.40/  OK

This should be a "cidr:" table lookup instead, and should use
permit_auth_destination, instead of "OK".

74.203.184.40/32  permit_auth_destination

> /etc/postfix-118/sender_checks.pcre:
> /myclient\.com/ permit

This should not be a regular expression check at all:

main.cf:
indexed = ${default_database_type}:${config_directory}/

smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
check_sender_access ${indexed}sender_checks,
...

sender_checks:
myclient.compermit_auth_destination
.myclient.com   permit_auth_destination

as written it allows:

- myclient.com@anydomain.example
- other-than-myclient.com@anydomain.example
- someuser@myclient.comcast
...

Correct use of regular expressions, which not only accepts all wanted
inputs, but also rejects allallunwanted inputs, is surprisingly rare.
Best practice is to avoid REs if at all possible, because you're likely
to use them incorrectly.

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

[pfx] Re: relay_domains override for smtpd

[Viktor Dukhovni via Postfix-users]

On Tue, Jan 16, 2024 at 06:12:58PM +0100, Marc Dierksen via Postfix-users wrote:

> I am running Postfix 3.5.23 on Debian 11 as an edge mailserver that accepts
> mails on port 25 for a list of domains defined as relay_domains in the
> main.cf.
>
> I am currently trying to setup a second smtpd process on port 587 that
> accepts mails only for local recipients.
> 
> If I set relay_domains to empty in the main.cf it works as expected.

The classification of input addresses into address classes as part of
transport resolution happens in trivial-rewrite(8).  This is why
changing relay_domains in smtpd(8) is ineffective.

> So it seems to me the '-o relay_domains=' parameter for smtpd does not work
> correctly.

It works correctly, as intended.  It does not seem to make much sense to
restrict submission on port 587 for a subset of addresses that any
unauthenticated external sender can target.  Your "restricted" users
could just send to port 25 instead!

That said, if this is what you actually need, instead of trying to set
an empty list of relay domains, set an empty list of valid relay
recipients, which is checked in smtpd(8):

master.cf:
submission inet ... smtpd
-o { relay_recipient_maps = inline:{@=@} }
...

because just "@" is never going to be a lookup key for a relay recipient
address.  While an empty key is even more strongly never used, and the
form "inline:{=}" is presently accepted, I expect this is not
intentional.  It would have to be documented, otherwise, at some point,
Postfix might reject empty keys in inline table definitiions.

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

[pfx] Re: DKIM => Undelivered Mail Returned to Sender

[Viktor Dukhovni via Postfix-users]

On Mon, Jan 15, 2024 at 08:14:13AM +0100, Gerd Hoerst via Postfix-users wrote:

> I added
> 
> masquerade_domains  
>   = hoerst.net
> 
> to main.cf and mail sent via mailx is sent asu...@domain.tld  and it has also 
> both DKIM Signatures inside
> (ed25519 and sha256 key)

I don't recommend masquerade_domains, it is better to set the right
domain in the first place.  For incoming mail, masquerade_domains is not
easily compatible with recipient validation.  For just outgoing mail, it
is not so bad, but I prefer canonical_maps instead, and having the right
domain in the first place (correct value of $myorigin, ...)

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

[pfx] Re: DKIM => Undelivered Mail Returned to Sender

[Viktor Dukhovni via Postfix-users]

On Sun, Jan 14, 2024 at 06:05:20PM +0100, Gerd Hoerst via Postfix-users wrote:

> Still no success..
> 
> non_smtpd_milters is set and mail send via mailx or sendmail is still not
> signed..
> 
> btw: with mailx or sendmail  email will send with u...@host.domain.tld
> instead of u...@domain.tld

Well, that could be part of the problem, since the DKIM milters tend to
only sign mail for specific "From:" domains (overly strict domain
alignment limitation).  So, you need "myorigin" to be set to the logical
email domain, rather than system the hostname.

You've also IIRC not posted your DKIM milter configuration settings, and
all settings and relevant logs should be reported after each change.

- $ postconf -nf
- $ postconf -Mf
- DKIM signer configuration
- logs of probe message delivery

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

[pfx] Re: DKIM => Undelivered Mail Returned to Sender

[Viktor Dukhovni via Postfix-users]

On Sun, Jan 14, 2024 at 04:20:29PM +0100, Gerd Hoerst via Postfix-users wrote:

> How can i check if its now correct with my setup, that mail which is not
> coming from smpt or esmtp ?

Log in to the machine and send an email message (to some address you
receive) via sendmail(1) or the mail(1) or mailx(1) wrapper.  Check
whether it was DKIM signed.

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

[pfx] Re: DKIM => Undelivered Mail Returned to Sender

[Viktor Dukhovni via Postfix-users]

On Fri, Jan 12, 2024 at 08:07:02PM -0500, Wietse Venema via Postfix-users wrote:

> > In my case it is the "daemon_name" macro, and so I have:
> > 
> > $ postconf -Mf cleanup/unix
> > cleanupunix  n   -   n   -   0   cleanup
> > -o milter_macro_daemon_name=ORIGINATING
> > 
> > Your settings may be different.  And you should avoid sending success
> > notices, especially ones that purport to report a failure.
> 
> This looks like it is the same cleanup service that is used for mail
> from the network. 
> 

It is not a problem, with mail that arrives via the smtpd(8) the
connection macros are sent by smtpd(8), not cleanup(8), so the
same cleanup works fine also for incoming mail, even with the
macro.  Though, just in case, I have a separate cleanup for
incoming mail.

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

[pfx] Re: DKIM => Undelivered Mail Returned to Sender

[Viktor Dukhovni via Postfix-users]

On Fri, Jan 12, 2024 at 11:10:52PM +0100, Gerd Hoerst via Postfix-users wrote:
> Hi !
> 
> In my main.cf
> 
> non_smtpd_milters = $smtpd_milters
> 
> is already configured...
> 
> Where else can I check ?

The milter configuration, and Postfix cleanup(8) milter macros   How
does the milter decide what/when to sign vs. verify.  In my case it
is the "daemon_name" macro, and so I have:

$ postconf -Mf cleanup/unix
cleanupunix  n   -   n   -   0   cleanup
-o milter_macro_daemon_name=ORIGINATING

Your settings may be different.  And you should avoid sending success
notices, especially ones that purport to report a failure.

-- 
Viktor.

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

[pfx] Re: DKIM => Undelivered Mail Returned to Sender

[Viktor Dukhovni via Postfix-users]

On Fri, Jan 12, 2024 at 07:43:51PM +0100, Gerd Hoerst via Postfix-users wrote:

> im using ubuntu 22.04 and i setup complete feature set  with spf / dkim /
> dmarc / dane during the last time i get some emails related to this domain
> which i do not understand (if the problem is on my side)

The problem is on your side.  Your OpenDMARC milter is sending unsigned
"failure" reports for messages that actually passed authentication.

If you're going to send reports, it is best to only send failure
reports, success reports just invite trouble (mail loops, may
be considered junk mail, ...).

The notification was not signed because you haven't arranged for DKIM
signing of locally submitted mail (non_smtpd_milters and related
settings to actually sign rather verify mail that comes in via
pickup(8)).

> From: OpenDMARC Filter 
> Date: Fri, 12 Jan 2024 15:38:56 +0100 (CET)
> Subject: FW: ABOUT YOU [DE] - Sendungsverfolgung: ayou-139-261767319
> To: dm...@aboutyou.com
> 
> This is an authentication failure report for an email message received from IP
> 87.253.238.213 on Fri, 12 Jan 2024 15:38:56 +0100 (CET).

But right below we see the message actually passed both DKIM and SPF
checks.

> Authentication-Results: smtp.hoerst.net; dkim=pass (Good 1024 bit 
>rsa-sha256 signature) header.d=aboutyou.de header.i=nore...@aboutyou.de 
>header.a=rsa-sha256
> X-Greylist: delayed 671 seconds by postgrey-1.36 at vserver.hoerst.net; Fri, 
> 12 Jan 2024 15:38:55 CET
> Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=87.253.238.213; 
> helo=o213.p13.mailjet.com; 
> envelope-from=a7de81aa.caaabq15i0caakdcyiyaayb6j6eaaay06gblo...@a406762.bnc3.mailjet.com;
>  receiver= 
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; q=dns/txt;
>   d=aboutyou.de; i=nore...@aboutyou.de; s=mailjet; x=1705076863;
>   
> h=message-id:mime-version:from:from:reply-to:to:to:subject:subject:date:date:list-unsubscribe-post:
>   list-unsubscribe:feedback-id:x-csa-complaints:x-mj-mid:x-report-abuse-to:
>   content-type:content-transfer-encoding;
>   bh=guyeDNniXPEzK0dg+G9mLcs8ZBnLy3mb2tOJ7JbZTyw=;
>   b=mcUjEaxmKzNl+cg45RwmsN8dyShRY2CEoVZyrNB8wHqyMbOKUTKOMid8U
>  4oVJnS0sYv3q1zAQrZWYRotJ+8fWrZCE3X8hk+Mw3f37Yg7kJfrNdT+8JB8b
>  alre6+/UbHBs7NC8FSRvoIv1iWwT0O+XurDc9XU+6jcl04t3NPMokM=
> Message-Id: 
> 
> [...]

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

[pfx] Re: postfix repo

[Viktor Dukhovni via Postfix-users]

On Thu, Jan 11, 2024 at 07:29:40PM +0100, Benny Pedersen via Postfix-users 
wrote:

> Wietse Venema via Postfix-users skrev den 2024-01-11 15:56:
> > natan via Postfix-users:
> > > Hi Wietse Have you thought about postfix repo for Debian, just like
> > > dovecot has for his relase ?
> > > 
> > > I'm asking by the way
> > 
> > Yes. It will happen some time.
> 
> so next is gentoo ebuilds ? :)

No.  There is no Postfix binary release build farm, and nobody has
volunteered to coördinate binary release engineering at the Postfix
project level for all supported platforms.

Since there are existing actively maintained Postfix packages for most
if not all platforms of interest, it is rather unclear what the point
would be of centralising the package builds.

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

[pfx] Re: postfix repo

[Viktor Dukhovni via Postfix-users]

On Thu, Jan 11, 2024 at 03:53:35PM +0100, natan via Postfix-users wrote:
> Hi Wietse Have you thought about postfix repo for Debian, just like dovecot
> has for his relase ?
> 

What is a "Postfix repo for Debian"?  Do you mean binary release
packages?  What's wrong with the packages from the Debian maintainers?

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

[pfx] Re: Not a very important problem - smtpd_sender_login_maps

[Viktor Dukhovni via Postfix-users]

On Thu, Jan 11, 2024 at 02:08:28PM +0100, natan via Postfix-users wrote:

> I need a mapping every single email to the same one in pcre for
> sender_login_maps.cf for
>
> reject_sender_login_mismatch
> ...
> smtpd_sender_login_maps = pcre:/etc/postfix/sender_login_maps.cf
> ...
> 
> Yes, I can use an existing map - I have such a map for outgoing e-mails
> But I need a this  "wildcard" for my MX that only works for incoming mail
> something like .*@.* -> *.@.*
> 
> I just don't want stupid bots to try to play...

It is not clear to me what question, if any, you're asking.

With Postfix >= 3.7, a PCRE identity mapping requires no additional
table files:

smtpd_sender_login_maps = pcre:{{/(.*)/ $${1}}}

with earlier releases the requisite file consists of:

/(.*)/  ${1}

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

[pfx] Re: Downloadlinks for postfix-3.9-20240109 seem to be broken

[Viktor Dukhovni via Postfix-users]

On Wed, Jan 10, 2024 at 04:47:43PM +0100, Ralf Hildebrandt via Postfix-users 
wrote:

> http://ftp.porcupine.org/mirrors/postfix-release/index.html
> 
> lists:
> 
> http://ftp.porcupine.org/mirrors/postfix-release/experimental/postfix-3.9-20240109.tar.gz
> http://ftp.porcupine.org/mirrors/postfix-release/experimental/postfix-3.9-20240109.HISTORY

The most recent snapshot on Wietse's FTP server is at the moment:

-r--r--r--  1 wietse  wheel   4908912 Jan  6 19:57 
postfix-3.9-20240106.tar.gz
-r--r--r--  1 wietse  wheel   280 Jan  6 19:57 
postfix-3.9-20240106.tar.gz.sig
-r--r--r--  1 wietse  wheel   480 Jan  6 19:57 
postfix-3.9-20240106.tar.gz.gpg1
-r--r--r--  1 wietse  wheel   220 Jan  6 19:57 
postfix-3.9-20240106.tar.gz.gpg2
-r--r--r--  1 wietse  wheel  9468 Jan  6 19:50 
postfix-3.9-20240106.RELEASE_NOTES
-r--r--r--  1 wietse  wheel991448 Jan  6 19:39 
postfix-3.9-20240106.HISTORY
... older files ...

The index was indeed modified on 2024-01-09:

-r--r--r--  1 wietse  wheel  11 Jan 10 10:04 time
-r--r--r--  1 wietse  wheel   72297 Jan  9 18:47 index.html
drwxr-xr-x  3 wietse  wheel   82432 Jan  6 20:07 experimental
drwxr-xr-x  2 wietse  wheel   89088 Dec 22 15:02 official
... older files/directories ...

but neither of the distribution directories have been updated since
2024-01-06.  So it looks like the tarball upload has not happened yet.
I expect the index and tarballs will be back in sync before long...

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

[pfx] Re: Incoming mail server blocks outlook / microsoft servers

[Viktor Dukhovni via Postfix-users]

On Wed, Jan 10, 2024 at 05:38:37PM +0200, Nikolaos Milas via Postfix-users 
wrote:

> On 10/1/2024 5:24 μ.μ., Matus UHLAR - fantomas via Postfix-users wrote:
> 
> > If you use postscreen, remove reject_rbl_client from *_restrictions.
> > 
> > reject_rhsbl_client, reject_rhsbl_sender and reject_rhsbl_helo are fine
> > to stay since they use something postscreen does not.
> 
> Thanks Matus for your prompt reply. I appreciate it a lot.

My advice is slightly different, I'd still use zen.spamhaus.org in
smtpd(8), without any of the other (more prone to be false positive)
lists.  The postscreen cached verdict can be outdated.  Keeping in mind
that of course in smtpd(8) there's no scoring, so the whitelists with
negative scores aren't available.  If you absolutely want to ensure
that the whitelists are honoured, then you need to stick to just
postscreen.

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

[pfx] Re: Redirect deferred mails via IP4 or IP6 addresses (automatically)

[Viktor Dukhovni via Postfix-users]

On Mon, Jan 08, 2024 at 07:36:37PM +0100, Michael Grimm via Postfix-users wrote:

> >smtp   unix  -   -   n   -   -   smtp
> >smtpv4 unix  -   -   n   -   -   smtp
> >-o inet_protocols=ipv4
> >smtpv6 unix  -   -   n   -   -   smtp
> >-o inet_protocols=ipv6
> > 
> > For destination domains found to have issues with IPv6 (or conversely
> > with IPv4) just specify one of the alternative transports.
> > 
> >gmail.com   smtpv4:gmail.com
> >example.com smtpv6:example.com
> 
> Thanks, this is a good solution in my case, especially due to the fact, that 
> those "reputational issues" are not that very often to solve.
> 
> But will that work, once a mail has been deferred and is sitting in the queue 
> already? 
> Meaning, if a 'postqueue -f' will retry with smtpv4, instead sticking to the 
> old IPv4 address?

Transport resolution is not "sticky", it is performed de novo, each time
a message enters the active queue.

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

[pfx] Re: recipient_bcc_maps clarification.

[Viktor Dukhovni via Postfix-users]

On Mon, Jan 08, 2024 at 10:24:15AM +0530, anant--- via Postfix-users wrote:

> For specific 2 recipients of our domain, we don't want always_bcc to be
> implemented.  ie. if a mail is addressed to a...@xx.com  (our domain only),
> mail should not be Bcc to zz...@xx.com. similarly if mail recipient is
> d...@xx.com (our domain only), mail should not be Bcc to zz...@xx.com.  For
> all others always_bcc to continue.

Suggested approach (this uses "inline" tables, but equivalent file-based
PCRE, or, in the case of the transport(5) table, hash or cdb tables also
work.

main.cf:
recipient_delimiter = +
recipient_bcc_maps = pcre:{
{ /^"(.*)"@example\.com$$/  "bcc+$${1}"@example.com }
{ /^(.*)@example\.com$$/  bcc+$${1}@example.com }
}
transport_maps = inline:{
{ bcc+...@example.com = discard:silently }
{ bcc+...@example.com = discard:silently }
}

The "$$" syntax is only needed for inline tables in main.cf, just a
single "$" is needed in  a file-based PCRE table

rcpt-bcc.pcre:
/^"(.*)"@example\.com$/  "bcc+${1}"@example.com
/^(.*)@example\.com$/  bcc+${1}@example.com

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

[pfx] Re: Redirect deferred mails via IP4 or IP6 addresses (automatically)

[Viktor Dukhovni via Postfix-users]

On Mon, Jan 08, 2024 at 04:02:48PM +0100, Michael Grimm via Postfix-users wrote:

> Sometimes outgoing mail is deferred due to "reputational issues" at
> the receiving side. These "reputational issues" mostly concerned my
> IP6 addresses, thus I removed IP6 mailing completely. But now, I do
> want to give it a try, again.
> 
> In the past, whenever a mail has been deferred, I manually modified
> inet_protocols to the protocol *not* involved, restarted postfix and
> ran 'postqueue -f'. After having the "reputational issue" solved, I
> returned to inet_protocols=all.

You shouldn't need anything nearly so complex.

I have in master.cf:

smtp   unix  -   -   n   -   -   smtp
smtpv4 unix  -   -   n   -   -   smtp
-o inet_protocols=ipv4
smtpv6 unix  -   -   n   -   -   smtp
-o inet_protocols=ipv6

For destination domains found to have issues with IPv6 (or conversely
with IPv4) just specify one of the alternative transports.

gmail.com   smtpv4:gmail.com
example.com smtpv6:example.com

Of course, as noted by Wietse, when MX-hosts for a myriad (not possible
to explicitly list) domains need a specific transport, the DNS reply
filter comes in handy.  Between that, and explicit transports you should
be able to have IPv4+IPv6 as a default with appropriate work-arounds.

Or perhaps IPv4 as a default, with IPv6 or both for domains where those
work better.

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

[pfx] Re: SMTP Smuggling with long-term fix

[Viktor Dukhovni via Postfix-users]

On 6 Jan 2024, at 12:04 pm, Damian via Postfix-users 
 wrote:
> 
> If I remember correctly, on the wire there was \r\n\r\n.\r\r\n
> 
> I will assemble a pcap and some logs when I'm back home.

That's expected, Postfix will accept one *or more* CRs before LF as CRLF.

   
https://github.com/vdukhovni/postfix/blob/d2d9daf4d1b5e8cec47bd7434264f92b4fe1ba30/postfix/src/global/smtp_stream.c#L437-L438

Does that also need to be more strict? :-(

-- 
Viktor.

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

[pfx] Re: Behaviour in case of multiple relay hosts with multiple DNS records

[Viktor Dukhovni via Postfix-users]

On Fri, Jan 05, 2024 at 06:46:01PM +0100, Peter Wienemann via Postfix-users 
wrote:

> > Unfortunately this says that RFC 5321 applies to LMTP deliveries,
> 
> RFC 2033 says: "The LMTP protocol is identical to the SMTP protocol [SMTP]
> [HOST-REQ] with its service extensions [ESMTP], except as modified by this
> document."

But, in fact LMTP MX records are only for SMTP relay, and to not apply
to either submission or LMTP.

> I do not find any exceptions mentioned in RFC 2033 concerning the choice of
> target hosts. Therefore - to my understanding - the same target selection
> rules apply for SMTP and LMTP. If this is a misunderstanding on my part,
> please correct me.

They do not.  MX records specify the location of the inbound SMTP
servers for a domain, and there is no reason to expect to find the
associated LMTP servers at the same set of servers. 

In any case, LMTP delivery is a local matter (replacing ad-hoc local
delivery IPC mechanisms), and there is no reason for a sending domain
domain to connect to the LMTP servers of an unrelated domain, so the
resolution mechanism is unspecified.

Indeed, how exactly would you specify unix-domain sockets in MX records?
This is why LMTP nexthops are just transport end-points, not logical
destinations subject to MX lookup.

Since the RFC failed to note this distinction, the problem is with the RFC.

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

[pfx] Re: Postfix stopped logging lines with sender IP addresses after upgrade

[Viktor Dukhovni via Postfix-users]

On Tue, Jan 02, 2024 at 02:44:06PM -0500, Vince Heuser via Postfix-users wrote:

> Jan 02 14:26:56 islou postfix/qmgr[2]: 4T4NC41vLCzQ1P: 
> from=, size=1258, nrcpt=1 (queue active)
> Jan 02 14:26:56 islou postfix/smtp[22517]: 4T4N9z4tYzzQ1b: to=, 
> relay=127.0.0.1[127.0.0.1]:10024, delay=57, delays=0.04/0/0/57, dsn=2.0.0, 
> status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued 
> as 4T4NC41vLCzQ1P)
> Jan 02 14:26:56 islou postfix/qmgr[2]: 4T4N9z4tYzzQ1b: removed
> Jan 02 14:26:56 islou postfix/pipe[22532]: 4T4NC41vLCzQ1P: to=, 
> relay=dovecot, delay=0.24, delays=0.03/0/0/0.21, dsn=2.0.0, status=sent 
> (delivered via dovecot service)
> Jan 02 14:26:56 islou postfix/qmgr[2]: 4T4NC41vLCzQ1P: removed

You have logging from "qmgr", the "relay" delivery agent and the
"dovecot" instance of the "pipe" delivery agent.

> islou:~# postconf -Mf
> smtp   inet  n   -   y   -   -   smtpd
> cleanup    unix  n   -   y   -   0   cleanup
> smtp   unix  -   -   y   -   -   smtp
> relay  unix  -   -   y   -   -   smtp
>     -o fallback_relay=

For the above "chroot = y".

> qmgr   fifo  n   -   n   300 1   qmgr
> dovecot    unix  -   n   n   -   -   pipe flags=DRhu
>     user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -f ${sender} -d
>     ${recipient}
> smtp-amavis unix -   -   n   -   2   smtp
>     -o smtp_data_done_timeout=1200
>     -o smtp_send_xforward_command=yes
>     -o disable_dns_lookups=yes
>     -o max_use=20

And for these "chroot = n".  That lines up quite well with
absence/presence of log entries.

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

[pfx] Re: Behaviour in case of multiple relay hosts with multiple DNS records

[Viktor Dukhovni via Postfix-users]

On Tue, Jan 02, 2024 at 11:12:28AM +0100, Peter Wienemann via Postfix-users 
wrote:

> To avoid a potential misunderstanding: I do not see any reason to cast doubt
> on the RFC compliance of Postfix. I think the issue discussed in this thread
> rather goes beyond what is specified in RFCs. It basically boils down to the
> question whether the RFC imposed ranking based on DNS record types is
> stronger or weaker than the ranking imposed by the order of the specified
> relay hosts. I neither found an answer to that question in RFCs nor in the
> Postfix documentation (I hope I have not missed anything). Wietse kindly
> answered that the RFC imposed ranking is implemented on the level of
> individual entries of the relay host list rather than on the ensemble of
> relay host entries. Maybe it is worth clarifying this point in the Postfix
> documentation.

FWIW, it seems clear to me that Postfix should try each destination in
turn, with all subsequent destinations as *fallback*, rather than
concurrent alteratives.  For concurrent alternatives, one would define a
single destination with suitable priority MX records.

One important use case is to shunt mail that fails the first delivery
attempt to a fallback queue that processes "problem" mail.

That said, indeed the documentation is not explicit on this point, one
has to read "between the lines".  If your technical writing skills are
adequate, perhaps you could suggest some concise and clear text
explaining the semantics.

This would need to be added to smtp(8), transport(5) and postconf(5),
with multiple affected parameters in the last 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 configure lmtp delivery

[Viktor Dukhovni via Postfix-users]

On Sun, Dec 31, 2023 at 08:25:42PM +0100, toganm--- via Postfix-users wrote:

> >>>>> "VDvP" == Viktor Dukhovni via Postfix-users  
> >>>>> writes:
> 
> VDvP> So the "hostname" form does not use "[]", which are only for address
> VDvP> literals. As for master.cf (master(5)), whether you need to add
> VDvP> anything or not, depends on what's already there. An entry for the
> VDvP> "lmtp" delivery agent is needed if you intend to use LMTP.
> 
> this is what I have so I should be OK, or do I need to specifiy the 
> inet:[address] instead of unix ?
> 
> lmtp  unix  -   -   n   -   -   lmtp

The LMTP nexthop syntax is for the transport(5) table or related
per-address-class defaults.  It is not for master.cf.  Do not
confuse internal Postfix service-to-service protocols with the
external protocols used to deliver mail out in delivery agents.

The queue manager communicates with all delivery via local IPC
(unix-domain sockets).  All Postfix services are of this same type.  The
only exceptions are:

- One or more TCP listeners:

smtp   inet  n   -   n   -   -   smtpd
smtp   inet  n   -   n   -   1   postscreen
submission inet  n   -   n   -   -   smtpd
submissions inet n   -   n   -   -   smtpd
628inet  n   -   n   -   -   qmqpd

- Possible SMTP service front-ended by "postscreen":

smtpd  pass  -   -   n   -   -   smtpd

- The postlog service, which listends on a single connectionless socket
  (and a process limit of 1) in order to ensure in-order logging:

postlogunix-dgram n  -   n   -   1   postlogd

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

[pfx] Re: How to configure lmtp delivery

[Viktor Dukhovni via Postfix-users]

On Sun, Dec 31, 2023 at 07:52:39PM +0100, Togan Muftuoglu via Postfix-users 
wrote:

> so the following is all I need which I wrote in the first mail
> (without the inet part) I don't need to set anything in master.cf
> 
> mailbox_transport = lmtp:inet:[172.16.0.216]:24
> virtual_transport = lmtp:inet:[172.16.0.216]:24

The lmtp(8) manpage says in part:

LMTP DESTINATION SYNTAX
   The Postfix SMTP+LMTP client supports multiple destinations separated
   by comma or whitespace (Postfix 3.5 and later).  LMTP destinations have
   the following form:

   unix:pathname
  Connect to the local UNIX-domain server that is bound to the
  specified pathname. If the process runs chrooted, an absolute
  pathname is interpreted relative to the Postfix queue directory.

   inet:hostname

   inet:hostname:port

   inet:[address]

   inet:[address]:port
  Connect to the specified TCP port on the specified local or
  remote host. If no port is specified, connect to the port
  defined as lmtp in services(4).  If no such service is found,
  the lmtp_tcp_port configuration parameter (default value of 24)
  will be used.  An IPv6 address must be formatted as
  [ipv6:address].

So the "hostname" form does not use "[]", which are only for address
literals.  As for master.cf (master(5)), whether you need to add
anything or not, depends on what's already there.  An entry for the
"lmtp" delivery agent is needed if you intend to use LMTP.

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

[pfx] Re: How to configure lmtp delivery

[Viktor Dukhovni via Postfix-users]

On Sun, Dec 31, 2023 at 06:47:25PM +0100, toganm--- via Postfix-users wrote:

> When the documentation lacks what I am looking for then is there another way?
> 
> WVvP> To integrate Dovecot, see Dovecot documentation for examples.
> 
> That does not help because dovecot is not running on the same machine.

The Postfix LMTP delivery agent supports LMTP delivery over TCP
(possibly also with STARTTLS or TLS wrapper mode).  This is documented
in the lmtp(8) manpage.

You should not generally set the LMTP recipient limit to 1.  LMTP
supports multiple mailbox recipients efficiently, and some
implementations even deduplicate the storage of large attachments sent
to multiple recipients.

> The final step is to tell Postfix to use this socket for final delivery, in 
> this case in a virtual user scenario:
> 
> virtual_transport = lmtp:unix:private/dovecot-lmtp

I would expect you'd find more examples at the Dovecot Wiki.

> The above is assuming dovecot lmtp server is local, and in my case it is not.

It does not matter.  The LMTP protocol is the same either way.  Just
specify the appropriate endpoint, along the lines of:

inet:[192.0.2.1]:24

or 

inet:[some.host.name]:24

Provided LMTP is not chrooted, or if DNS is correctly configured in the
chroot jail, the hostname form may be easier to manage.

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

[pfx] Re: postfix 'non-interactive-package' build/install to non-default target location requires existence of /etc/postfix/{main,master}.cf ?

[Viktor Dukhovni via Postfix-users]

On Sat, Dec 30, 2023 at 07:54:56PM -0500, pgnd via Postfix-users wrote:

> BUT, just-built 'postconf' FAILs,
> 
>   /usr/local/TMP/postfix-package/sbin/postconf mail_version
>   /usr/local/TMP/postfix-package/sbin/postconf: fatal: open 
> /etc/postfix/main.cf: No such file or directory

Of course, this is expected, you asked to build a distribution package
image, not a live installation.  For the latter use "make upgrade"
instead.  It will install a live image into the actual paths from which
you expect Postfix to run.

>   Preparing a pre-built package for distribution to other systems

But you did build a package image, you can't expect to run it from
the temporary image directory.  To actually use Postfix, you need
to install the image into the expected paths, and run the
first time install actions.

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

[pfx] Re: Behaviour in case of multiple relay hosts with multiple DNS records

[Viktor Dukhovni via Postfix-users]

On Fri, Dec 29, 2023 at 07:45:45PM +0100, Peter Wienemann via Postfix-users 
wrote:

> > And then shows some examples that deminstarte that the using
> > MX records is mutually exclusive with using address (A or ) records.
> 
> I think what bears the potential for confusion is what you mean by "trying
> MX records". In my opinion the example showed that MX lookups are always
> tried, even if MX records are not present

That's of course unavoidable to determine *whether* they are present.

> In that sense MX and A/ (DNS) trials are not mutually exclusive.

> What is mutually exclusive is the subsequent delivery attempt. Either
> destinations specified by MX records are tried if there are any or
> otherwise delivery is attempted to hosts specified by A/ records.

As already noted, delivery is mutually exclusive, to either the IP
addresses of hosts found in MX records, or to the addresses of the
domain if MX lookups return NODATA.

RFCs 5321, 2821 and 821 have been around long enough to expect
compliance with core elements of the SMTP specification from any
mainstream MTA, and particularly Postfix, which appears to be the most
widely deployed MTA by some measures.

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

[pfx] Re: SMTP Smuggling, workarounds and fix // Clarification on BDAT

[Viktor Dukhovni via Postfix-users]

On Wed, Dec 27, 2023 at 11:40:56PM +0100, Damian via Postfix-users wrote:

> > The attack can be mitigated by using BDAT.
> 
> Can someone clarify?

It really does not matter much, but leaving BDAT enabled can help in
some cases.  It is not necessary to go this deep down the rabbit hole.

If both the original server and the downstream incoming server support
BDAT, the SMTP smuggling will not succeed, because it depends on the
incoming server seeing a non-standard . or . as end of
message, but that's a feature of DATA, not BDAT which instead sends
explicit block lengths, and does not depend on any magic end of input
marker.

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

[pfx] Re: WTF X-ANONYMOUSTLS ???

[Viktor Dukhovni via Postfix-users]

On Wed, Dec 27, 2023 at 06:45:27AM +0100, Ralph Seichter via Postfix-users 
wrote:
> * Viktor Dukhovni via Postfix-users:
> 
> > Microsoft ESMTP MAIL Service [...]
> 
> Gee, who woulda thunk? ;-) That being said, perhaps somebody on the
> "mailop" mailing list would be able to offer more insight? Some exotic
> extension, perhaps, or a weird application level firewall? I sure hope
> it is not a part of a M$ core product.

Well, the "bing.com" ChatGPT AI reports the text quoted below, but this
still sheds exceedingly little light on why someone believed that
STARTTLS promises a "valid" certificate, while X-ANONYMOUSTLS is somehow
needed for just unauthenticated opportunistic TLS (i.e. basic RFC3207
STARTTLS).  The whole thing looks like a design blunder, that perhaps is
expected to remain hidden within the "Exchange Organisation" away from
the prying eyes of outside observers (external SMTP clients)?  The only
good news is that (after apparently many years of this being a "thing")
I don't think there's any chance of anyone else needing to implement
this to become "interoperable".

The **X-ANONYMOUSTLS** Extended SMTP extension is a feature used in
**Exchange Server** environments. Let me provide you with some
details:

1. **Purpose**:
   - **X-ANONYMOUSTLS** is used to establish a secure channel for
 SMTP traffic between **Hub servers within the organization**
 and between **Hub and Edge servers** within the same
 organization.
   - It ensures that the communication is encrypted and secure.

2. **Functionality**:
   - When enabled, **X-ANONYMOUSTLS** allows anonymous TLS
 connections between Exchange hubs and edge servers.
   - It is part of the **Microsoft proprietary SMTP extension**.

3. **Usage**:
   - **Hub servers** use **X-ANONYMOUSTLS** to communicate securely
 with each other.
   - Similarly, **Hub and Edge servers** utilize it for secure SMTP
 traffic.

4. **Documentation**:
   - You can find detailed information about the
 **Set-ReceiveConnector** cmdlet, which includes the
 **SuppressXAnonymousTls** parameter controlling the
 **X-ANONYMOUSTLS** extension, in the Microsoft Learn
 documentation¹.
   - Additionally, there are discussions on community forums, such
 as this Technet thread², where users share insights and
 experiences related to this extension.

Remember that **X-ANONYMOUSTLS** is specific to Exchange
environments, and its usage may vary based on your organization's
setup.

Source: Conversation with Bing, 27/12/2023 (1) Set-ReceiveConnector
(ExchangePowerShell) | Microsoft Learn.

https://learn.microsoft.com/en-us/powershell/module/exchange/set-receiveconnector?view=exchange-ps.
(2) How X-ANONYMOUSTLS extension is different from STARTTLS SMTP
extension?.

https://social.technet.microsoft.com/Forums/exchange/en-US/2a83f959-3a52-4b7d-9e21-3843b77fde9c/how-xanonymoustls-extension-is-different-from-starttls-smtp-extension.
(3) Exchange General FAQ3 - social.technet.microsoft.com.

https://social.technet.microsoft.com/forums/exchange/en-US/0752c1fc-1a6b-4c42-a10a-a280db2f59b8/exchange-general-faq3.

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

[pfx] WTF X-ANONYMOUSTLS ???

[Viktor Dukhovni via Postfix-users]

I can't imagine what went on in the minds of the developers who thought
it necessary to implement an "X-ANONYMOUSTLS" ESMTP extension.  What's
wrong with STARTTLS, that this was felt to be needed?

Does anyone known where this might be, at least in part, documented?

I've just run into a domain that promises TLS via DANE TLSA records, but
does not offer STARTTLS:

posttls-finger: < 220  Microsoft ESMTP MAIL Service 
ready at Wed, 27 Dec 2023 01:59:51 +0100
posttls-finger: > EHLO ...
posttls-finger: < 250- Hello []
posttls-finger: < 250-SIZE 37748736
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-DSN
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-X-ANONYMOUSTLS
posttls-finger: < 250-AUTH NTLM
posttls-finger: < 250-X-EXPS GSSAPI NTLM
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-BINARYMIME
posttls-finger: < 250-CHUNKING
posttls-finger: < 250-SMTPUTF8
posttls-finger: < 250 XRDST
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 Service closing transmission channel

It offers only X-ANONYMOUSTLS instead.  I could comment further, but I
should refrain. :-(

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

[pfx] Re: [pfx-ann] SMTP Smuggling, workarounds and fix

[Viktor Dukhovni via Postfix-users]

On Thu, Dec 21, 2023 at 04:29:20PM -0500, Wietse Venema via Postfix-users wrote:

> > >   https://gitlab.com/ohisee/block-shodan-stretchoid-census
> > 
> > I feel no particular urge to block them.
> 
> They apparently flag a lot more Postfix MTAs than Exim ones.

By "flag" you mean count instances of on the public Internet?
Is this the table you had in mind:

https://www.shodan.io/search/facet?query=port%3A25=product

Very nice if that's a fair representation of actual deployment volumes.
And then deservedly so, after 25 years of solid performance.

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

[pfx] Re: [pfx-ann] SMTP Smuggling, workarounds and fix

[Viktor Dukhovni via Postfix-users]

On Thu, Dec 21, 2023 at 03:08:57PM -0500, pgnd via Postfix-users wrote:

> > This even includes "shodan" looking
> 
> ugh. shodan.
> 
> this can help a bit
> 
>   https://gitlab.com/ohisee/block-shodan-stretchoid-census

I feel no particular urge to block them.

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

[pfx] Re: [pfx-ann] SMTP Smuggling, workarounds and fix

[Viktor Dukhovni via Postfix-users]

On Thu, Dec 21, 2023 at 02:17:34PM -0500, Wietse Venema via Postfix-users wrote:

> Kim Sindalsen via Postfix-users:
> > I'm reading that either " smtpd_data_restrictions =
> > reject_unauth_pipelining" or "smtpd_forbid_unauth_pipelining = yes" should
> > *work* for shor-term workaround, right?
> 
> They look for the same thing but at different times.
> 
> > I've had data-restrictions for years, just today added forbid_unauth for
> > good meassure.
> > 
> > Looking through logs I see:
> 
> A lot of crap on the Internet, thanks for confirming that!

Indeed, many instances of "improper command pipelining after CONNECT" in
my logs, some early talkers, but mostly HTTP or TLS Client Hello.
This even includes "shodan" looking for implicit TLS on port 25 for no
good reason:

improper command pipelining after CONNECT
from burger.census.shodan.io[66.240.219.146]: \026\003\001\000j...

But, on December 6th, my logs have a somewhat more interesting
example, with 14 instances of:

connect from unknown[14.116.39.58]
NOQUEUE: reject: RCPT from unknown[14.116.39.58]:
550 5.7.1 Client host rejected: cannot find your reverse hostname,
[14.116.39.58]; from= to=
proto=ESMTP helo=
NOQUEUE: reject: RCPT from unknown[14.116.39.58]:
550 5.7.1 Client host rejected: cannot find your reverse hostname,
[14.116.39.58]; from= to=
proto=ESMTP helo=
NOQUEUE: reject: RCPT from unknown[14.116.39.58]:
550 5.7.1 Client host rejected: cannot find your reverse hostname,
[14.116.39.58]; from= to=
proto=ESMTP helo=
NOQUEUE: reject: RCPT from unknown[14.116.39.58]:
550 5.7.1 Client host rejected: cannot find your reverse hostname,
[14.116.39.58]; from= to=
proto=ESMTP helo=
NOQUEUE: reject: RCPT from unknown[14.116.39.58]:
550 5.7.1 Client host rejected: cannot find your reverse hostname,
[14.116.39.58]; from= to=
proto=ESMTP helo=
NOQUEUE: reject: RCPT from unknown[14.116.39.58]:
550 5.7.1 Client host rejected: cannot find your reverse hostname,
[14.116.39.58]; from= to=
proto=ESMTP helo=
improper command pipelining after DATA from unknown[14.116.39.58]:
RSET\r\nMAIL FROM:\r\nRCPT TO:
\r\nDATA\r\nRSET\r\nMAIL FROM:

[pfx] Re: SMTP Smuggling short & long term fixes

[Viktor Dukhovni via Postfix-users]

On Wed, Dec 20, 2023 at 05:48:43PM -0500, Wietse Venema via Postfix-users wrote:

> Wietse Venema via Postfix-users:
> > As part of a non-responsible disclosure process, SEC Consult has
> > published an email spoofing attack that involves a composition of
> > different mail service behaviors with respect to broken line endings.
> 
> Also on-line at httpps://www.postfix.org/smtp-smuggling.html

FWIW, after minding p's:

Also on-line at https://www.postfix.org/smtp-smuggling.html

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

[pfx] Re: SMTP smuggling

[Viktor Dukhovni via Postfix-users]

On Wed, Dec 20, 2023 at 09:12:47PM +0100, John D'Orazio via Postfix-devel wrote:

> I recently encountered on a server of my own a case of SMTP smuggling.

I am very sceptical that this is in fact the case.  Which is to say,
very confident it is not.

> I was befuddled by the fact that I received a message which appeared
> to be coming from my own email address, even though from the headers I
> could see that the true actor was sending from an IP address from
> another country. And yet the email passed SPF and DKIM!

You surely misinterpreted the message content.  Postfix is never an
intermediary system in "SMTP smuggling", it can only be an end-recipient
of mishanling of non-formant line-endings in some other upstream
submission system.

> I'm now seeing a lot of articles popping up on the web about SMTP
> smuggling, and this seems to be exactly what happened in this case.

Perhaps a suggestive and enticing coincidence, but very unlikely to
actually match your situation.

> However some articles I have read are saying that Postfix is
> vulnerable to these kinds of attacks.

Only as a receiving end-system, and only to the extent that you care to
enforce DKIM and/or SPF alignment with any applicable DMARC policy.  The
real issue is in the upstream that transmits non-standard line breaks
downstream.

> Does anyone have any information on how to mitigate these attacks? Is a
> patch to Postfix feasible to protect against this vulnerability? Has a
> patch already been put in place?


On Wed, Dec 20, 2023 at 10:25:28PM +0100, John D'Orazio via Postfix-users wrote:

> I have however started implementing amavis as spam detection, which
> does use -o smtpd_data_restrictions=reject_unauth_pipelining.

That's not Amavis, that's Postfix.  Yes, if that's specified for the
port 25 inbound Postfix service, it will in most cases mitigate the
attack.  Note however, my assertion above that this is with near
certainty not the source of your observed mystery message.

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

[pfx] Re: Not all errors are postfix's fault

[Viktor Dukhovni via Postfix-users]

On Wed, Dec 20, 2023 at 03:21:03PM +, Linkcheck via Postfix-users wrote:

> 
> > How does your milter decide which messages to sign?  Does it perhaps
> > look for:
> >
> > milter_macro_daemon_name=ORIGINATING
> 
> I originally had this in place but could find no reason for it online nor
> any sufficient reason to use it, so I removed it, with no apparent change in
> performance.

It is a clear signal to milters that the message is being handled by a
(presumably authentiated) submission service, and, in the case of a DKIM
milter, should then be DKIM *signed* rather than *verified*.

My question still stands, how do you expect your OpenDKIM milter to
known which messages should be signed, and which should be verified.

If you have users connecting to your MSA from random external IP
addresses, there's no way to know, if the SUBMIT service and the
(inbound) SMTP service use the same (bidirectional) DKIM milter.

> It was in use on the old server but no sign of a macro it could refer
> to. I have now replaced it but am unsure what to do to satisfy its
> inclusion.

>From the stock "opendkim.conf":

##  MacroList macro[=value][,...]
##
##  Gives a set of MTA-provided macros which should be checked to see
##  if the sender has been determined to be a local user and therefore
##  whether or not signing should be done.  See opendkim.conf(5) for
##  more information.

# MacroList foo=bar,baz=blivit

And in:

https://linux.die.net/man/5/opendkim.conf

MacroList (dataset)
Defines a set of MTA-provided macros that should be checked to see
if the sender has been determined to be a local user and therefore
whether or not the message should be signed. If a value is specified
matching a macro name in the data set, the value of the macro must
match a value specified (matching is case-sensitive), otherwise the
macro must be defined but may contain any value. The set is empty by
default, meaning macros are not considered when making the
sign-verify decision. The general format of the value is
value1[|value2[|...]]; if one or more value is defined then the
macro must be set to one of the listed values, otherwise the macro
must be set but can contain any value.

In order for the macro and its value to be available to the filter
for checking, the MTA must send it during the protocol exchange.
This is either accomplished via manual configuration of the MTA to
send the desired macros or, for MTA/filter combinations that support
the feature, the filter can request those macros that are of
interest. The latter is a feature negotiated at the time the filter
receives a connection from the MTA and its availability depends upon
the version of milter used to compile the filter and the version of
the MTA making the connection.

This data set must be of type "file" or "csl". 

> > which should then be set for the submission service in master.cf?  Or
> > does it have a set of client IP CIDR blocks that it considers internal?
> 
> No CIDR that I'm aware of. How do I implement this, please?

You still haven't been sufficiently clear on whether your submission
users are all internal to your network and signing can be IP-based, or
whether they are roaming and authenticate via SASL, in which case an MSA
macro is the only way to go.

> > "postconf -Mf" output
> 
> My apologies. I was unaware of the f switch.

Perhaps the instructions at "DEBUG_README.html#mail" could be updated to
suggest "postconf -nf" and "postconf -Mf", now that all supported
versions of Postfix have had "-f" for some years.

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

[pfx] Re: Not all errors are postfix's fault

[Viktor Dukhovni via Postfix-users]

On Tue, Dec 19, 2023 at 04:07:11PM +, Linkcheck via Postfix-users wrote:

> Sort of. I now have a problem where (it seems) ALL authenticated mail is not
> being dkim signed 

How does your milter decide which messages to sign?  Does it perhaps
look for:

milter_macro_daemon_name=ORIGINATING

which should then be set for the submission service in master.cf?  Or
does it have a set of client IP CIDR blocks that it considers internal?

> smtp   inet  n   -   n   -   -   smtpd
> submission inet  n   -   n   -   -   smtpd
>   -o syslog_name=postfix/submission
>   -o smtpd_tls_wrappermode=no
>   -o smtpd_tls_security_level=encrypt
>   -o smtpd_tls_auth_only=yes
>   -o smtpd_sasl_auth_enable=yes
>   -o smtpd_sasl_type=dovecot
>   -o smtpd_sasl_path=private/auth
>   -o receive_override_options=no_header_body_checks
>   -o smtpd_milters=$mua_milters
>   -o tls_ssl_options=NO_RENEGOTIATION

I see no mention of that macro here...

[ By the way, try to post "postconf -Mf" output, with whitespace
  faithfully preserved. ]

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

[pfx] Re: Using a second domain for outgoing mail

[Viktor Dukhovni via Postfix-users]

On Tue, Dec 19, 2023 at 12:34:55PM -0600, Richard Raether via Postfix-users 
wrote:

> In addition, the boss just asked is there a way to restrict the group of
> users that can send from that second domain? We are using ldap for
> authentication. Please forgive any ignorance on my part.

How does your Postfix server know who the "user" is?  Is it a submission
service to which the users' mail clients connect to directly and
authenticate to via SASL?  Or is it a network perimeter "smarthost"
relay forwarding mail on behalf of internal MTAs?

The problem is much too poorly defined to give specific definitive
answers.

What sort of mail environment is "inside" your Network?  If
the user desktops and mail clients are "managed" the best place to
enforce such controls is at the user's desktop.

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

[pfx] Re: Postfix authenticated sender and From: header verification

[Viktor Dukhovni via Postfix-users]

On Tue, Dec 19, 2023 at 10:42:14AM -0500, Wietse Venema via Postfix-users wrote:

> First, there is one mistake in my last quoted paragraph above. In
> the smuggled commands, an attacker can avoid an SMTP command
> pipelining violation, by using use BDAT instead of DATA.
> Below I'm indenting the smuggling-related inputs:
> 
>   EHLO ...
>   MAIL FROM ...
>   RCPT TO ...
>   DATA
>   normal content
>   .
>   MAIL FROM ...
>   RCPT TO ...
>   BDAT ...
>   smuggled content
>   BDAT 0
>   . (command syntax error)
>   QUIT

The source of the problem is that it is technically valid to pipeline a
second mail transaction after the first without waiting for the initial
result, and BDAT removes the synchronisation point at "DATA".  At least
one of these is IMNSHO a specification error.

The BDAT (CHUNKING) ESMTP extension was defined rather a long time ago,
in a less hostile environment.  It SHOULD have specified that the first
BDAT be a pipelining pause, just like "DATA".  Without that, the
receiving MTA is supposed to tolerate receiving a stream of pipelined
BDAT commands of indeterminate length (awaiting an RSET or QUIT) even
after rejecting all the recipients and the first BDAT command.

That said, I'd expect it is far easier to require a pause between the
end of one message and the start of another.  While it is reasonable to
allow a pipelined QUIT or RSET after "DOT", anything else should require
resynchronisation (there's alreadya a resync after RSET and QUIT is of
course final).

I don't see a legitimate use-case for SMTP clients to stuff a stream of
pipelined messages down the wire without any intemediate pauses after
the initial EHLO.  Is anyone aware of sending MTAs that do that?

[ It this is something only some MUAs do, then "message stuffing" could
  be restricted to submission and trusted clients. ]


> Second, speaking of BDAT, I suspect that Microsoft's fix may still
> allow stray  when the smuggler uses BDAT for the whole transaction.
> Again, I'm indenting the smuggling-related inputs:
> 
>   EHLO ...
>   MAIL FROM ...
>   RCPT TO ...
>   BDAT ...
>   normal content
>   .
>   smuggled commands and content
>   BDAT 0
>   QUIT

[ That "BDAT 0" is of course "BDAT 0 LAST", or, more typically,
  "BDAT  LAST". ]

But the reported Microsoft "workaround" is that they won't transmit
. to a remote system that does not do BDAT, they will send
a non-BDAT ..


  After a deeper analysis of outbound SMTP servers, a peculiarity in
  Microsoft Outlook's (outlook.com) SMTP server was observed. When
  trying to send an . sequence, the message does not get
  transmitted, and the following error message is returned: 

Remote server returned '550 5.6.11 SMTPSEND.BareLinefeedsAreIllegal;
message contains bare linefeeds, which cannot be sent via DATA and
receiving system does not support BDAT' 


Note that Postfix supports BDAT, and Microsoft will presumably elect to
use it when available, so outlook.com->Postfix should never result in
SMTP message smuggling regardless of line endings, that requires either
the sending or receiving system to not support CHUNKING (BDAT).


> If my suspicion is correct, a dwnstream server may receive the
> normal and suggled content as two separate messages.

I don't see why.  It shouldn't matter how Microsoft's MTA ends up
with a message containing "." or (.), so long as
they refuse to send the violating sequence to a non-BDAT peer.  The
issue seems to be that they didn't think to apply the logic to both
variants, censoring only ., but not ..

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

[pfx] Re: Postfix authenticated sender and From: header verification

[Viktor Dukhovni via Postfix-users]

On Tue, Dec 19, 2023 at 12:20:57AM +0100, r.barclay--- via Postfix-users wrote:
> > For now, enforcement of pipelining is actually available, while
> > enforcement of  vs.  is still only a hypothetical.
> 
> As an average user without any special or legacy systems, I'd
> appreciate if one could configure Postfix as safe and secure as
> possible regarding this issue. So I'd value being on the safe side
> over being interoperable/lenient with non standard clients.  If that
> means to convert all standalone CR or LF to CRLF (?) or reject
> suspicious SMTP dialogues, I'd opt-in to whatever is necessary. :)

If you reject unauthorised pipelining, you're fine, and may even
occasionally turn away some sloppily implemented botnet spam.


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

[pfx] Re: Postfix authenticated sender and From: header verification

[Viktor Dukhovni via Postfix-users]

On Mon, Dec 18, 2023 at 05:40:49PM -0500, Wietse Venema wrote:

> > - Postfix 3.8.1, 3.7.6, 3.6.10 and 3.5.20 include the same supporting
> >   code as 3.9 snapshots, but the "smtpd_forbid_unauth_pipelining"
> >   parameter defaults to "no".
> 
> Indeed, setting "smtpd_forbid_unauth_pipelining = yes" prevents
> Postfix from accepting a smuggled message after it has allowed a
> malformed end-of-data.
> 
> This has the potential to break mail from poorly-implemented clients,
> just like a stricter enforcement of  line boundaries would.

To be more precise: just like it could break a potentially *different*
set of poorly-implemented clients.  My instinct is that fewer clients
would be broken by strict enforcement of pipelining than by strict
 enforcement, but that's a guess, and it behooves each site to
determine their own situation.

For now, enforcement of pipelining is actually available, while
enforcement of  vs.  is still only a hypothetical.

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

[pfx] Re: Postfix authenticated sender and From: header verification

[Viktor Dukhovni via Postfix-users]

On Mon, Dec 18, 2023 at 02:48:43PM -0500, Bill Cole via Postfix-users wrote:

> > This research work has now been published by Sec Consult company, see
> > link below .
> 
> It is interesting that they seem to be unaware of some SMTP basics, such as
> the fact that message bodies, message headers, and the SMTP protocol have
> different format rules, defined in different RFCs that are clearly marked as
> such. They seem to think that the problem is grounded in legitimate
> misunderstanding of imprecise RFCs, when it seems clear to me that there's
> one right interpretation.
> 
> That very much ruins my ability to take what they are saying seriously. I
> believe they tested against the proprietary systems cited and found the
> issue, I find it extremely suspect that they show no examples for Sendmail
> or Postfix, merely an assertion.
> 
> > The Postfix issues the researcher mentions, we were not able to actually
> > reproduce
> 
> This is unsuprising.

- Postfix 3.9 (pending official release soon), rejects unuthorised
  pipelining by default: "smtpd_forbid_unauth_pipelining = yes".

- Postfix 3.8.1, 3.7.6, 3.6.10 and 3.5.20 include the same supporting
  code as 3.9 snapshots, but the "smtpd_forbid_unauth_pipelining"
  parameter defaults to "no".

  This default avoids breaking compatibility in a patch to stable
  release, in case some fax-to-email machine, or other minimally
  conformant device performs illegal pipeling.

  However, for most users it is IMHO prudent to override the default to
  "yes" in their configuration, after ensuring that that this is
  compatible with their mail flows.

With illegal pipelining blocked by default, the described attempts to
inject multiple messages into Postfix as a receiving system will fail.
This is because with very high probability any "." will be
immediately followed by some part of the rest of the original message
content in the same TCP frame, or the next TCP frame in same TCP window.

To succeed, the sending TCP would have to exactly fill a TCP window with
content up and including the ., and would have to be stalled
waiting for missing ACKs.

As an outbound server, Postfix will never send ..  Its output
will always be RFC-conformant.  So any impact falls largely on systems
that send illegal bare LF in (non-BDAT) SMTP.

It should also be noted that the piggybacked message will not have a
matching DKIM signature, and can only succeed via SPF alignment.

It may be time to consider ditching SPF.

And of course, all that this "attack" achieves is "From:" header
"forgery", in cases where the outbound server would normally not allow
the submission client to use a "From:" header of their choice.

My personal view is that phishing attacks largely rely on distracting
the user with flashy message content that draws attention away from any
"From:" header that suggest the message is not "authentic".

None of the fake "Geek Squad" bills I receive on a steady basis actually
have a related domain in "From:".  They work to defraud some of their
marks by presending artfully constructed content with all the right
logos that looks like a plausible "Geek Squad" bill.

So I don't see much point for phishers to try to achieve "From:"
alignment when they can simply not bother.

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

[pfx] Re: queue_lifetime clarification

[Viktor Dukhovni via Postfix-users]

On Thu, Dec 14, 2023 at 12:41:17PM +0100, Marek Podmaka via Postfix-users wrote:

> > and used header_checks to hold the mails in queue.
> >
> > Now, as no decision is made, I want to continue to hold for another 13
> > days more.
> >
> > Will this change, hold the queue for another 13 days more? Or it
> > remembers the earlier lifetime of 7 days for those in hold queue?
>
> IMHO messages will stay in hold queue forever.

Correct, held messages are not subject to the queue lifetime limits
while they're held.  Once released, delivery will be attempted at
least once, but if that delivery is not immediately successful,
the message may expire if old enough.

> Man page for "postsuper" mentions that if you want to release a message
> from hold queue, which has been there for a long time, you should use
> "postfix -r", so it gets a new queue id and its lifetime starts from 0.

Hence the recommendation to use "postsuper -r" (not "postfix -r").

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

[pfx] Re: 25 years today

[Viktor Dukhovni via Postfix-users]

On Thu, Dec 14, 2023 at 08:20:26AM -0500, Wietse Venema via Postfix-users wrote:

> As a few on this list may recall, it is 25 years ago today that the
> "IBM secure mailer" had its public beta release. This was accompanied
> by a nice article in the New York Times business section.

Many thanks.  It's been a pleasure to come along for the ride, be it
late to the party, in April of 2001 at the suggestion of Bennett Todd.

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

[pfx] Re: TAKE NOTE 3: Upcoming new Let's Encrypt intemediate issuer CAs.

[Viktor Dukhovni via Postfix-users]

On Thu, Dec 14, 2023 at 11:04:32AM +0100, Joachim Lindenberg via Postfix-users 
wrote:

> I´d say Viktor is biased towards 3 1 1.

It isn't a bias, it is a rational recommendation.  There are multiple
issues with "2 1 1":

- With a public issuer CA, you're adding a redundant trusted party,
  with generally rather weak domain validation (DV) certificate
  issuance mechanisms.

- The underlying EE certificates are then subject to periodic
  expiration.  Some operators invariably fail to rotate them
  on time.

- A less common problem, but also unique to DANE-TA(2) is failure to
  match the hostname in the certificate.  Some operators neglect to
  make sure that the TLSA base domain aligns with a DNS name in the
  certificate.

- The CA operator can always surprise you with unexpected changes in
  their insfrastructure.

- With "3 1 1" *you* decide when to rotate your keys, pre-publish
  a "3 1 1" TLSA record matching next key, and then switch to that
  key once the TLSA record has been in place for a few TTLs.

> You may call me biased towards 2 1 1 because I dislike pinning a key
> that is supposed to rotate.

You're always pinning a key, either the issuer CA's or the end-entity
(EE) servers.  Only poor ACME tooling gets in the way of key rotation
with "3 1 1".

If you can prepare a key in advance of a certificate rollover,
prepublish the matching "3 1 1" and use that key conditionally on a
prepublication timer having elapsed, then you get key rollover without
introducing a redundant trusted third party or risking outages due to
certificate expiration, name match failures, ...

Each day, a handful of domains fail DANE validation, a large majority,
because of botched Let's Encrypt integration, where the key rotation
is not properly orchestrated.  They'd be far better off with a "pinned"
3 1 1, that they rollover at their discretion, rather than let the
ACME client break their mail system every 2 months.

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

[pfx] TAKE NOTE 3: Upcoming new Let's Encrypt intemediate issuer CAs.

[Viktor Dukhovni via Postfix-users]

My previous post on this topic noted that covered Let's Encrypt are
planning to *randomise* the choice of intermediate issuer CA used with
each renewal. 

It now turns out that they will also be switching to new underlying
intermediate CAs.  So you'll a random choice of *new* issuers.


https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/L7XoAXt_s1c/m/k_vdk9rQAwAJ

- We will be generating 5 RSA and 5 ECDSA intermediates, instead of 2
  each. We plan to automatically rotate issuance between multiple
  intermediates for improved redundancy.

- We will be shortening their validity period from 5 years to 3 years,
  to reflect our commitment to issue new intermediates every 2 years.

So anyone relying on DANE-TA(2) (certificate usage 2) needs to closely
watch for upcoming announcements from LE, and be prepared to add TLSA
records for the new intemediates soon.  Or stop playing their game, and
switch to a robust "3 1 1" + "3 1 1" model with a stable by default
key during certificate renewals.

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

[pfx] Re: [ext] Why can't I get /etc/aliases to do anything?

[Viktor Dukhovni via Postfix-users]

On Tue, Dec 05, 2023 at 04:45:49PM +, Chris Green via Postfix-users wrote:
> On Tue, Dec 05, 2023 at 05:41:11PM +0100, Ralf Hildebrandt via Postfix-users 
> wrote:
> > * Chris Green via Postfix-users :
> > 
> > > mydestination = 
> > 
> > no mail is delivered locally. Thus "/etc/aliases" doesn't get to do
> > anything
> > 
> Ah, that explains it.
> 
> So what's the minimal way of doing this?

https://www.postfix.org/MULTI_INSTANCE_README.html#split
https://www.postfix.org/MULTI_INSTANCE_README.html#quick

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

[pfx] Re: SELinux/SMTP Relay Handshake Failure

[Viktor Dukhovni via Postfix-users]

On Mon, Dec 04, 2023 at 07:20:08PM +1100, duluxoz via Postfix-users wrote:

> This issue is definitely SELinux related, because it only crops up when
> SELinux is enabled.
> 
> I'm getting a `TLS handshake failed for service=smtp
> peer=[104.199.96.85]:587` error when attempting to rely via mailjet (that's
> who's IP that is) and also brevo/sendinblue.
> 
> Any one have any ideas (apart from disabling SELinux - that is *NOT* an
> option)  :-)

It should be of course, but in the meantime, it would most productive if
you shared your configuration settings.  That is, the outputs of:

$ postconf -nf

and

$ postconf -Mf

making sure to not change the spaces or line breaks. 

> @Vicktor: you mentioned in a previous reply (which I can't find) about
> someone else having an SELinux issue around postfix's smtp(8)/relay process
> (I think) when I asked a related Q before.

SELinux was preventing "tlsproxy" from opening the client certificate
file.  Patrick had client certificates configured for use even with
remote systems where there was no access to be gained based on such
client credentials.  I recommend against configuring client certificates
as a default.

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

[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger

[Viktor Dukhovni via Postfix-users]

On Sat, Dec 02, 2023 at 11:37:55AM -0500, pgnd wrote:

> > - dane:Same as "may" in the absence of DNSSEC MX and TLSA
> 
> iiuc, this functions as
> 
>   dane, with DNSSEC MX and TLSA
>   may,  without DNSSEC MX and TLSA
> 
> is there an equivalent single form that functions as
> 
>   dane,   with DNSSEC MX and TLSA
>   fails or warns, without DNSSEC MX and TLSA
> 

To insist on DANE, use "dane-only".  There is no "warns"
mode.

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

[pfx] Re: Patch: Some TLS connections untrusted in postfix but trusted with posttls-finger

[Viktor Dukhovni via Postfix-users]

On Sat, Dec 02, 2023 at 12:44:27PM +0100, Alexander Leidinger wrote:

> > Actually "secure", which means that the match strategy is
> > "nexthop:dot-nexthop" unless you specify additional command-line
> > arguments to override the match list.
> > 
> > switch (state->level) {
> > case TLS_LEV_SECURE:
> > state->match = argv_alloc(2);
> > while (*argv)
> > argv_add(state->match, *argv++, ARGV_END);
> > if (state->match->argc == 0)
> > argv_add(state->match, "nexthop", "dot-nexthop", ARGV_END);
> > break;
> > case TLS_LEV_VERIFY:
> > state->match = argv_alloc(1);
> > while (*argv)
> > argv_add(state->match, *argv++, ARGV_END);
> > if (state->match->argc == 0)
> > argv_add(state->match, "hostname", ARGV_END);
> > break;
> > case TLS_LEV_FPRINT:
> > state->dane = tls_dane_alloc();
> > while (*argv)
> > tls_dane_add_fpt_digests(state->dane,
> > state->options.enable_rpk,
> >  *argv++, "", smtp_mode);
> > break;
> > ...

Sorry, yes, the "..." part is the default DANE setting, which, as it
happens presently:

case TLS_LEV_DANE:
case TLS_LEV_DANE_ONLY:
state->match = argv_alloc(2);
argv_add(state->match, "nexthop", "hostname", ARGV_END);
break;
}

configures matching of either the "nexthop" and the MX "hostname" in
anticipation of DANE TLSA records, but this lingers even when no TLSA
records are found.  The matching strategy is then a hybrid of "secure"
and "verify".  This can reasonably be declared a bug in
"posttls-finger".

--- a/src/posttls-finger/posttls-finger.c
+++ b/src/posttls-finger/posttls-finger.c
@@ -2138,7 +2138,15 @@ static void parse_match(STATE *state, int argc, char 
*argv[])
 #ifdef USE_TLS
 int smtp_mode = 1;
 
+/*
+ * DANE match names are configured late, once the TLSA records are in hand.
+ * For now, prepare to fall back to "secure".
+ */
 switch (state->level) {
+default:
+   state->match = 0;
+   break;
+case TLS_LEV_DANE:
 case TLS_LEV_SECURE:
state->match = argv_alloc(2);
while (*argv)
@@ -2159,11 +2167,6 @@ static void parse_match(STATE *state, int argc, char 
*argv[])
tls_dane_add_fpt_digests(state->dane, state->options.enable_rpk,
 *argv++, "", smtp_mode);
break;
-case TLS_LEV_DANE:
-case TLS_LEV_DANE_ONLY:
-   state->match = argv_alloc(2);
-   argv_add(state->match, "nexthop", "hostname", ARGV_END);
-   break;
 }
 #endif
 }

With the above, posttls-finger reports:

$ bin/posttls-finger -c -P /etc/ssl/certs/ reply.github.com
posttls-finger: server certificate verification failed for 
in-5.smtp.github.com[140.82.113.31]:25: num=62:hostname mismatch
posttls-finger: in-5.smtp.github.com[140.82.113.31]:25: 
subject_CN=*.smtp.github.com, issuer=DigiCert TLS RSA SHA256 2020 CA1, cert 
fingerprint=4B:7B:90:8B:F3:F3:28:AE:36:C2:D4:04:918
posttls-finger: Untrusted TLS connection established to 
in-5.smtp.github.com[140.82.113.31]:25: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-s6

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

[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger

[Viktor Dukhovni via Postfix-users]

On Sat, Dec 02, 2023 at 09:55:44PM +0900, Byung-Hee HWANG via Postfix-users 
wrote:
> > No, it's a pure security policy thing and an overlooked line in the mysql 
> > tls
> > policy table.
> >
> > The policy "secure" (and I assume "dane-only") doesn't work, as github is 
> > not
> > using DNSSEC. Valid policies which make this work are "verify", "may" and I
> > assume "dane" (if you have "smtp_tls_security_level = may" or verify
> > resp. "smtpd_tls_security_level = may" or verify).

Security levels usable today include:

- may: good enough to protect against passive monitoring

- encrypt: Same as above, but will never fall back to cleartext
   if for some reason a Github MX host fails to offer or
   (even after a retry) negotiate STARTTLS.

- dane:Same as "may" in the absence of DNSSEC MX and TLSA
   records, but should Github adopt DANE, becomes
   hardened also against active attacks.

- verify:  Essentialy same "encrypt", unless MX records are
   tamper-resistant via DNSSEC, or explicit match
   names are specified (becomes identical to "secure"
   with same match names).  Not recommended.

- secure:  With default, or explicit name match patterns not
   affected by MX forgery.  The default match names
   ("nexthop" and "dot-nexthop" patterns) work only
   when the MX host certificates also include SANs
   matching the nexthop or a subdomain.  If tweaked
   to use the "hostname" name match pattern, becomes
   identical to "verify".

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

[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger

[Viktor Dukhovni via Postfix-users]

On Fri, Dec 01, 2023 at 01:52:19PM +0100, Alexander Leidinger wrote:

> > No.  The problem you're reporting is with name matching.  If the
> > certificate chain failed to be constructed, that'd be reported instead.
> > You'll only see name match errors if the chain construction succeeds,
> > but the peer name matching fails.
> 
> Great to know. I didn't before you told me. Can I suggest to add this
> information to the TLS readme?

That would Postfix documenting OpenSSL library behaviour, and is not
something we can promise as a stable Postfix feature.  It just so
happens that OpenSSL first builds a chain, and then verifies various
conditions.  Perhaps building the chain first is unavoidable, because
that can bring in name constraints, or other limitations that make the
leaf certififate invalid.  So this is unlikely to change, but is not
something Postfix implements or influences.

> > The "postls-finger" program will default to "dane" or (absent DANE TLSA
> > records) "secure", rather than "may" in order to improve your odds of
> > meaningfully testing the remote cert chain.
> 
> github is not DNSSEC protected, as such - if I understand the TLS readme
> correctly, postfix will not use DANE. As such I assume, posttls-finger will
> not use DANE too.

Correct.  Therefore "posttls-finger" will use the "secure" level, and
its matching policy:

  -l level (default: dane or secure)

  The security level for the connection, default dane or secure
  depending on whether DNSSEC is available.  For syntax and
  semantics, see the documentation of smtp_tls_security_level.
  When dane or dane-only is supported and selected, if no TLSA
  records are found, or all the records found are unusable, the
  secure level will be used instead.  The fingerprint security
  level allows you to test certificate or public-key fingerprint
  matches before you deploy them in the policy table.

  Note, since posttls-finger(1) does not actually deliver any
  email, the none, may and encrypt security levels are not very
  useful.  Since may and encrypt don't require peer certificates,
  they will often negotiate anonymous TLS ciphersuites, so you
  won't learn much about the remote SMTP server's certificates at
  these levels if it also supports anonymous TLS (though you may
  learn that the server supports anonymous TLS).

However, because posttls-finger is not the smtp(8) delivery agent, it
does not use any of the "smtp_tls_..." parameters.  Instead it uses only
the "tls_..." parameters and base main.cf parameters such as
"inet_protocols", ...  The rest is via a kitchen sink of command-line
options (starting to run out of single letters, and we don't yet have
"long option" support).

> The tls policy for github.com was secure in postfix, but I may have
> overlooked what posttls-finger is doing if there is no dane record. By
> experimantation I now think it is falling back to "verify" in that case.

Actually "secure", which means that the match strategy is
"nexthop:dot-nexthop" unless you specify additional command-line
arguments to override the match list.

switch (state->level) {
case TLS_LEV_SECURE:
state->match = argv_alloc(2);
while (*argv)
argv_add(state->match, *argv++, ARGV_END);
if (state->match->argc == 0)
argv_add(state->match, "nexthop", "dot-nexthop", ARGV_END);
break;
case TLS_LEV_VERIFY:
state->match = argv_alloc(1);
while (*argv)
argv_add(state->match, *argv++, ARGV_END);
if (state->match->argc == 0)
argv_add(state->match, "hostname", ARGV_END);
break;
case TLS_LEV_FPRINT:
state->dane = tls_dane_alloc();
while (*argv)
tls_dane_add_fpt_digests(state->dane, state->options.enable_rpk,
 *argv++, "", smtp_mode);
break;
...

> At least the output between "-l may", "-l secure" and "-l verify" lead
> me to this assumption. May I suggest to add a comment to the man page
> of posttls-finger in this regard?

The manpage is sadly long, but this is document per above.


> I was under the wrong assumption that posttls-finger may have a look at my
> postfix config.

It does read main.cf, but it does not use the smtp(8) delivery agent
settings.  It uses base network and TLS settings.  Perhaps there could
be a switch that asks posttls-finger to "adopt" "smtp_tls_mumble"
settings, but that's not the case now.

> If your concern is privacy as an ideology and you assume it would be too
> costly to put a man in the middle into your communication: Maybe, maybe not.

The "may" security level is sufficient for protection against passive
monitoring.  Certificate checks are not needed for that.  They are only
useful for fending off active attacks, in which case one should also
include MX record forgery in the threat model.

[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger

[Viktor Dukhovni via Postfix-users]

On Fri, Dec 01, 2023 at 09:53:25AM +0100, Alexander Leidinger via Postfix-users 
wrote:

> > > Why should it expect reply.github.com?
> > 
> > Because that name is securely known from the recipient address.

Because, whether you're willing to understand the point or prefer to
"dig in", verifying a certificate against an attacker-supplied name is
pointless.  You gain no security by checking attacker-supplied names.

You want to deposit a bunch of cash into your bank account, I meet you
in a bar wearing a name tag that says I'm the manager of your bank, you
give me a hefty sum of money in cash to deposit into your account...

> If then someone send mails to alexan...@leidinger.net, why should it
> match the hostname against leidinger.net?

Because that's the only name worth verifying, otherwise skip the
potential delivery issues and don't verify.

> My MX is mailgate.leidinger.net, it has a SAN with mailgate.leidinger.net,
> and I expect the sending MTA to match the hostname in the MX against the SAN
> of the cert.

An active attacker can replace "your" MX with "send.money.now" for which
he has a handy certificate from Let's Encrypt.

> > The MX hostname is typically obtained via an insecure (subjet to MiTM
> > tampering) DNS lookup, so you lose all security when validating
> > certificates against the payloads of MX records.
> 
> You (and the link) are talking about trust.

Really about the futility of going through the motions of verifying
certificates in the absence of trustworthy "reference identifiers".

> I talk about the technical
> operation of establishing a TLS connection and verifying the certificate.

You can go through the motions if you want, but it won't achieve any
security goals.

> The technical problem I have is that postfix seems to use parts of the cert
> store (it validates the MX of FreeBSD, but not the MX of github), whereas
> posttls-finger uses the complete cert store.

No.  The problem you're reporting is with name matching.  If the
certificate chain failed to be constructed, that'd be reported instead.
You'll only see name match errors if the chain construction succeeds,
but the peer name matching fails.

> As answered to Wietse, the cert store is readable no permission
> problem, no user access problem, no security polcies, no chroot.

As evidenced by the fact that you got a name matching problem.

> He didn't tell that posttls-finger uses a different
> validation policy than postfix.

The "postls-finger" program will default to "dane" or (absent DANE TLSA
records) "secure", rather than "may" in order to improve your odds of
meaningfully testing the remote cert chain.

Otherwise, it uses default settings, but you have a policy table and
verious "smtp_tls_..." settings, that don't apply to posttls-finger.

> If I understand it correctly: if both have the same access to the cert
> store and the network, they should produce the same result (valid or
> not valid). They don't.

You don't appear to be interested in answers.  Rather one gets the
impression you want to make a point.  Your point has been made.  It
is wrong, but it is clear.

> I want to solve this technical problem and let them both agree, that
> the cert is valid (which it is, the SAN of the MX of github has
> *.smtp.github.com, and this is a match from a certificate validation
> point of view with the hostname the MX presents).

If you want an insecure outcome, just set the destination policy to
"may", or for a false sense of security to "verify".  The latter
will match the MX hostname (by default), but the result is pointless,
unless the domain's MX records are DNSSEC-signed, or you've configured
the expected MX hostnames explicitly (using actual names for that
site, not the "hostname" pattern).

> Please tell me what is wrong about:
>  - the MX of domain A.c points to a.B.c

You can't in most cases rely on getting that name and not a forgery.

> - a sending MTA has to take a.B.c and match it against the SAN the server
> a.B.c provides (ignoring details of doing a reverse lookup and resolving the
> resulting IP and validating that too)

A sending MTA can just skip going through pointless ceremoy verifying a
name that may be supplied by the attacker...

> In HTTP the name to match against what is provided by the user in the URL,
> in SMTP it is the MX, as the domain part of the email address is not at all
> significant for the name of the MX (see above the Google workspace example).

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

> > No, there's a mismatch between the configuration of your Postfix SMTP
> > client and what you posttls-finger was asked to do.
> 
> That's the reason why I come her and ask what I do wrong. I agree that there
> is a difference between the operation of both.

Essentially only as a result of your explicit configuration to make it so.

> What do I have to do to the MTA, to let it agree with the result of
> 

[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger

[Viktor Dukhovni via Postfix-users]

On Thu, Nov 30, 2023 at 03:37:02PM +0100, Alexander Leidinger via Postfix-users 
wrote:

> > > Nov 30 11:18:40 mailgate postfix/tlsproxy[98300]: server certificate
> > > verification failed for in-9.smtp.github.com[140.82.112.31]:25:
> > > num=62:hostname mismatch
> > 
> > That is the error.

Indeed that's the issue.  The SANs in the certificate don't match the
name matching settings for this destination.

> > The hostname your TLS configuration is probably expecting for that
> > connection is reply.github.com, but that's apparently just a mail
> > domain, not a hostname, and the machines acting as MXs for it don't use
> > a certificate with that name.
> 
> Why should it expect reply.github.com?

Because that name is securely known from the recipient address.

> The MX record lists in-9.smtp.github.com as a MX,

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

The MX hostname is typically obtained via an insecure (subjet to MiTM
tampering) DNS lookup, so you lose all security when validating
certificates against the payloads of MX records.

> This has nothing to do with the email address I want to deliver to
> this server.

See above.  You're missing the point.

> So there is a mismatch between postfix and postls-finger on a TLS
> connection level which to my understanding shall not happen.

No, there's a mismatch between the configuration of your Postfix SMTP
client and what you posttls-finger was asked to do.

> smtp_tls_policy_maps = hash:/my/tls_policy, mysql:/my/tls-policy.cf

This must be matching "reply.github.com" directly or as ".github.com".

> smtp_tls_security_level = may

Since delivery was deferred when TLS authentication failed, you were not
actually using "may", so the policy table MUST be matching the
destination.

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

[pfx] Re: What does postfix do with malformed messages?

[Viktor Dukhovni via Postfix-users]

On Wed, Nov 29, 2023 at 10:17:01AM -0500, Wietse Venema via Postfix-users wrote:

> > I see the cleanup program and all the options about when to run it and
> > what to tell it to do, but in practice, will a typical system clean
> > everything up, just locally submitted stuff, or soemthing else? TNx.
> 
> In addition to what Viktor mentioned, Postfix will add or rewrite
> headers for "local" submissions (by default, any message that does not
> come from the machine itself). See
> https://www.postfix.org/postconf.5.html#local_header_rewrite_clients

Pedantic correction, I hope this was clear, despite the verbatim text:
"remote" submissions are by default those that don't come from the
machine itself, while "local" submissions are the ones that are subject
to rewrites.

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

[pfx] Re: Turn Off Verify Service?

[Viktor Dukhovni via Postfix-users]

On Wed, Nov 29, 2023 at 03:00:24PM +1100, duluxoz via Postfix-users wrote:

> I was reading an on-line guide about hardening Postfix and came across
> a line that said that the Verify service could/should be turned off I
> the master.cf file.
> 
> Is this actually good advice, or is there some sort of "gotcha" hiding in
> the background that'll bite us in the @rse?

The advice is largely misguided, but mostly harmless, if you don't use
sender or recipient verification.  Leaving the service enabled does
not materially affect the Postfix "attack surface", but it off when
unused is fine too.

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

[pfx] Re: What does postfix do with malformed messages?

[Viktor Dukhovni via Postfix-users]

On Tue, Nov 28, 2023 at 10:04:53PM -0500, John Levine via Postfix-users wrote:

> If a malformed mail message shows up by SMTP (not local sendmail or
> submission), will postfix generally try to clean it up or just
> pass it along?

You have to be a bit more specific.  What does "malformed" mean?
Generally speaking, Postfix leaves messages alone, other than folding
very long lines when forwarding to a remote SMTP server.

Postfix will however insert a blank line after the last header and
before the first body line if there isn't one.  This can happen
when there's a malformed header (missing a ":" or the header name
is too far out of spec).

> I see the cleanup program and all the options about when to run it and
> what to tell it to do, but in practice, will a typical system clean
> everything up, just locally submitted stuff, or soemthing else? TNx.

The cleanup service is not about fixing the message syntax, its job is
primarily to perform address rewriting (primarily 1-to-1 canonical on
the envelope and headers followed by 1-to-n virtual on just the envelope
recipients).

The cleanup(8) service is also responsible for orchestrating the
optional header/body checks (user-provided regexp filters) and
passing the message content (headers and body) through any
milters.

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

[pfx] Re: [ext] gmail failing SPF/DKIM

[Viktor Dukhovni via Postfix-users]

On Mon, Nov 27, 2023 at 04:50:55PM +, Linkcheck via Postfix-users wrote:

> Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkcheck.co.uk; 
> s=mail;
>  t=1701091213; bh=...;
>  h=Date:To:From:Reply-To:Subject:From;
>  b=...

Have you tried leaving out the largely redundant "s=" from your DKIM key
record?  Compare:

mail._domainkey.linkcheck.co.uk. TXT"v=DKIM1; h=sha256; k=rsa; s=email; 
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvz7F7+W2AovZpw0lRMW/6HjaFsD8iyUsH0x/whIFNGobLP0cRiVaUmKQr62C69HMl+DpilTgtrwa3S/8i63Ym7yNeMSxsV+vbCnH9eq2l2bs6Z1MzZOLb50OmTgr6El6El1Wt/VEJc7m6rcatFpGxZWtLljaVlGwtFlpZwMYm"
 
"RI20FieK6oYl+adOyZHWdGTc7DKtHjwz0/LCwuG4bfJhXxqd56dbY33cPl/xoc3I/Sts9b8pqWtb0R9h96S4wsCYW5Egai2a2Y0Xxa/ND5Ftv6WmXPWqiWAfkRBwVxAA20WCrVTH9+3sZhtpAXmZjC3S7axsBqSl3jmtLf4zu19uQIDAQAB"

20230601._domainkey.google.com. TXT "v=DKIM1; k=rsa; 
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4zd3nfUoLHWFbfoPZzAb8bvjsFIIFsNypweLuPe4M+vAP1YxObFxRnpvLYz7Z+bORKLber5aGmgFF9iaufsH1z0+aw8Qex7uDaafzWoJOM/6lAS5iI0JggZiUkqNpRQLL7H6E7HcvOMC61nJcO4r0PwLDZKwEaCs8gUHiqRn/SS3wqEZX29v/VOUVcI4BjaOz"
 
"OCLaz7V8Bkwmj4Rqq4kaLQQrbfpjas1naScHTAmzULj0Rdp+L1vVyGitm+dd460PcTIG3Pn+FYrgQQo2fvnTcGiFFuMa8cpxgfH3rJztf1YFehLWwJWgeXTriuIyuxUabGdRQu7vh7GrObTsHmIHwIDAQAB"

Perhaps Google's DKIM implementation does not like "s="?  I expect it
does support "sha256"...

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

[pfx] Re: [ext] gmail failing SPF/DKIM

[Viktor Dukhovni via Postfix-users]

On Mon, Nov 27, 2023 at 04:04:12PM +0100, Ralf Hildebrandt via Postfix-users 
wrote:
> * Linkcheck via Postfix-users :
> 
> > If someone wishes to check this, a typical form (which is sent to me with
> > copy to "you") is at
> > https://www.linkcheck.co.uk/
> >   under menu option Contact & Enquiries.
> 
> I tried your form:
> 
> Authentication-Results: mail-cbf-ext.charite.de;
> dkim=pass header.d=linkcheck.co.uk header.s=mail header.b=LiOUpR1t;
> spf=pass (mail-cbf-ext.charite.de: domain 
> ofenquiryf...@linkcheck.co.uk designates 185.35.151.121 as permitted sender) 
> smtp.mailfrom=enquiryf...@linkcheck.co.uk; 
> dmarc=pass (policy=reject) header.from=linkcheck.co.uk
> 
> Looking good if you ask me :)

Why just the "AR" header and not also the "DKIM-Signature" header, and
perhaps also the "Return-Path" and related "Received"?

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

[pfx] Re: TAKE NOTE 2: Future Let's Encrypt CA choice randomisation.

[Viktor Dukhovni via Postfix-users]

On Thu, Nov 23, 2023 at 07:48:33PM +1100, duluxoz via Postfix-users wrote:
> Hi All,
> 
> This may be a stupid Q, but we're getting a `postfix/tlsproxy[89206]: TLS
> handshake failed for service=smtp peer=[104.199.96.85]:25` error in our logs
> when trying to relay via an SMTP Relay Service (both Mailjet and
> Brevo/SendInBlue). Could our issue be related to this LE issue?

No, failure to complete the TLS handshake is not related to any issues
with the certificates.  That said, the handshake works for me:

posttls-finger: Untrusted TLS connection established to
104.199.96.85[104.199.96.85]:25: 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: > EHLO straasha.imrryr.org
posttls-finger: < 250-smtpin.mailjet.com
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-SIZE 15728640
posttls-finger: < 250-VRFY
posttls-finger: < 250-ETRN
posttls-finger: < 250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5
posttls-finger: < 250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-SMTPUTF8
posttls-finger: < 250 CHUNKING
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 Bye

Unclear why your tlsproxy is having issues.  Perhaps the same problem as
Patrick was having with SELinux?  Don't configure any client
certificates on your end, or don't enable SELinux?

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

[pfx] Re: TAKE NOTE 2: Future Let's Encrypt CA choice randomisation.

[Viktor Dukhovni via Postfix-users]

On Thu, Nov 23, 2023 at 12:25:19PM +, Alan Munday via Postfix-users wrote:

> > > It may be prudent to mark your calendar to check the Let's Encrypt
> > > certificate page once or twice a year, and make appropriate changes if
> > > new intermediate issuer CAs are introduced, or extant ones retired.
> > > 
> > >  https://letsencrypt.org/certificates/
>
> Can I check I have not missed something here.
> 
> 
> When I use Viktor's chaingen.sh  I get a TLSA 3 1 1  which matches the
> TLSA 2 1 1 above.

That's because you're trying to use "chaingen.sh" on just the chain file
with the issuer CAs, rather than the complete chain with the server
certificate *followed* by the issuer CAs.  For Let's Encrypt, the
therefore, you need either concatenate the "cert" and "fullchain" (not
really) files:

h=$(uname -n) # or whatever MX hostname you use
l=$(uname -n) # or whatever "lineage" name is pertinent
d=/etc/letsencrypt/live/$l
eechain=$(mktemp -t fullchain.XX)
cat $d/cert.pem $d/fullchain.pem > $eechain
chaingen.sh $eechain $h
rm $eechain

or just know that all the issuer CA usages should be "2" not "3"
when running "chaingen" on a partial chain that is missing the
end-entity (EE, i.e. leaf or server) certificate.

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

[pfx] Re: No messages from freebsd.org

[Viktor Dukhovni via Postfix-users]

On Thu, Nov 23, 2023 at 05:44:47AM +0100, Jack Raats wrote:

> You're absolutely right. I am ashamed that I didn't think that DANE was
> perhaps the problem
> Short term solution was to delete the TLSA record from the DNS.
> After deleting the TLSA record the mails are getting in.

So, you'll finally implement monitoring, right???

It isn't particularly difficult:

https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html

Or will the FreeBSD list your monitoring "canary"? :-)

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

[pfx] Re: No messages from freebsd.org

[Viktor Dukhovni via Postfix-users]

On Thu, Nov 23, 2023 at 04:32:02AM +0100, Jack Raats via Postfix-users wrote:

> Can anyone help me to address the following problem.
> 
> I'm receiving messages from the dovecot and postfix mailinglist. I can get
> mail from gmail etc. but not from the freebsd mailing lists.
> 
> I get the following in maillog
> 
> Nov 23 04:23:43 nl postfix/smtpd[2135]: connect from
>mx2.freebsd.org[2610:1c1:1:606c::19:2]
> Nov 23 04:23:44 nl postfix/smtpd[2135]: Anonymous TLS connection
>established from mx2.freebsd.org[2610:1c1:1:606c::19:2]: TLSv1.3 with
>cipher TLS_AES_256_GCM>
> Nov 23 04:23:44 nl postfix/smtpd[2135]: disconnect from
>mx2.freebsd.org[2610:1c1:1:606c::19:2] ehlo=1 starttls=1 quit=1 commands=3

Not surprising, given:

https://stats.dnssec-tools.org/explore/?netnl.net

I sent a note on Nov 1th to: 

Subject: netnl.net: SMTP server DNS (DANE TLSA record) issue

Perhaps that's wasn't a good choice of contact address.  I can only
try...  I really don't understand users who deploy DANE (or any other
security technology) without implementing monitoring.  Magical thinking
that nothing could possibly go wrong?

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

[pfx] Re: How to temporarily pause virtual mail delivery?

[Viktor Dukhovni via Postfix-users]

On Wed, Nov 22, 2023 at 09:36:31PM +0100, Ralph Seichter via Postfix-users 
wrote:
> * Viktor Dukhovni via Postfix-users:
> 
> > https://www.postfix.org/postconf.5.html#defer_transports
> 
> Indeed. In my backup scripts, I like to use something like the following
> (from memory only, beware of possible typos):
> 
>   postconf -e defer_transports=lmtp,local,virtual && postfix reload
> 
> Now that I think of it again, I wonder if the reload command is even
> necessary?

If you understand:

https://www.postfix.org/OVERVIEW.html#delivering

and have read:

https://www.postfix.org/qmgr.8.html

you'll know the answer.

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

[pfx] Re: How to temporarily pause virtual mail delivery?

[Viktor Dukhovni via Postfix-users]

On Wed, Nov 22, 2023 at 07:32:06PM +, Matthias Nagel via Postfix-users 
wrote:

> Am Mittwoch, 22. November 2023, 19:01:23 CET schrieb postfix--- via 
> Postfix-users:
> > > I am looking for an option to temporarily pause delivery via LMTP and 
> > > defer mail while the Dovecot mailboxes are being backed-up in order to 
> > > get an consistent state.
> > 
> > Just take dovecot LMTP offline. Isn't the default behavior of postfix to 
> > queue undeliverable mail and once its able to deliver, it will? No need to 
> > bounce public mail with a 4xx error.
> > 
> 
> I don‘t want to bounce the mail publicly. I want Postfix to take it out of 
> the active queue, put it into the deferred queue (on the *same* mail server) 
> and Postfix shall attempt to re-deliver it later on.
> 
> Taking Dovecot LMTP offline doesn‘t seem to be that easy either. So I was 
> looking for an alternative on the Postfix side.

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

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

[pfx] Re: Postfix + mysql connection lost after RCPT

[Viktor Dukhovni via Postfix-users]

On Wed, Nov 22, 2023 at 02:59:06PM -0300, Rafael Azevedo via Postfix-users 
wrote:

> We're using Postfix + Mysql and we're getting this mysql connection
> lost issue very often.
> 
> Nov 22 14:38:28 smtp2 smtp2/smtpd[15858]: warning:
> mysql:/etc/postfix/mysql_virtual_alias_maps.cf: query failed: Lost
> connection to MySQL server during query

Somehow you never got the message that you should be using:

proxy:mysql:/path/to/table.cf

rather than

mysql:/path/to/table.cf

Your server will be much happier when you pool MySQL connections via the
proxyread(8) service.

See also the documentation of proxy_read_maps (which you don't need to
change in the most cases, just helpful context).

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

[pfx] Re: postfix does not use the MX of the parent domain

[Viktor Dukhovni via Postfix-users]

On Tue, Nov 21, 2023 at 04:24:35PM +0100, Vincent Lefevre via Postfix-users 
wrote:

> When sending a mail to some @helpdesk.inria.fr address, postfix tries
> to connect to helpdesk.inria.fr (which does not have a MX):
> 
> Nov 21 15:43:26 joooj postfix/smtp[748304]: D1A104A9:
> to=<[...]@helpdesk.inria.fr>, relay=none, delay=76462,
> delays=76431/0.1/30/0, dsn=4.4.1, status=deferred (connect to
> helpdesk.inria.fr[128.93.128.88]:25: Connection timed out)

All correct and as expected.

> Some admin at Inria tells me that this is incorrect and that postfix
> should connect to the MX of the parent domain (inria.fr) in such a
> case.

Some admin at inria has no idea what he or she is talking about, and is
just inventing things out of thin air.

Only the MX (and in their absence the A and ) of the recipient
domain are considered.  The parent domain MUST NOT be used.

If "helpdesk.inria.fr" does not receive email (no MX RRs and no SMTP
server reachable at any A or  RRs), then the email address in
question is unreachable.

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

[pfx] Re: Mail not for my domain

[Viktor Dukhovni via Postfix-users]

On Mon, Nov 20, 2023 at 10:00:01PM +0100, Joseph Castry via Postfix-users wrote:

> On my postfix server I receive some mails who are not for my domain
> (jcingenierie.fr)

How do you determine whether the message is "for youd domain"?  Are you
looking in the mail logs, the "Received" headers or the "To" and "Cc"
headers of the message.

For more specific help:

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

* postconf -nf output
* postconf -Mf output
* Relevant logs
* Received headers of a sample unwanted message

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

[pfx] Re: Amazon SES rejects text/rfc822-headers when header includes multipart content type - Workaround?

[Viktor Dukhovni via Postfix-users]

On Mon, Nov 20, 2023 at 11:02:15AM -0500, postfix--- via Postfix-users wrote:

> > You'd need to apply "body checks" to internally generated mail, which is
> > generally not recommended, and would apply regardless of context, not
> > just to bounced header-only content.
> > 
> >  main.cf:
> >  internal_mail_filter_classes = bounce
> >  bounce_body_checks = pcre:{ {~^(Content-Type:\s*multipart/)~ 
> > X-$${1}} }
> > 
> >  master.cf:
> >  bounce unix  -   -   n   -   0   bounce
> >  -o { cleanup_service_name = bounce-cleanup }
> >  bounce-cleanup unix n-   n   -   0   cleanup
> >  -o { receive_override_options = no_milters }
> >  -o { disable_mime_input_processing = no }
> >  -o { body_checks = $bounce_body_checks }
> >  -o { header_checks = }
> >  -o { nested_header_checks = }
> > 
> 
> Thank you! This might work for us (and does for this specific test case).
> But do I read you right that the danger is that if the full message is
> returned in the third part of the report then this setup would alter those
> headers as well (which would then presumably break the message, since it's
> not meant to be headers-only)?

No. This will not break actual MIME headers in the returned message, but
may interfere with message content where the string:

Content-Type: multipart/mumble

occurs at the beginning of a message body line in contexts other than
returned headers.  Note that the configuraion is narrowly targetting
just the "bounce" service, and enables only "body_checks".  It is
as safe as I know how to make it...

The caveat is there to let you know that the rule is less surgically
precise than say a tailored Postfix feature to explicitly censor or
modify the headers to be included in a header-text-only bounce.

Given infinite cycles, Postfix would support some sort of
"header-checks" like syntax for deciding how to tweak the returned
headers.  But the cost here should be borne by the guilty party (Amazon)
and not Postfix.

Barring more compelling use-cases, We should not go out of our way to 
help their broken MTA work.

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

[pfx] Re: TLS server certificate verification fails

[Viktor Dukhovni via Postfix-users]

On Mon, Nov 20, 2023 at 04:01:05PM +0100, Marc Dierksen via Postfix-users wrote:

> For the domain 'shieldersme.com' outbound TLS is configured via this entry
> in the TLS policy map:
> 
> shieldersme.com verify match=hostname:nexthop:dot-nexthop ciphers=high
> protocols=>=TLSv1.2
> 
> When trying to send mail I am getting the following error:
> 
> Nov 17 12:23:50 postfix-outbound/smtp[11269]: server certificate
> verification failed for shieldersme.com[5.79.80.155]:25: num=62:hostname
> mismatch

This is easily reproducible:

$ posttls-finger -c -Lsummary -lsecure "shieldersme.com" hostname nexthop 
dot-nexthop
posttls-finger: server certificate verification failed for 
shieldersme.com[5.79.80.155]:25: num=62:hostname mismatch
posttls-finger: Untrusted TLS connection established to 
shieldersme.com[5.79.80.155]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

And expected (i.e. works as indended and specified in all relevant RFCs):

$ posttls-finger -cC -Lsummary -lsecure "shieldersme.com" hostname nexthop 
dot-nexthop 2>&1 |
openssl crl2pkcs7 -nocrl -certfile /dev/stdin |
openssl pkcs7 -print_certs -text |
grep -E 'Subject:|DNS:'
Subject: CN=liger.hibridmena.com
DNS:liger.hibridmena.com
Subject: C=US, ST=TX, L=Houston, O=cPanel, Inc., CN=cPanel, Inc. 
Certification Authority
Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA 
Limited, CN=COMODO RSA Certification Authority

The actual certificate presented to Postfix is for:

liger.hibridmena.com

Your tests with "openssl s_client" sent a default SNI etension, but
Postfix does not by default.  With SMTP, it is unclear, in general, what
the SNI should be, and sending the "wrong" SNI can sometimes cause
connection aborts.  Therefore, if you want to solicit a particular
certificate, you have to configure the SNI explicitly.

$ posttls-finger -cC -s shieldersme.com -Lsummary -lsecure 
"shieldersme.com" hostname nexthop dot-nexthop 2>&1 |
openssl crl2pkcs7 -nocrl -certfile /dev/stdin |
openssl pkcs7 -print_certs -text |
grep -E 'Subject:|DNS:'
Subject: CN=*.shieldersme.com
DNS:*.shieldersme.com, DNS:shieldersme.com
Subject: C=US, O=Let's Encrypt, CN=R3
Subject: C=US, O=Internet Security Research Group, CN=ISRG Root X1

Relevant documentation:

posttls-finger(1):
   -s servername
  The server name to send with the TLS Server Name Indication
  (SNI) extension.  When the server has DANE TLSA records, this
  parameter is ignored and the TLSA base domain is used instead.
  Otherwise, SNI is not used by default, but can be enabled by
  specifying the desired value with this option.

postconf(5):
   mayOpportunistic TLS. Since sending in the clear is acceptable,
  demanding stronger than default TLS security merely reduces
  interoperability. The optional "ciphers", "exclude", and
  "protocols" attributes (available for opportunistic TLS with
  Postfix >= 2.6) and "connection_reuse" attribute (Postfix >=
  3.4) override the "smtp_tls_ciphers",
  "smtp_tls_exclude_ciphers", "smtp_tls_protocols", and
  "smtp_tls_connection_reuse" configuration parameters. In the
  policy table, multiple ciphers, protocols or excluded ciphers
  must be separated by colons, as attribute values may not contain
 >whitespace or commas.  At this level and higher, the optional
 >"servername" attribute (available with Postfix >= 3.4) overrides
 >the global "smtp_tls_servername" parameter, enabling
 >per-destination configuration of the SNI extension sent to the
 >remote SMTP server.  The optional "enable_rpk" attribute
  (Postfix >= 3.9) overrides the main.cf smtp_tls_enable_rpk
  parameter.  When opportunistic TLS handshakes fail, Postfix
  retries the connection with TLS disabled.  This allows mail
  delivery to sites with non-interoperable TLS implementations.

You need to add "servername=shieldersme.com" to the policy table entry.

Also, in this case, using "hostname" is a bad idea, it means you'd trust
insecurely obtained forged MX records to tell the client what name to
match, so any active attacker can compromise the connection by sending
a suitably crafted MX response.  The match pattern you want here is

nexthop:dot-nexthop

*without* "hostname".  Or (less fungible) even just "nexthop", if by
mutual agreement with the receiving system, you're sure that the cert
will "always" include the domain.

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

[pfx] Re: TAKE NOTE 2: Future Let's Encrypt CA choice randomisation.

[Viktor Dukhovni via Postfix-users]

On Sat, Nov 18, 2023 at 04:33:46PM +0900, Byung-Hee HWANG via Postfix-users 
wrote:

> > or if you prefer:
> >
> > _25._tcp.mx1.org.example. IN CNAME _25._tlsa.org.example.
> > _25._tcp.mx2.org.example. IN CNAME _25._tlsa.org.example.
> > ...
> > _25._tcp.mxN.org.example. IN CNAME _25._tlsa.org.example.
> > ;
> > _25._tlsa.org.example. IN TLSA 2 1 1 
> > 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d ; R3
> > _25._tlsa.org.example. IN TLSA 2 1 1 
> > e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 ; R4
> > _25._tlsa.org.example. IN TLSA 2 1 1 
> > 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 ; E1
> > _25._tlsa.org.example. IN TLSA 2 1 1 
> > bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 ; E2
> 
> Thank you for the clear summary. I did update all again.
> 

Good job, you're set until some future change a few years down the line.

_25._tcp.yw-0919.doraji.xyz. IN CNAME rfc7671.doraji.xyz.
_25._tcp.yw-1204.doraji.xyz. IN CNAME rfc7671.doraji.xyz.
rfc7671.doraji.xyz. IN TLSA 2 1 1 
8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
rfc7671.doraji.xyz. IN TLSA 2 1 1 
e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
rfc7671.doraji.xyz. IN TLSA 2 1 1 
276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
rfc7671.doraji.xyz. IN TLSA 2 1 1 
bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270

It may be prudent to mark your calendar to check the Let's Encrypt
certificate page once or twice a year, and make appropriate changes if
new intermediate issuer CAs are introduced, or extant ones retired.

https://letsencrypt.org/certificates/

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

[pfx] Re: Return-path: == From:

[Viktor Dukhovni via Postfix-users]

On Fri, Nov 17, 2023 at 07:19:31PM +0100, Steffen Nurpmeso via Postfix-users 
wrote:

>Remarks: many MTA installations and sites disallow setting an
>explicit reverse-path, but for members of dedicated user
>groups, or after MTA reconfiguration.
> 
> I have no idea of how far this applies to you.  (Even to postfix
> as such.)

Postfix places no restrictions on the envelope sender address of local
submission via the Postfix sendmail(1) command-line (really the
underlying internal postdrop(1) command for which sendmail(1) is the
public interface).

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

[pfx] Re: Amazon SES rejects text/rfc822-headers when header includes multipart content type - Workaround?

[Viktor Dukhovni via Postfix-users]

On Thu, Nov 16, 2023 at 03:18:13PM -0500, postfix--- via Postfix-users wrote:

> I'm thinking someone has probably already seen this and wondering if anyone
> has a work around (other than send the bounce somewhere else which may or
> may not be possible in my current situation, still investigating that).

News to me, FWIW.

> In brief if a Postfix bounce message is sent through Amazon SES, and the
> bounce message contains a third part with the Content-Type:
> text/rfc822-headers, and the original message (and therefore the body part
> of the text/rfc822-headers message) included a multipart Content-Type
> header, Amazon rejects the bounce message with "554 Transaction failed:
> Missing start boundary." I'm guessing this is an error on Amazon's part;
> they shouldn't be expecting actual inner boundary delimiters in the
> text/rfc822-headers part of the message. (Should they?)

They're definitely wrong.  It's a bug.

> I'll include the setup I used to test this below in case I'm missing
> something on my end but if not, is there a way around this? I.E., maybe some
> way to exclude that header from the text/rfc822-headers part of the message
> (for my particular usage I probably won't need it on a bounce; and if it's
> between that and getting the message delivered I'd rather it be delivered).

You'd need to apply "body checks" to internally generated mail, which is
generally not recommended, and would apply regardless of context, not
just to bounced header-only content.

main.cf:
internal_mail_filter_classes = bounce
bounce_body_checks = pcre:{ {~^(Content-Type:\s*multipart/)~ X-$${1}} }

master.cf:
bounce unix  -   -   n   -   0   bounce
-o { cleanup_service_name = bounce-cleanup }
bounce-cleanup unix n-   n   -   0   cleanup
-o { receive_override_options = no_milters }
-o { disable_mime_input_processing = no }
-o { body_checks = $bounce_body_checks }
-o { header_checks = }
-o { nested_header_checks = }

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

[pfx] TAKE NOTE 2: Future Let's Encrypt CA choice randomisation.

[Viktor Dukhovni via Postfix-users]

On Wed, Nov 15, 2023 at 04:53:17PM +0100, Geert Hendrickx via Postfix-users 
wrote:

> On Wed, Nov 15, 2023 at 10:29:41 -0500, James Cloos via Postfix-users wrote:
> > LE announced a while back that they would not renew the cross cert.
> 
> Yes, but dropping the cross-signed X1 root cert from the default chain
> last week was an accident:
> https://community.letsencrypt.org/t/shortening-the-lets-encrypt-chain-of-trust/201580/2
> 
> They plan to stop providing the cross-signed "long chain" by default
> in February 2024, and completely in June, as the cross-sign expires
> in September.  Dropping it last week was unintended.

Many thanks for that reference.  The ensuing conversation on the LE
forum uncovered a second potential future incompatibility to plan for:


https://community.letsencrypt.org/t/short-chain-and-dane/208422/8?u=ietf-dane

Let's Encrypt are apparently also planning to *randomise* the choice of
intermediate issuer CA used with each renewal.  Instead of consistently
using say "R3", they'll randomly choose one of R3/R4/E1/E2.

Therefore, anyone who publishes TLSA records for just one of the 4
issuers, will eventually also be "disappointed".

If you're using Let's Encrypt as your CA and prefer to publish
DANE-TA(2), rather than DANE-EE(3) TLSA records, please look over:



carefully, and publish all four of the **required** TLSA records, for
each MX host:

_25._tcp.mx1.org.example. IN TLSA 2 1 1 
8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d ; R3
_25._tcp.mx1.org.example. IN TLSA 2 1 1 
e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 ; R4
_25._tcp.mx1.org.example. IN TLSA 2 1 1 
276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 ; E1
_25._tcp.mx1.org.example. IN TLSA 2 1 1 
bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 ; E2
...

or if you prefer:

_25._tcp.mx1.org.example. IN CNAME _25._tlsa.org.example.
_25._tcp.mx2.org.example. IN CNAME _25._tlsa.org.example.
...
_25._tcp.mxN.org.example. IN CNAME _25._tlsa.org.example.
;
_25._tlsa.org.example. IN TLSA 2 1 1 
8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d ; R3
_25._tlsa.org.example. IN TLSA 2 1 1 
e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 ; R4
_25._tlsa.org.example. IN TLSA 2 1 1 
276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 ; E1
_25._tlsa.org.example. IN TLSA 2 1 1 
bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 ; E2

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

[pfx] Re: TAKE NOTE: "2 1 1" TLSA records vs. apparent change of Let's Encrypt default certificate chain

[Viktor Dukhovni via Postfix-users]

On Wed, Nov 15, 2023 at 09:44:18PM +0900, Byung-Hee HWANG via Postfix-users 
wrote:

> > Bottom line, if you're relying on that "2 1 1" record matching the ISRG
> > root to match your Let's Encrypt chain, you're about to be disappointed,
> > if you aren't already.  See:
> >
> > http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html
> >
> > for better alternatives, or switch to "3 1 1", perhaps with the aid of
> > "danebot" (still hoping some early adopters will pitch in to further
> > improve it, to support some additional workflows):
> >
> >
> 
> Thank you for notifying us. Also i'm using 211 TLSA record.
> 
> Honestly, 311 it was not easy to set up to me.

Your TLSA record specifies the intermediate R3 issuer, not the ISRG X1
root, so you won't be affected by the upcoming change:

doraji.xyz. IN MX 1871 yw-0919.doraji.xyz.
doraji.xyz. IN MX 1895 yw-1204.doraji.xyz.
_25._tcp.yw-0919.doraji.xyz. IN CNAME rfc7671.doraji.xyz.
_25._tcp.yw-1204.doraji.xyz. IN CNAME rfc7671.doraji.xyz.
rfc7671.doraji.xyz. IN TLSA 2 1 1 
8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d

you should, however, in that case list not just the "R3" CA, but also
its backup R4, and probably also E1 and E2, as recommended at the above
link.

Also, if you're monitoring your MTAs to regularly check that the TLSA
records match the chain, and alerting someone who can fix the problem if
not, then your setup is "too easy".  Don't deploy DANE if you're not
able to monitor it properly.  See:

https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html

You should also have code that prevents deployment of new certificate
chains that don't match the published TLSA records, and instead sticks
with the current chain.  This works best with "3 1 1", which is not
subject to expiration, though given LE automated renewal after 60 days,
but a 90 day cert lifetime, you'd have 30 days to address any issues,
if the mismatch for the new chain is reported to the operator.

This approach is taken in:

https://github.com/tlsaware/danebot

which does scheduled key rollovers only once the matching TLSA RR has
been in place for at least 2 days.

I'm requesting early adopter help to add polish to "danebot"
particularly with regard to also being able to change the list of
requested domains, and run "hooks".  If you're adept at writing robust
"bash" shell scripts, please give it a go.

Perhaps danebot could also be extended to work with not just "certbot"
but also other ACME clients.

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

[pfx] TAKE NOTE: "2 1 1" TLSA records vs. apparent change of Let's Encrypt default certificate chain

[Viktor Dukhovni via Postfix-users]

The DANE/DNSSEC survey () has seen a
recent spike in the number of MX hosts whose "2 1 1" TLSA records no
longer match their certificate chain.  The records in question all
shar the same digest value, for various TLSA base domains:

_25._tcp.mx1.example. IN TLSA 2 1 1 
0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3

I was initially puzzled as to why this might be happening, but then
it occurred to me that the reason why is clear.

The above hash is the hash of the ISRG X1 root CA key, but it is also of
course the key hash of its outdated **cross-certificate** issued by DST.
That DST cross cert was needed for compatability with some old Android
systems that did not get root CA updates (or updates of any kind).

It must be that Let's Encrypt finally stopped by default including that
cross certificate in their chains.  So instead of a chain that looks
like:

- depth 0: EE (server) certificate
- depth 1: Let's Encrypt R3/E1 issuer CA
- depth 2: ISRG X1 cross cert issued by DT

with the certificate at depth 2 matching the TLSA record, they now
generate just:

- depth 0: EE (server) certificate
- depth 1: Let's Encrypt R3/E1 issuer CA

with the ISRG (now standalone) root CA not included in the chain!

Leaving out the root CA works fine for WebPKI, where clients need to
have a locally trusted copy of the root, but not for certificate usage
DANE-TA(2), which does not rely on any local CA store:

https://dane.sys4.de/common_mistakes#4
https://datatracker.ietf.org/doc/html/rfc7672#section-3.1.2

Bottom line, if you're relying on that "2 1 1" record matching the ISRG
root to match your Let's Encrypt chain, you're about to be disappointed,
if you aren't already.  See:

http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html

for better alternatives, or switch to "3 1 1", perhaps with the aid of
"danebot" (still hoping some early adopters will pitch in to further
improve it, to support some additional workflows):

   

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

[pfx] Re: FOLLOW-UP Re: Re: [ext] list.sys4.de fails with starttls

[Viktor Dukhovni via Postfix-users]

On Tue, Nov 14, 2023 at 03:56:25PM +0100, Patrick Ben Koetter via Postfix-users 
wrote:

> It turned out that RedHat's SELinux policy does not cover Postfix' tlsproxy
> and whenever tlsproxy takes out to do what Postfix wants it to do SELinux will
> interfere and prohibit it from doing that. That in consequence made the SMTP
> service throttle and so it came to a stillstand.

In particular, presumably read access to the client cert .pem files was
blocked, though perhaps access to other essential resources was also
denied.

> For the moment we decided to do without TLS session caching in Postfix
> smtp-client *and* sending client side x509 certificates on demand in
> favor of running a more secure platform.

I am having some trouble parsing the above.  I think you're saying
you're keeping SELinux enabled ("more secure platform"), and going
without client certs *and* without TLS connection reuse.

My vague impression from upthread was that disabling client certs was
sufficient, and connection reuse would then work?  Was that not the
case?

> Our long-term goal is to re-enable the Postfix features *and* use
> SELinux.  (RedHat if you're on this list and following this thread
> ping me offlist and I'll be happy to share all information we can
> provide.)

My recommendation of not gratuitously enabling client certs stands, they
add no value when (almost always) the server can't use them in any
meaningful way.

Client certificates are for prior bilateral security arrangements
with *specific* servers that know what to do with specific client
certificates.

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

[pfx] Re: LDAP - how to design a virtual domain alias table?

[Viktor Dukhovni via Postfix-users]

On Tue, Nov 14, 2023 at 06:32:55PM +0100, Francis Augusto Medeiros-Logeay via 
Postfix-users wrote:

> I figured out all the queries I need, except one. You see, right now,
> I use Postfixadmin and my query for virtual_mailbox_domains is like
> this:
> 
> query = SELECT goto
> FROM alias, alias_domain
>WHERE alias_domain.alias_domain = '%d'
>  AND alias.address = CONCAT('%u', '@', alias_domain.target_domain)
>  AND alias.active = 1
>  AND alias_domain.active=‘1’

Your relational data model is normalised to store each user alias just
once, under the primary domain of each alternate domain.  You get to
attach secondary domains to a primary domain without losing recipient
validation by doing wildcard rewrites.

You reduced the amount of data to manage, at the cost of being unable to
assign valid addresses on a per-user basis, with some users having a
different subset of associated secondary domains than others.

This type of normalisation is idiomatic for SQL, but is not idiomatic
(or necessarily possible) with LDAP.

LDAP schemas are not normalised, they are "star-like".  Typical LDAP
objects Objects have multi-valued attributes representing 1-to-many
relationships, such as the set of all the valid addresses of a user
object.

The LDAP representation of a mail user would typically have (attribute
name choices vary, though "cn" for the 'display name', and "mail" for
the single-valued primary address are essentially standard.

  user.ldif:
cn: Joe User
uid: joeuser
mail: joe.user@someorg.example
maildrop: joeuser@imap1.someorg.example
mailacceptinggeneralid: joe.user@someorg.example
mailacceptinggeneralid: joe.user@aliasorg1.example
mailacceptinggeneralid: joe.user@aliasorg2.example
mailacceptinggeneralid: joeuser@someorg.example
mailacceptinggeneralid: userjoe@someorg.example
...

  virtual.cf:
query = mailacceptinggeneralid=%s
result_attribute = maildrop

  canonical.cf:
query = mailacceptinggeneralid=%s
result_attribute = mail

Mail can be sent to the user under each of the *explicitly* listed
addresses, but is typically canonicalised to "mail" in outbound email
(all headers and envelope sender).  Inbound mail is rewritten to
"maildrop" (just the envelope recipient) for storage.

Other designs are possible, see LDAP_README for variations.

But you're unlikely to find (or ultimately want) data model parity.
LDAP directories just aren't SQL databases.  If you want to assign
every user in some collection the same set of domains, that would
be done as of provisioning and maintaining the user "entries",
rather than computed via relational query logic.

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