[pfx] Re: Update: What features to deprecate

[Wietse Venema via Postfix-users]

Peter via Postfix-users:
> On 21/02/24 12:40, Wietse Venema via Postfix-users wrote:
> > Peter via Postfix-users:
> >>> A quick status update.
> >>>
> >>> First, several features have been logging warnings that they would
> >>> be removed for 10 years or more, so we could delete them in good
> >>> conscience (perhaps keeping the warning with the suggested alternative).
> >>> This change has not yet been made.
> > 
> > Note that this IS a breaking change: features are removed. But
> > there have been warnings for 10+ years that this was coming.
> 
> Right, this is the main reason why I think that releasing as 4.0 would 
> be appropriate.  I do realize that these features have been deprecated 
> for a long time but still they are, as you say, breaking changes and so 
> releasing as 4.0 will help a lot to distinguish that.

It's three (permit_naked_ip_address, reject_maps_rbl, check_relay_domains)
that have been logging warnings since 2005 or earlier). I find it
hard to justify a major version change for their removal.

> >>> Next, I have added new warnings for the following features, so that
> >>> they can be removed some 5 years down the road.
> >> ...
> >>> The present state is in postfix-3.9-20240218. I have slienced the
> >>> noisy warnings for deprecated and unused configuration parameters
> >>> so that they are not logged while upgrading or installing Postfix.
> >>> The warnings are still logged, once, with postfix start, start-fg,
> >>> check, reload, or status.
> >>
> >> Just a quick thought here.  I think it would make sense to release this
> >> as Postfix 4.0 since removing and deprecating a large number of features
> >> should probably be considered quite a major change.
> > 
> > I'm not sure that I follow. This is not a breaking change. it just logs
> > a reminder that there will be a breaking change a few years from now.
> 
> I didn't mean to imply that these are breaking changes.  Simply taking 
> the whole of these changes into account along with the breaking changes 
> above seems to lend support to releasing as 4.0.

There is a lot more work that needs to be done, that could result
in 5.x in just a few years. It's not impossible to have major
versions a few yearts apart,  but I'd like keep a major version for
the time that were removing those 17 obsolete TLS parameters
(_use_tls, _enforce_tls, _per_site, and some otther ones).

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

[pfx] Re: Update: What features to deprecate

[Peter via Postfix-users]

On 21/02/24 12:40, Wietse Venema via Postfix-users wrote:

Peter via Postfix-users:

A quick status update.

First, several features have been logging warnings that they would
be removed for 10 years or more, so we could delete them in good
conscience (perhaps keeping the warning with the suggested alternative).
This change has not yet been made.


Note that this IS a breaking change: features are removed. But
there have been warnings for 10+ years that this was coming.


Right, this is the main reason why I think that releasing as 4.0 would 
be appropriate.  I do realize that these features have been deprecated 
for a long time but still they are, as you say, breaking changes and so 
releasing as 4.0 will help a lot to distinguish that.



Next, I have added new warnings for the following features, so that
they can be removed some 5 years down the road.

...

The present state is in postfix-3.9-20240218. I have slienced the
noisy warnings for deprecated and unused configuration parameters
so that they are not logged while upgrading or installing Postfix.
The warnings are still logged, once, with postfix start, start-fg,
check, reload, or status.


Just a quick thought here.  I think it would make sense to release this
as Postfix 4.0 since removing and deprecating a large number of features
should probably be considered quite a major change.


I'm not sure that I follow. This is not a breaking change. it just logs
a reminder that there will be a breaking change a few years from now.


I didn't mean to imply that these are breaking changes.  Simply taking 
the whole of these changes into account along with the breaking changes 
above seems to lend support to releasing as 4.0.



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

[pfx] Re: Update: What features to deprecate

[Wietse Venema via Postfix-users]

Peter via Postfix-users:
> > A quick status update.
> > 
> > First, several features have been logging warnings that they would
> > be removed for 10 years or more, so we could delete them in good
> > conscience (perhaps keeping the warning with the suggested alternative).
> > This change has not yet been made.

Note that this IS a breaking change: features are removed. But
there have been warnings for 10+ years that this was coming.

> > Next, I have added new warnings for the following features, so that
> > they can be removed some 5 years down the road.
> ...
> > The present state is in postfix-3.9-20240218. I have slienced the
> > noisy warnings for deprecated and unused configuration parameters
> > so that they are not logged while upgrading or installing Postfix.
> > The warnings are still logged, once, with postfix start, start-fg,
> > check, reload, or status.
> 
> Just a quick thought here.  I think it would make sense to release this 
> as Postfix 4.0 since removing and deprecating a large number of features 
> should probably be considered quite a major change.

I'm not sure that I follow. This is not a breaking change. it just logs
a reminder that there will be a breaking change a few years from now.

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

[pfx] Re: Update: What features to deprecate

[Peter via Postfix-users]

On 19/02/24 14:00, Wietse Venema via Postfix-users wrote:

Viktor Dukhovni via Postfix-users:

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


Over 25 years, Postfix has accumulated some features that
are essentially obsolete.


A quick status update.

First, several features have been logging warnings that they would
be removed for 10 years or more, so we could delete them in good
conscience (perhaps keeping the warning with the suggested alternative).
This change has not yet been made.

...

Next, I have added new warnings for the following features, so that
they can be removed some 5 years down the road.

...

The present state is in postfix-3.9-20240218. I have slienced the
noisy warnings for deprecated and unused configuration parameters
so that they are not logged while upgrading or installing Postfix.
The warnings are still logged, once, with postfix start, start-fg,
check, reload, or status.


Just a quick thought here.  I think it would make sense to release this 
as Postfix 4.0 since removing and deprecating a large number of features 
should probably be considered quite a major change.



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

[pfx] Update: What features to deprecate

[Wietse Venema via Postfix-users]

Viktor Dukhovni via Postfix-users:
> On Tue, Feb 13, 2024 at 12:23:32PM -0500, Wietse Venema via Postfix-users 
> wrote:
> 
> > Over 25 years, Postfix has accumulated some features that 
> > are essentially obsolete.

A quick status update. 

First, several features have been logging warnings that they would
be removed for 10 years or more, so we could delete them in good
conscience (perhaps keeping the warning with the suggested alternative).
This change has not yet been made.

- permit_naked_ip_address logs a warning since Postfix 2.0. This
  feature has no alternative, because it is unsafe.

- reject_maps_rbl logs a warning sice Postfix 2.1. The suggested
   alternative is to use reject_rbl_client.

- check_relay_domains logs a warning since Postfix 2.2. The 
  suggested alternative is to use reject_nauth_destination.

Next, I have added new warnings for the following features, so that
they can be removed some 5 years down the road.

- permit_mx_backup now logs a warning. The suggested alternative
  is to use relay_domains.

- disable_dns_lookups was documented as deprecated since Postfix
  2.11 but had no warning. The suggested alternative is to specify
  smtp_dns_support_level.

- xxx_use_tls, xxx_enforce_tls now log a warning that they will
  be removed. The with suggested alternative is to specify
  xxx_tls_security_level.

- xxx_per_site now log a warning that they will be removed. The
  suggested alternative is to specify xxx_policy_maps.

- smtpd_tls_dh1024_param_file, smtpd_tls_eecdh_grade now log a
  warning that they will be removed, with no asuggested alternative
  (i.e. do not specify, leave these at their defaults).

Notably mmissing from the list is address masquerading. The alternative
for that would be to specify canonical mappings, but this is not as
convenient, so it would require documentation for which I may not
have time.

The logging for deprecated parameters looks like this:

postconf: warning: /etc/postfix/main.cf: support for parameter
disable_dns_lookups will be removed; instead, specify
smtp_dns_support_level

The present state is in postfix-3.9-20240218. I have slienced the
noisy warnings for deprecated and unused configuration parameters
so that they are not logged while upgrading or installing Postfix.
The warnings are still logged, once, with postfix start, start-fg,
check, reload, or status.

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

[pfx] Re: What features to deprecate

[Nikolai Lusan via Postfix-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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

FWIW I use multi-master LDAP  with a bunch of virtual transport and
relay records in main.cf. This also has the benefit that my MX hosts can
authenticate users and allow them to send email out via that route in
the event of the main [submission] host being down.

The solution may not be for everyone, but has worked for me in a number
of scenarios - even one where the actual mail server was "hidden" (the
bosses term, not mine) behind a couple of layers of MX and was (I'm not
going to name names) a particular "collaboration suite" that was a java
web frontend with a combination of different FOSS tools underneath - the
ones that were of use to me were openldap, postfix, dovecot, and
mysql/maraidb. This allowed us to extract lists of valid domains, and
email addresses to let through the remote MX's (both in and out) - all
we had to do was run a small script once an hour to get those lists, and
if they had changed push them out to the MX hosts. This solution was
_almost_ as good as having either multi-master or slave nodes for LDAP
(or a database server if that is you weapon of choice). Distributing
your data like this can be good for redundancy purposes as well (being
able to dump and backup a database, ldap directory, or even just text
lists in multiple locations can save your bacon when things get rough),
it can also make it easier for failover and faster for passing through
only legitimate mail. 

Three of the documentation pages with either relevant information, or
config directives that can help with this are:
   https://www.postfix.com/SMTPD_ACCESS_README.html
   https://www.postfix.com/VIRTUAL_README.html
   https://www.postfix.com/SMTPD_POLICY_README.html
   
And if that's not enough just start reading the page with _all_ the
configuration directive and figure out what you need 

- -- 
Nikolai Lusan
Email: niko...@lusan.id.au

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAmXMvx8ACgkQ4ZaDRV2V
L6RgOQ//bzBsmvF8G/lxIfhUhZ/tBlWv0kHpeYnUzizj93R9P6ODfv3UjTm+gYH1
RlCe0zbeQ+rbnx7H4jTJRnp1Uy9R8zhw+RVj3zPtFEQYXAc+iN45P6GeZh6K+a6q
/v3Qw5G18qHJ5fFOmo2ojMNl/s9hjecuaMUwLRrFrf93JlQkBERTctKiSWRAv5eq
/WaicL/hlpk+U1cwFrWTcxoAaZ+DTBrBmBZVG5zpRY/s2vvhx+wbY7rRAViirmM2
6kqIOwEmNOuxYNd7yFMQEQS2DRNkfmX8XjrN/XW5Il+Z0aS4TyswNderc/KLR/rg
Zs2RiCKot8l/9Pr1vBxPbYBGu4D074mJTOGicOodYeQC6BhA1QFbAh5TzkQxnuJ1
vqC+2lHkD4eyVogvLPfkrI6xU5Birn/Fh/G5xCER3fWq0Ae1SVksakriBCOMSw02
izrd0Ehdh5BSxjiHc2ixVR7uSOjNu6l8OgNBntw8PnXiwvcTUVOyPKelYIsGT6u0
7kOe81I+E9qm1wa8tg4HRoB7+sMLpsxqbhDNAW3x0DzsW7vbkcDtt2slxiwzDcRT
CH0EGAInFZeLh2weoLalNDcpp5QCAz4GzOyxfjmtS7WMfuJghtpmBO7ar0CqvZQC
nVKxIeaSWJsVxbu/AkFLZajuR1scjyBP5rmXdmWBN47YyoENJO8=
=4/pO
-END PGP SIGNATURE-
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: What features to deprecate

[Aleksandar Ivanisevic via Postfix-users]

> On 14. Feb 2024, at 09:23, Geert Hendrickx via Postfix-users 
>  wrote:
> 
>> Of course it is best dealt with at the source by configuring the
>> client systems to use the correct domain.
> 
> 
> Perhaps, but not all client systems are under our control (trusted but not
> necessarily cooperative), and it is convenient to manage the (evolving)
> mail policy in a central place, rather than on a large number of variour
> client systems.  (and even there, a single masquerade_domains setting would
> be handier than an explicit canonical_maps).

Having just introduced ‘masquerade_domains’, I can not agree more, “trusted but 
not necessarily cooperative” is a beautiful way to put it ;)
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: What features to deprecate

[Geert Hendrickx via Postfix-users]

On Tue, Feb 13, 2024 at 12:51:51 -0500, Viktor Dukhovni via Postfix-users wrote:
> On Tue, Feb 13, 2024 at 06:32:14PM +0100, Geert Hendrickx via Postfix-users 
> wrote:
> > What's the alternative for masquerade_domains ?
> 
> It is canonical_maps, ideally with explicit mappings for each expected
> non-canonical address.  For an outbound-only Postfix relay or submission
> instance, the canonical mapping could use wildcards or regular
> expression mappings.  Though in the same context (no inbound mail) the
> use of "masquerade_domains" has little down-side.


Yes, we use masquerade_domains on an outbound mail relay for a large group
of internal servers (typically sending cron mail or other automated reports,
so no inbound mail).  This was/is the classical case for masquerade_domains?

We rewrite only envelope_sender from user@host.domain to user@domain for
SPF compliance (not needing an SPF record for each individual hostname).
The From header is left alone, as it is DMARC aligned.

Achieving the same with canonical_maps would require regular expressions,
as there is no catch-all ".domain" support in canonical(5) ?


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


Perhaps, but not all client systems are under our control (trusted but not
necessarily cooperative), and it is convenient to manage the (evolving)
mail policy in a central place, rather than on a large number of variour
client systems.  (and even there, a single masquerade_domains setting would
be handier than an explicit canonical_maps).


Geert


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

[pfx] Re: What features to deprecate

[Viktor Dukhovni via Postfix-users]

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

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

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

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

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

[pfx] Re: What features to deprecate

[Wietse Venema via Postfix-users]

Viktor Dukhovni via Postfix-users:
> On Tue, Feb 13, 2024 at 12:23:32PM -0500, Wietse Venema via Postfix-users 
> wrote:
> 
> > Over 25 years, Postfix has accumulated some features that 
> > are essentially obsolete.
> > 
> > - permit_mx_backup is fundamentally incompatible with recipient
> > address validation. There is no way to work around that with
> > reject_unverified_recipient, because that requires that a domain
> > is reachable, and in that case permit_mx_backup is not needed.
> > Log a deprecation warning with compatibility_levels>=3.9.
> > 
> > - masquerade_domains complicates table-driven address validation.
> > Log a deprecation warning with compatibility_levels>=3.9.
> > 
> > - disable_dns_lookups can be migrated to smtp_dns_support_level
> > which implements a superset of the functionality. Log a deprecation
> > warning with compatibility_levels>=3.9.
> > 
> > What else needs to go?
> 
> Obsoleted by TLS security levels:
> 
> - lmtp_enforce_tls
> - lmtp_use_tls
> - postscreen_enforce_tls
> - postscreen_use_tls
> - smtp_enforce_tls
> - smtp_use_tls
> - smtpd_enforce_tls
> - smtpd_use_tls
> - tlsproxy_client_enforce_tls
> - tlsproxy_client_use_tls
> - tlsproxy_enforce_tls
> - tlsproxy_use_tls
> 
> Obsoleted by TLS policy maps:
> 
> - lmtp_tls_per_site
> - smtp_tls_per_site
> - tlsproxy_client_per_site

The above are easy to flag if explicitly set. No risk of breaking
code.

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

Isn't that TLS version dependent, or have we already lost support for 
the old way?

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

That's a lot of code that would have to become compatibility level dependent.
This is likely too invasive for Postfix 3.9.

Wietse

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

[pfx] Re: What features to deprecate

[Wietse Venema via Postfix-users]

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

The proper alternative is a two-way 1:1 mapping between internal
email addresses and the corresponding addresses in 'publicly visible'
domains.

On an inbound email gateway, accept only recipients in 'publicly
visible' domains, and map the envelope recipient to the corresponding
internal address.

On an outbound email gateway, accept only sender addresses that
have a 'publicly visible' equivalent, and convert internal address
forms to the 'public' forms.

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

[pfx] Re: What features to deprecate

[Viktor Dukhovni via Postfix-users]

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

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

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

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

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

[pfx] Re: What features to deprecate

[Viktor Dukhovni via Postfix-users]

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

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

Obsoleted by TLS security levels:

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

Obsoleted by TLS policy maps:

- lmtp_tls_per_site
- smtp_tls_per_site
- tlsproxy_client_per_site

Obsoleted by automatic negotiation in the SSL code:

- smtpd_tls_dh1024_param_file = auto
- smtpd_tls_eecdh_grade = auto

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

Perhaps more controversial:

- parent_domains_matches_subdomains

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

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

[pfx] Re: What features to deprecate

[Geert Hendrickx via Postfix-users]

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


What's the alternative for masquerade_domains ?


Geert


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

[pfx] What features to deprecate

[Wietse Venema via Postfix-users]

Over 25 years, Postfix has accumulated some features that 
are essentially obsolete.

- permit_mx_backup is fundamentally incompatible with recipient
address validation. There is no way to work around that with
reject_unverified_recipient, because that requires that a domain
is reachable, and in that case permit_mx_backup is not needed.
Log a deprecation warning with compatibility_levels>=3.9.

- masquerade_domains complicates table-driven address validation.
Log a deprecation warning with compatibility_levels>=3.9.

- disable_dns_lookups can be migrated to smtp_dns_support_level
which implements a superset of the functionality. Log a deprecation
warning with compatibility_levels>=3.9.

What else needs to go?

Wietse
___
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: What does postfix do with malformed messages?

[Wietse Venema via Postfix-users]

John Levine via Postfix-users:
> 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?
>
> 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

Wietse
___
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] What does postfix do with malformed messages?

[John Levine via Postfix-users]

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?

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.

R's,
John


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

[pfx] Re: What is best way for backup solution?

[Byung-Hee HWANG via Postfix-users]

Dear Matt,

Matt Kinni via Postfix-users  writes:

> Are you just talking about backing up the config files in /etc/postfix?
> I would recommend using git for version control; there is nothing
> special about backing up the postfix configs vis a vis any other
> service on your machine.  It also wouldn’t hurt to take periodic
> snapshots of your VMs

Also i like git! Wonderful advice, thanks!

Sincerely,

-- 
^고맙습니다 _地平天成_ 감사합니다_^))//
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: What is best way for backup solution?

[Matt Kinni via Postfix-users]

Are you just talking about backing up the config files in /etc/postfix?
I would recommend using git for version control; there is nothing special about 
backing up the postfix configs vis a vis any other service on your machine.  It 
also wouldn’t hurt to take periodic snapshots of your VMs

Sent from my iPad

> On Mar 28, 2023, at 22:57, Byung-Hee HWANG via Postfix-users 
>  wrote:
> 
> Hellow,
> 
> I am running two Postfix servers. Both are in Cloud -- Google GCP and
> Rimuhosting-EU VM. Recently i thought that i have to backup servers
> setting values. Because sometimes i meet minor accidents.
> 
> Somebody say Docker is good for backup. Though i would like to hear more
> opinions. Any comments welcome!
> 
> My domain is this [DORAJI.XYZ].
> 
> Sincerely,
> 
> -- 
> ^고맙습니다 _地平天成_ 감사합니다_^))//
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] What is best way for backup solution?

[Byung-Hee HWANG via Postfix-users]

Hellow,

I am running two Postfix servers. Both are in Cloud -- Google GCP and
Rimuhosting-EU VM. Recently i thought that i have to backup servers
setting values. Because sometimes i meet minor accidents.

Somebody say Docker is good for backup. Though i would like to hear more
opinions. Any comments welcome!

My domain is this [DORAJI.XYZ].

Sincerely,

-- 
^고맙습니다 _地平天成_ 감사합니다_^))//
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Re: What is happening here? (TLS Library Problem)

[Wietse Venema]

SSL_OP_IGNORE_UNEXPECTED_EOF will be enabled in the upcoming
stable releases, expected by this weekend.

Wietse

Miriam Espana Acebal:
> Hi all,
> 
> I was working on the same case for a bug open in Ubuntu
> https://bugs.launchpad.net/debian/+source/postfix/+bug/1995312 (It was
> reported to Debian also at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011040 ) when using
> postfix when openssl3. I developed a solution similar to Viktor's proposed
> in this thread. Still, I doubted if it was affecting only the server-side,
> client-side or both, although I would opt toward both, as an abrupt
> disconnection can happen in both ways... but as I said, it was a thing I
> want to share here for discussion and advice, also proposing if you could
> pick one of the proposed fixes in future patches or releases to solve the
> bugs (as I didn't see it in the incoming postfix 3.8 either).
> 
> I put the setting of the  SSL_OP_IGNORE_UNEXPECTED_EOF in the function
> tls_bug_bits (src/tls/tls_misc.c) used by both client and server
> connections:
> 
> --- a/src/tls/tls_misc.c
> +++ b/src/tls/tls_misc.c
> @@ -1355,6 +1355,9 @@ longtls_bug_bits(void)
>   * options just in case.
>   */
>  bits |= SSL_OP_SINGLE_ECDH_USE | SSL_OP_SINGLE_DH_USE;
> +#ifdef SSL_OP_IGNORE_UNEXPECTED_EOF
> +bits |= SSL_OP_IGNORE_UNEXPECTED_EOF;
> +#endif
>  return (bits);
>  }
> 
> I tested this fix in Ubuntu Jammy (potsfix 3.6.4-1ubuntu1), Ubuntu Kinetic
> (potsfix3.6.4-1ubuntu2 ) and also 23.04 (our on-development version,
> postfix 3.7.3-4) and I'll document that in the Ubuntu bug.
> 
> I really appreciate any help you can provide and many thanks for
> considering my request.
> 
> 
> On Tue, Jun 14, 2022 at 5:17 PM Demi Marie Obenour 
> wrote:
> 
> > On 6/10/22 08:55, Gerben Wierda wrote:
> > >
> > >> On 10 Jun 2022, at 13:17, Wietse Venema  wrote:
> > >>
> > >> Wietse Venema:
> > >>> Gerben Wierda:
> > >>>>
> > >>>>> On 10 Jun 2022, at 02:30, Wietse Venema 
> > wrote:
> > >>>>>
> > >>>>> Gerben Wierda:
> > >>>>>> What is happening here? (mail is delivered, I?m just curious)
> > >>>>>>
> > >>>>>> Jun 09 23:37:39 mail postfix/postscreen[4294]: CONNECT from
> > [146.185.52.133]:10400 to [192.168.2.66]:25
> > >>>>>> Jun 09 23:37:45 mail postfix/postscreen[4294]: PASS NEW
> > [146.185.52.133]:10400
> > >>>>>> Jun 09 23:37:45 mail smtp/smtpd[4296]: connect from
> > ims-smtp133.persgroep-ops.net[146.185.52.133]
> > >>>>>> Jun 09 23:37:46 mail smtp/smtpd[4296]: CC868E75AA1E: client=
> > ims-smtp133.persgroep-ops.net[146.185.52.133]
> > >>>>>> Jun 09 23:37:47 mail postfix/cleanup[4300]: CC868E75AA1E:
> > message-id=<
> > 220609233739.sim_40lt1wa1poje3tjw6hnmtvk29xxj_ghn7vvejgut3cs3hljfekzafd9hipabzz8ro0vetlr2qj0j2ddp9oie2u%2bfuro...@ims-smtp133.persgroep-ops.net
> > >
> > >>>>>> Jun 09 23:37:48 mail postfix/qmgr[8801]: CC868E75AA1E: from=<
> > nore...@mail.trouw.nl>, size=34628, nrcpt=1 (queue active)
> > >>>>>> Jun 09 23:37:48 mail smtp/smtpd[4296]: warning: TLS library
> > problem: error:0A000126:SSL routines::unexpected eof while
> > reading:ssl/record/rec_layer_s3.c:309:
> > >>>>>> Jun 09 23:37:48 mail smtp/smtpd[4296]: disconnect from
> > ims-smtp133.persgroep-ops.net[146.185.52.133] ehlo=2 starttls=1 mail=1
> > rcpt=1 data=1 commands=6
> > >>>>>>
> > >>>>>
> > >>>>> Did you look for 0A000126 with a web search engine?
> > >>>>
> > >>>> Yes. Searched on the entire error string as well.
> > >>>>
> > >>>> But that did not give me a clue.
> > >>>
> > >>> I got: OpenSSL 3 is more strict about clients that disconnect without
> > >>> fully following the protocol.
> > >>
> > >> Specifically, google 0A000126, the first result is PHP issue 8369a
> > >
> > > Indeed. Interesting. I use duckduckgo (which relies on Bing afaik) and
> > it doesn?t find that.
> > >
> > >> which links to https://github.com/openssl/openssl/issues/11378 <
> > https://github.com/openssl/openssl/issues/11378>. The
> > >> latter had a breaking fix, backed it out for OpenSSL 1.1.1, but
> > >> kept it in the branch that become OpenSSL 3.
> > >
> > > So basically, the sender doesn?t properly close the SSL protocol, their
> > MTA is using an SSL which isn?t properly implemented.
> >
> > My understanding is that a truncation attack is never a problem in
> > SMTP, as a premature EOF is always an SMTP error.  If this is in
> > fact the case, Postfix should set SSL_OP_IGNORE_UNEXPECTED_EOF to
> > tell OpenSSL to not treat a missing close_notify as an error.
> > --
> > Sincerely,
> > Demi Marie Obenour (she/her/hers)
> 
> 
> 
> -- 
> Miriam Espa?a Acebal
> Software Engineer II - Ubuntu PublicCloud/Server
> Canonical Ltd.

Re: What is happening here? (TLS Library Problem)

[Miriam Espana Acebal]

Hi all,

I was working on the same case for a bug open in Ubuntu
https://bugs.launchpad.net/debian/+source/postfix/+bug/1995312 (It was
reported to Debian also at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011040 ) when using
postfix when openssl3. I developed a solution similar to Viktor's proposed
in this thread. Still, I doubted if it was affecting only the server-side,
client-side or both, although I would opt toward both, as an abrupt
disconnection can happen in both ways... but as I said, it was a thing I
want to share here for discussion and advice, also proposing if you could
pick one of the proposed fixes in future patches or releases to solve the
bugs (as I didn't see it in the incoming postfix 3.8 either).

I put the setting of the  SSL_OP_IGNORE_UNEXPECTED_EOF in the function
tls_bug_bits (src/tls/tls_misc.c) used by both client and server
connections:

--- a/src/tls/tls_misc.c
+++ b/src/tls/tls_misc.c
@@ -1355,6 +1355,9 @@ longtls_bug_bits(void)
  * options just in case.
  */
 bits |= SSL_OP_SINGLE_ECDH_USE | SSL_OP_SINGLE_DH_USE;
+#ifdef SSL_OP_IGNORE_UNEXPECTED_EOF
+bits |= SSL_OP_IGNORE_UNEXPECTED_EOF;
+#endif
 return (bits);
 }

I tested this fix in Ubuntu Jammy (potsfix 3.6.4-1ubuntu1), Ubuntu Kinetic
(potsfix3.6.4-1ubuntu2 ) and also 23.04 (our on-development version,
postfix 3.7.3-4) and I'll document that in the Ubuntu bug.

I really appreciate any help you can provide and many thanks for
considering my request.


On Tue, Jun 14, 2022 at 5:17 PM Demi Marie Obenour 
wrote:

> On 6/10/22 08:55, Gerben Wierda wrote:
> >
> >> On 10 Jun 2022, at 13:17, Wietse Venema  wrote:
> >>
> >> Wietse Venema:
> >>> Gerben Wierda:
> >>>>
> >>>>> On 10 Jun 2022, at 02:30, Wietse Venema 
> wrote:
> >>>>>
> >>>>> Gerben Wierda:
> >>>>>> What is happening here? (mail is delivered, I?m just curious)
> >>>>>>
> >>>>>> Jun 09 23:37:39 mail postfix/postscreen[4294]: CONNECT from
> [146.185.52.133]:10400 to [192.168.2.66]:25
> >>>>>> Jun 09 23:37:45 mail postfix/postscreen[4294]: PASS NEW
> [146.185.52.133]:10400
> >>>>>> Jun 09 23:37:45 mail smtp/smtpd[4296]: connect from
> ims-smtp133.persgroep-ops.net[146.185.52.133]
> >>>>>> Jun 09 23:37:46 mail smtp/smtpd[4296]: CC868E75AA1E: client=
> ims-smtp133.persgroep-ops.net[146.185.52.133]
> >>>>>> Jun 09 23:37:47 mail postfix/cleanup[4300]: CC868E75AA1E:
> message-id=<
> 220609233739.sim_40lt1wa1poje3tjw6hnmtvk29xxj_ghn7vvejgut3cs3hljfekzafd9hipabzz8ro0vetlr2qj0j2ddp9oie2u%2bfuro...@ims-smtp133.persgroep-ops.net
> >
> >>>>>> Jun 09 23:37:48 mail postfix/qmgr[8801]: CC868E75AA1E: from=<
> nore...@mail.trouw.nl>, size=34628, nrcpt=1 (queue active)
> >>>>>> Jun 09 23:37:48 mail smtp/smtpd[4296]: warning: TLS library
> problem: error:0A000126:SSL routines::unexpected eof while
> reading:ssl/record/rec_layer_s3.c:309:
> >>>>>> Jun 09 23:37:48 mail smtp/smtpd[4296]: disconnect from
> ims-smtp133.persgroep-ops.net[146.185.52.133] ehlo=2 starttls=1 mail=1
> rcpt=1 data=1 commands=6
> >>>>>>
> >>>>>
> >>>>> Did you look for 0A000126 with a web search engine?
> >>>>
> >>>> Yes. Searched on the entire error string as well.
> >>>>
> >>>> But that did not give me a clue.
> >>>
> >>> I got: OpenSSL 3 is more strict about clients that disconnect without
> >>> fully following the protocol.
> >>
> >> Specifically, google 0A000126, the first result is PHP issue 8369a
> >
> > Indeed. Interesting. I use duckduckgo (which relies on Bing afaik) and
> it doesn’t find that.
> >
> >> which links to https://github.com/openssl/openssl/issues/11378 <
> https://github.com/openssl/openssl/issues/11378>. The
> >> latter had a breaking fix, backed it out for OpenSSL 1.1.1, but
> >> kept it in the branch that become OpenSSL 3.
> >
> > So basically, the sender doesn’t properly close the SSL protocol, their
> MTA is using an SSL which isn’t properly implemented.
>
> My understanding is that a truncation attack is never a problem in
> SMTP, as a premature EOF is always an SMTP error.  If this is in
> fact the case, Postfix should set SSL_OP_IGNORE_UNEXPECTED_EOF to
> tell OpenSSL to not treat a missing close_notify as an error.
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)



-- 
Miriam España Acebal
Software Engineer II - Ubuntu PublicCloud/Server
Canonical Ltd.

Re: A little help/clarification on what SPF does please

[Matus UHLAR - fantomas]

What I'm not clear about is what happens when the mail is sent onwards
by the 'smarthost' at Gandi.  Does it change the envelope sender to


Send an email to yourself and have a look at the headers.
Some MTAs add received headers like "received by  for ".


On 14.01.23 19:10, Gerald Galster wrote:

I meant Return-Path or look at your maillog on the incoming mail
you've sent to yourself.


Return-Path: is header usually added by mailserver when delivering mail.
The envelope from: address is put to Return-Path in such case.

You see the envelope from: address in mail logs, but while transferring 
e-mail via SMTP, Return-Path often does not exist.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Windows 2000: 640 MB ought to be enough for anybody

Re: A little help/clarification on what SPF does please

[Matus UHLAR - fantomas]

On 14.01.23 11:02, Chris Green wrote:
>I use postfix on my home server and deliver mail by connecting to my
>hosting providers' "smart host" using authenticated SMTP.
>
>My home system's hostname is zbmc.eu but I don't use that domain in my
>E-Mail address, I use isbd.co.uk which domain is hosted at one of my
>hosting providers (mythic-beasts.com).
>
>However most of the time I use my hosting at gandi.net to send my
>E-Mail, so mail from ch...@isbd.co.uk originates on zbmc.eu, is
>transferred by authenticated SMTP to mail.gandi.net and is sent on
>from there to whatever its destination is.

>As I understand it the SPF records for mail.gandi.net purely confirm
>to a receiving mail server that the mail is coming from mail.gandi.net
>and reverse DNS look-up confirms that it really is mail.gandi.net.
>Have I got that right?



On Sat, Jan 14, 2023 at 04:55:45PM +0100, Matus UHLAR - fantomas wrote:

SPF records for mail.gandi.net are checked when someone sends mail from
@mail.gandi.net (you don't) or when server introduces itself as
mail.gandi.net (I assume yours introduces as zbmc.eu).


On 14.01.23 16:45, Chris Green wrote:

Yes, my server's postfix is on zbmc.eu but since the connection to
Gandi is authenticated I assume Gandi will accept my E-Mails anyway.


usually yes, they of course can do that (but there's no point)


so, you should not care about SPF record for mail.gandi.net but for SPF
record for isbd.co.uk



How does isbd.co.uk's SPF record get involved, it's hosted at Mythic
Beasts so never sees my E-Mails sent from zbmc.eu to Gandi.


when you or someone send mail from @isbd.co.uk, the recipient server checks 
SPF records of isbd.co.uk to see if the sending client is allowed to send 
mail from that domain.


mail.gandi.net may not check SPF for that domain if you use their server 
(they may), and when mail.gandi.net sends that mail to anyone, the 
destination server will look if mail.gandi.net is listed in SPF record of 
isbd.co.uk.



As above, I don't see how isbd.co.uk's SPF record gets involved at
all, isbd.co.uk is hosted at mythic-beasts.com.  I have another
(unrelated) domain registered at Gandi (that I thus have a password
there that I use to autheticate the connection from zbmc.eu)


You send mail from @isbd.co.uk, the SPF is designed to stop people using 
domains they have no relation to. So, if you use @isbd.co.uk in your sender 
address, they will check if you are allowed to send mail from @isbd.co.uk.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"Two words: Windows survives." - Craig Mundie, Microsoft senior strategist
"So does syphillis. Good thing we have penicillin." - Matthew Alton

Re: A little help/clarification on what SPF does please

[Gerald Galster]

>> What I'm not clear about is what happens when the mail is sent onwards
>> by the 'smarthost' at Gandi.  Does it change the envelope sender to
> 
> Send an email to yourself and have a look at the headers.
> Some MTAs add received headers like "received by  for ".


I meant Return-Path or look at your maillog on the incoming mail
you've sent to yourself.

Best regards
Gerald

Re: A little help/clarification on what SPF does please

[Gerald Galster]

>> Given an email from ch...@isbd.co.uk, originating at zbmc.eu and sent
>> via mail.gandi.net (authenticated smtp submission) to b...@server.com:
>> 
>> - server.com sees the ip address of mail.gandi.net (incoming connection)
>> - server.com querys DNS for ch...@isbd.co.uk (host -t txt isbd.co.uk)
>> - server.com cannot find the ip address of mail.gandi.net within spf
>> - server.com might quarantine or classify your mail as spam because of ~all.
>> 
>> The solution would be to include mail.gandi.net's ips in the spf
>> of isbd.co.uk (ip4, ip6, include, ...) so that it is authorized
>> to send emails in the name of @isbd.co.uk.
>> 
> Brilliant explanation, thank you.
> 
> In reality the envelope sender for E-Mail sent out of my home server
> is s...@zbmc.eu <mailto:s...@zbmc.eu> as I have a mailbox of that name at 
> Gandi Internet and
> the zbmc.eu <http://zbmc.eu/> domain is hosted there. However zbmc.eu 
> <http://zbmc.eu/> has no SPF record:-
> 
>chris@esprimo$ host -t txt zbmc.eu <http://zbmc.eu/>
>zbmc.eu <http://zbmc.eu/> has no TXT record
> 
> Presumably Gandi Internet accepts the mail anyway because it's an
> authenticated SMTP connection.

Usually spf is not checked in that case but gandi may use internal
lists that define allowed envelope sender addresses for your sasl login,
so that you cannot impersonate other customers.
(https://www.postfix.org/postconf.5.html#smtpd_sender_login_maps)

> What I'm not clear about is what happens when the mail is sent onwards
> by the 'smarthost' at Gandi.  Does it change the envelope sender to

Send an email to yourself and have a look at the headers.
Some MTAs add received headers like "received by  for ".

Usually the envelope sender is not changed. It is possible that gandi
replaces it with your sasl login email address, although it's not common.

Not changing envelope senders is especially problematic with external
forwards (no smtp auth) and spf. That's why SRS (sender rewriting
scheme) has been invented, but it's not part of postfix and has to
be configured separately. I just mention it because you never know
what mailproviders do internally ...

See https://github.com/roehling/postsrsd

> something that an SPF record will be found for?  Or does it get sent
> on with the same envelope sender with the possibility that it will
> then get marked as spam or something?

It's not commmon but only gandi can tell ...

SPF can't fail for zbmc.eu because it does not have one. Considered
per se you're safe but gmail recently requires spf for forwards, so
for some it might be better to have one.

Best regards
Gerald

Re: A little help/clarification on what SPF does please

[Chris Green]

On Sat, Jan 14, 2023 at 05:03:15PM +0100, Gerald Galster wrote:
> > However most of the time I use my hosting at gandi.net to send my
> > E-Mail, so mail from ch...@isbd.co.uk originates on zbmc.eu, is
> > transferred by authenticated SMTP to mail.gandi.net and is sent on
> > from there to whatever its destination is.
> > 
> > As I understand it the SPF records for mail.gandi.net purely confirm
> > to a receiving mail server that the mail is coming from mail.gandi.net
> > and reverse DNS look-up confirms that it really is mail.gandi.net.
> > Have I got that right?  I.e. the fact that the mail's From: is not
> > connected in any way to the SPF record is irrelevant.  The SPF record
> > simply confirms the SMTP relay host's IP and that it is meant to be
> > relaying mail for that IP.
> 
> 
> Probably it's best to start with a simple smtp conversation.
> ch...@isbd.co.uk wants to send an email to b...@server.com:
> 
>[u...@client.com ~]$ nc server.com 25
>220 server.com ESMTP Postfix
>HELO client.com
>250 server.com
>MAIL FROM: 
>250 2.1.0 Ok
>RCPT TO: 
>250 2.1.5 Ok
>DATA
>354 End data with .
>From: 
>To: 
>Subject: test
>
>Hello,
>   
>this is a test.
>.
>250 2.0.0 Ok: queued as 4Nvabz5RcNabcHH3
>QUIT
>221 2.0.0 Bye
> 
> 
> SPF is about the envelope sender which is the address given at
> "MAIL FROM". The address at "From:" within the "DATA" stage is
> what your mailclient (Thunderbird, Outlook, ...) will display
> as the sender, which may be completely different and is not
> considered by SPF (or postfix).
> 
Yes, this is what I thought/assumed was going on, thank you for
confirming it.


> The envelope sender in our example is ch...@isbd.co.uk, so the
> receiving mailserver (server.com) will use this address for spf
> checks. Therefore it will look for a TXT record via DNS that
> contains spf info:
> 
> $ host -t txt isbd.co.uk
> isbd.co.uk descriptive text "v=spf1 include:_spf.mythic-beasts.com ~all"
> 
> This has an include option which requires another DNS query:
> 
> $ host -t txt _spf.mythic-beasts.com
> _spf.mythic-beasts.com descriptive text "v=spf1 ip4:93.93.130.89 ... ~all"
> 
> This returns ip addresses/networks that are allowed to send
> emails with senders @isbd.co.uk and a hint how to proceed
> (~all which means softfail or do not block right away).
> 
> Now we have that smtp connection from client.com to server.com and
> server.com will check if client.com's ip address is included in the
> list returned via DNS txt/spf query. If so, client.com is authorized
> to send mail in the name of @isbd.co.uk and the mail is accepted.
> Otherwise it could reject that mail (-all) or take that into account
> while checking spam (~all), ...
> 
> Given an email from ch...@isbd.co.uk, originating at zbmc.eu and sent
> via mail.gandi.net (authenticated smtp submission) to b...@server.com:
> 
> - server.com sees the ip address of mail.gandi.net (incoming connection)
> - server.com querys DNS for ch...@isbd.co.uk (host -t txt isbd.co.uk)
> - server.com cannot find the ip address of mail.gandi.net within spf
> - server.com might quarantine or classify your mail as spam because of ~all.
> 
> The solution would be to include mail.gandi.net's ips in the spf
> of isbd.co.uk (ip4, ip6, include, ...) so that it is authorized
> to send emails in the name of @isbd.co.uk.
> 
Brilliant explanation, thank you.

In reality the envelope sender for E-Mail sent out of my home server
is s...@zbmc.eu as I have a mailbox of that name at Gandi Internet and
the zbmc.eu domain is hosted there. However zbmc.eu has no SPF record:-

chris@esprimo$ host -t txt zbmc.eu
zbmc.eu has no TXT record

Presumably Gandi Internet accepts the mail anyway because it's an
authenticated SMTP connection.

What I'm not clear about is what happens when the mail is sent onwards
by the 'smarthost' at Gandi.  Does it change the envelope sender to
something that an SPF record will be found for?  Or does it get sent
on with the same envelope sender with the possibility that it will
then get marked as spam or something?

Anyway it seems I should add an SPF record for zbmc.eu at Gandi Internet
and I see they have a 'recommended' setting already there for me to use.

Thank you, it's all a bit clearer now.


-- 
Chris Green

Re: A little help/clarification on what SPF does please

[Chris Green]

On Sat, Jan 14, 2023 at 04:55:45PM +0100, Matus UHLAR - fantomas wrote:
> On 14.01.23 11:02, Chris Green wrote:
> >I use postfix on my home server and deliver mail by connecting to my
> >hosting providers' "smart host" using authenticated SMTP.
> >
> >My home system's hostname is zbmc.eu but I don't use that domain in my
> >E-Mail address, I use isbd.co.uk which domain is hosted at one of my
> >hosting providers (mythic-beasts.com).
> >
> >However most of the time I use my hosting at gandi.net to send my
> >E-Mail, so mail from ch...@isbd.co.uk originates on zbmc.eu, is
> >transferred by authenticated SMTP to mail.gandi.net and is sent on
> >from there to whatever its destination is.
> 
> >As I understand it the SPF records for mail.gandi.net purely confirm
> >to a receiving mail server that the mail is coming from mail.gandi.net
> >and reverse DNS look-up confirms that it really is mail.gandi.net.
> >Have I got that right? 
> 
> SPF records for mail.gandi.net are checked when someone sends mail from 
> @mail.gandi.net (you don't) or when server introduces itself as 
> mail.gandi.net (I assume yours introduces as zbmc.eu).
> 
Yes, my server's postfix is on zbmc.eu but since the connection to
Gandi is authenticated I assume Gandi will accept my E-Mails anyway.


> so, you should not care about SPF record for mail.gandi.net but for SPF 
> record for isbd.co.uk
> 
How does isbd.co.uk's SPF record get involved, it's hosted at Mythic
Beasts so never sees my E-Mails sent from zbmc.eu to Gandi.


> >I.e. the fact that the mail's From: is not
> >connected in any way to the SPF record is irrelevant. The SPF record
> >simply confirms the SMTP relay host's IP and that it is meant to be
> >relaying mail for that IP.
> 
> Header From: is irelevant with SPF.
> 
> Envelope from: is relevant and "isbd.co.uk" should have SPF record 
> including mail.gandi.net or whatever mail.gandi.net admins tell you to 
> include in SPF.
> 
As above, I don't see how isbd.co.uk's SPF record gets involved at
all, isbd.co.uk is hosted at mythic-beasts.com.  I have another
(unrelated) domain registered at Gandi (that I thus have a password
there that I use to autheticate the connection from zbmc.eu)

-- 
Chris Green

Re: A little help/clarification on what SPF does please

[Gerald Galster]

> However most of the time I use my hosting at gandi.net to send my
> E-Mail, so mail from ch...@isbd.co.uk originates on zbmc.eu, is
> transferred by authenticated SMTP to mail.gandi.net and is sent on
> from there to whatever its destination is.
> 
> As I understand it the SPF records for mail.gandi.net purely confirm
> to a receiving mail server that the mail is coming from mail.gandi.net
> and reverse DNS look-up confirms that it really is mail.gandi.net.
> Have I got that right?  I.e. the fact that the mail's From: is not
> connected in any way to the SPF record is irrelevant.  The SPF record
> simply confirms the SMTP relay host's IP and that it is meant to be
> relaying mail for that IP.


Probably it's best to start with a simple smtp conversation.
ch...@isbd.co.uk wants to send an email to b...@server.com:

   [u...@client.com ~]$ nc server.com 25
   220 server.com ESMTP Postfix
   HELO client.com
   250 server.com
   MAIL FROM: 
   250 2.1.0 Ok
   RCPT TO: 
   250 2.1.5 Ok
   DATA
   354 End data with .
   From: 
   To: 
   Subject: test
   
   Hello,
  
   this is a test.
   .
   250 2.0.0 Ok: queued as 4Nvabz5RcNabcHH3
   QUIT
   221 2.0.0 Bye


SPF is about the envelope sender which is the address given at
"MAIL FROM". The address at "From:" within the "DATA" stage is
what your mailclient (Thunderbird, Outlook, ...) will display
as the sender, which may be completely different and is not
considered by SPF (or postfix).

The envelope sender in our example is ch...@isbd.co.uk, so the
receiving mailserver (server.com) will use this address for spf
checks. Therefore it will look for a TXT record via DNS that
contains spf info:

$ host -t txt isbd.co.uk
isbd.co.uk descriptive text "v=spf1 include:_spf.mythic-beasts.com ~all"

This has an include option which requires another DNS query:

$ host -t txt _spf.mythic-beasts.com
_spf.mythic-beasts.com descriptive text "v=spf1 ip4:93.93.130.89 ... ~all"

This returns ip addresses/networks that are allowed to send
emails with senders @isbd.co.uk and a hint how to proceed
(~all which means softfail or do not block right away).

Now we have that smtp connection from client.com to server.com and
server.com will check if client.com's ip address is included in the
list returned via DNS txt/spf query. If so, client.com is authorized
to send mail in the name of @isbd.co.uk and the mail is accepted.
Otherwise it could reject that mail (-all) or take that into account
while checking spam (~all), ...

Given an email from ch...@isbd.co.uk, originating at zbmc.eu and sent
via mail.gandi.net (authenticated smtp submission) to b...@server.com:

- server.com sees the ip address of mail.gandi.net (incoming connection)
- server.com querys DNS for ch...@isbd.co.uk (host -t txt isbd.co.uk)
- server.com cannot find the ip address of mail.gandi.net within spf
- server.com might quarantine or classify your mail as spam because of ~all.

The solution would be to include mail.gandi.net's ips in the spf
of isbd.co.uk (ip4, ip6, include, ...) so that it is authorized
to send emails in the name of @isbd.co.uk.

Best regards
Gerald

Re: A little help/clarification on what SPF does please

[Matus UHLAR - fantomas]

On 14.01.23 11:02, Chris Green wrote:

I use postfix on my home server and deliver mail by connecting to my
hosting providers' "smart host" using authenticated SMTP.

My home system's hostname is zbmc.eu but I don't use that domain in my
E-Mail address, I use isbd.co.uk which domain is hosted at one of my
hosting providers (mythic-beasts.com).

However most of the time I use my hosting at gandi.net to send my
E-Mail, so mail from ch...@isbd.co.uk originates on zbmc.eu, is
transferred by authenticated SMTP to mail.gandi.net and is sent on
from there to whatever its destination is.



As I understand it the SPF records for mail.gandi.net purely confirm
to a receiving mail server that the mail is coming from mail.gandi.net
and reverse DNS look-up confirms that it really is mail.gandi.net.
Have I got that right? 


SPF records for mail.gandi.net are checked when someone sends mail from 
@mail.gandi.net (you don't) or when server introduces itself as 
mail.gandi.net (I assume yours introduces as zbmc.eu).


so, you should not care about SPF record for mail.gandi.net but for SPF 
record for isbd.co.uk



I.e. the fact that the mail's From: is not
connected in any way to the SPF record is irrelevant. The SPF record
simply confirms the SMTP relay host's IP and that it is meant to be
relaying mail for that IP.


Header From: is irelevant with SPF.

Envelope from: is relevant and "isbd.co.uk" should have SPF record 
including mail.gandi.net or whatever mail.gandi.net admins tell you to 
include in SPF.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
LSD will make your ECS screen display 16.7 million colors

A little help/clarification on what SPF does please

[Chris Green]

I use postfix on my home server and deliver mail by connecting to my
hosting providers' "smart host" using authenticated SMTP.

My home system's hostname is zbmc.eu but I don't use that domain in my
E-Mail address, I use isbd.co.uk which domain is hosted at one of my
hosting providers (mythic-beasts.com).

However most of the time I use my hosting at gandi.net to send my
E-Mail, so mail from ch...@isbd.co.uk originates on zbmc.eu, is
transferred by authenticated SMTP to mail.gandi.net and is sent on
from there to whatever its destination is.

As I understand it the SPF records for mail.gandi.net purely confirm
to a receiving mail server that the mail is coming from mail.gandi.net
and reverse DNS look-up confirms that it really is mail.gandi.net.
Have I got that right?  I.e. the fact that the mail's From: is not
connected in any way to the SPF record is irrelevant.  The SPF record
simply confirms the SMTP relay host's IP and that it is meant to be
relaying mail for that IP.

-- 
Chris Green

Re: What are the consequences of disabling chroot in all master services?

[Fourhundred Thecat]

This is not specific to postfix, but I cannot pass this opportunity to
remind/inform people that chroot is itself a potential source of
security vulnerabilities:

Please enjoy studying this beautiful local privilege escalation bug in
FreeBSD's ftpd, which was enabled by chroot jail:

https://www.zerodayinitiative.com/blog/2020/12/21/cve-2020-7468-turning-imprisonment-to-advantage-in-the-freebsd-ftpd-chroot-jail



> On 2022-12-13 00:17, Wietse Venema wrote:


The chroot feature makes post-exploitation of bugs (in Postfix,
libraries, etc) more more difficult, because there are fewer things
that an attacker can play with. For example no set-uid root programs,
no files in /proc, and no file system races against privileged programs.

One could argue that containers provide a minimized environment,
but that is not necessarily the case. The ones that do minimize
sometimes come with crippled libc implementations that introduce
problems of their own.

By the way it is rude to post html-only email to a mailing list.

Wietse

Re: What are the consequences of disabling chroot in all master services?

[postfix]

I apologize for the email being html-only, not my intention.
I'm having trouble getting Thunderbird to do this right as I have to manually 
do this for every outgoing email.



Tools > Settings > Composition > Sending Format > (Automatic || Only Plain Text)

and

Tools > Account Settings > Composition & Addressing > Compose messages in HTML 
format

Re: What are the consequences of disabling chroot in all master services?

[Sam]

I apologize for the email being html-only, not my intention. I'm having 
trouble getting Thunderbird to do this right as I have to manually do 
this for every outgoing email.


Can you please elaborate on what you mean with "problems of their own"? 
Anything specific comes to mind?


This whole movement to docker is a big set of trade-offs that I'm still 
researching.


Best regards,
Sam


On 13/12/2022 3:17 AM, Wietse Venema wrote:

Sam:
[ text/html is unsupported, treating like TEXT/PLAIN ]


?html style="direction: ltr;"?
   ?head?

 ?meta http-equiv="content-type" content="text/html; charset=UTF-8"?
 ?style id="bidiui-paragraph-margins" type="text/css"?body p { 
margin-bottom: 0cm; margin-top: 0pt; } ?/style?
   ?/head?
   ?body bidimailui-charset-is-forced="true" style="direction: ltr;"?
 ?p?Dear postfix experts:?/p?
 ?p??br?
 ?/p?
 ?p?While setting up postfix in a docker container, I have been
   getting the error "fatal: unknown service: smtp/tcp" when
   attempting to send an email. I investigated the issue, and it
   seems it has something to do with setting up chroot inside of
   docker container?/p?
 ?p??br?
 ?/p?
 ?p??a class="moz-txt-link-freetext" 
href="https://serverfault.com/questions/1052329/fatal-unknown-service-smtp-tcp-from-postfix-in-docker-using-start-fg"?https://serverfault.com/questions/1052329/fatal-unknown-service-smtp-tcp-from-postfix-in-docker-using-start-fg?/a??br?
 ?/p?
 ?p??br?
 ?/p?
 ?p?The easiest solution to this problem was to just disable chroot,
   which worked fine. I'm considering disabling chroot for all the
   postfix master services. Is this a bad move considering that
   postfix is running in a docker container? I would appreciate your
   insight into this.?/p?

The chroot feature makes post-exploitation of bugs (in Postfix,
libraries, etc) more more difficult, because there are fewer things
that an attacker can play with. For example no set-uid root programs,
no files in /proc, and no file system races against privileged programs.

One could argue that containers provide a minimized environment,
but that is not necessarily the case. The ones that do minimize
sometimes come with crippled libc implementations that introduce
problems of their own.

By the way it is rude to post html-only email to a mailing list.

Wietse

Re: What are the consequences of disabling chroot in all master services?

[Wietse Venema]

Sam:
[ text/html is unsupported, treating like TEXT/PLAIN ]

> ?html style="direction: ltr;"?
>   ?head?
> 
> ?meta http-equiv="content-type" content="text/html; charset=UTF-8"?
> ?style id="bidiui-paragraph-margins" type="text/css"?body p { 
> margin-bottom: 0cm; margin-top: 0pt; } ?/style?
>   ?/head?
>   ?body bidimailui-charset-is-forced="true" style="direction: ltr;"?
> ?p?Dear postfix experts:?/p?
> ?p??br?
> ?/p?
> ?p?While setting up postfix in a docker container, I have been
>   getting the error "fatal: unknown service: smtp/tcp" when
>   attempting to send an email. I investigated the issue, and it
>   seems it has something to do with setting up chroot inside of
>   docker container?/p?
> ?p??br?
> ?/p?
> ?p??a class="moz-txt-link-freetext" 
> href="https://serverfault.com/questions/1052329/fatal-unknown-service-smtp-tcp-from-postfix-in-docker-using-start-fg"?https://serverfault.com/questions/1052329/fatal-unknown-service-smtp-tcp-from-postfix-in-docker-using-start-fg?/a??br?
> ?/p?
> ?p??br?
> ?/p?
> ?p?The easiest solution to this problem was to just disable chroot,
>   which worked fine. I'm considering disabling chroot for all the
>   postfix master services. Is this a bad move considering that
>   postfix is running in a docker container? I would appreciate your
>   insight into this.?/p?

The chroot feature makes post-exploitation of bugs (in Postfix,
libraries, etc) more more difficult, because there are fewer things
that an attacker can play with. For example no set-uid root programs,
no files in /proc, and no file system races against privileged programs.

One could argue that containers provide a minimized environment,
but that is not necessarily the case. The ones that do minimize
sometimes come with crippled libc implementations that introduce
problems of their own.

By the way it is rude to post html-only email to a mailing list.

Wietse

What are the consequences of disabling chroot in all master services?

[Sam]

  
  
Dear postfix experts:


While setting up postfix in a docker container, I have been
  getting the error "fatal: unknown service: smtp/tcp" when
  attempting to send an email. I investigated the issue, and it
  seems it has something to do with setting up chroot inside of
  docker container


https://serverfault.com/questions/1052329/fatal-unknown-service-smtp-tcp-from-postfix-in-docker-using-start-fg



The easiest solution to this problem was to just disable chroot,
  which worked fine. I'm considering disabling chroot for all the
  postfix master services. Is this a bad move considering that
  postfix is running in a docker container? I would appreciate your
  insight into this.


Best regards,
Sam


  

Re: What happens if Postfix can't reach relay_host? - Postfix on laptops for system messages, with relay_host behind VPN

[Demi Marie Obenour]

On 11/15/22 17:56, r.barc...@habmalnefrage.de wrote:
> Wietse, Thanks so much for your quick and helpful response! It's an honor to 
> talk to you!
> 
> So my idea might only work, if I use the LAN IP address (e.g. 10.1.2.3) of 
> the internal mail server as relay_host.
> If Postfix can't connect to 10.1.2.3, it will probably retry mail relaying 
> for some days, configurable in maximal_queue_lifetime. That would be fine.
> 
> But it will NOT work, if I use an intranet FQDN (e.g. 
> internalmail.myintranet.corp), which can only be resolved, if the laptop is 
> in the LAN or VPN.
> Then emails get lost if they arrive while not in the LAN / VPN.
> 
> Or do you maybe have a different idea / suggestion about how to collect local 
> system emails from laptop clients?

Place the FQDN in /etc/hosts.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)


OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Re: What happens if Postfix can't reach relay_host? - Postfix on laptops for system messages, with relay_host behind VPN

[Viktor Dukhovni]

On Tue, Nov 15, 2022 at 11:56:22PM +0100, r.barc...@habmalnefrage.de wrote:

> So my idea might only work, if I use the LAN IP address (e.g.
> 10.1.2.3) of the internal mail server as relay_host.  If Postfix can't
> connect to 10.1.2.3, it will probably retry mail relaying for some
> days, configurable in maximal_queue_lifetime. That would be fine.
> 
> But it will NOT work, if I use an intranet FQDN (e.g.
> internalmail.myintranet.corp), which can only be resolved, if the
> laptop is in the LAN or VPN.  Then emails get lost if they arrive
> while not in the LAN / VPN.

Feel free to publish the name in the Internet-facing public DNS.  The IP
address can be 255.255.255.255, connection attempts to which will always
fail.  Of course this would have to appear only in the public DNS, and
not in the internal DNS.

-- 
Viktor.

Re: Re: What happens if Postfix can't reach relay_host? - Postfix on laptops for system messages, with relay_host behind VPN

[r . barclay]

Wietse, Thanks so much for your quick and helpful response! It's an honor to 
talk to you!

So my idea might only work, if I use the LAN IP address (e.g. 10.1.2.3) of the 
internal mail server as relay_host.
If Postfix can't connect to 10.1.2.3, it will probably retry mail relaying for 
some days, configurable in maximal_queue_lifetime. That would be fine.

But it will NOT work, if I use an intranet FQDN (e.g. 
internalmail.myintranet.corp), which can only be resolved, if the laptop is in 
the LAN or VPN.
Then emails get lost if they arrive while not in the LAN / VPN.

Or do you maybe have a different idea / suggestion about how to collect local 
system emails from laptop clients?


> Gesendet: Dienstag, 15. November 2022 um 22:45 Uhr
> Von: "Wietse Venema" 
> An: "Postfix users" 
> Betreff: Re: What happens if Postfix can't reach relay_host? - Postfix on 
> laptops for system messages, with relay_host behind VPN
>
> r.barc...@habmalnefrage.de:
> > This leads to my question: What happens to laptop-locally generated
> > / received emails, if their local Postfix can't reach the relay_host
> > in the intranet?
>
> The Postfx SMTP client will retry delivery after a soft error (host
> or port not reachable) until the message expires in the queue (by
> default, maximal_queue_lifetime = 5d).
>
> The Postfx SMTP client will NOT retry delivery after a hard error
> (host or domain does not exist in DNS, user does not exist on the
> remote SMP srever).
>
>   Wietse
>

Re: What happens if Postfix can't reach relay_host? - Postfix on laptops for system messages, with relay_host behind VPN

[Wietse Venema]

r.barc...@habmalnefrage.de:
> This leads to my question: What happens to laptop-locally generated
> / received emails, if their local Postfix can't reach the relay_host
> in the intranet?

The Postfx SMTP client will retry delivery after a soft error (host
or port not reachable) until the message expires in the queue (by
default, maximal_queue_lifetime = 5d).

The Postfx SMTP client will NOT retry delivery after a hard error
(host or domain does not exist in DNS, user does not exist on the
remote SMP srever).

Wietse

What happens if Postfix can't reach relay_host? - Postfix on laptops for system messages, with relay_host behind VPN

[r . barclay]

Hello,

I'd like to install Postfix on our Debian Linux laptops to handle local system 
messages / notifications, e.g. from "unattended-upgrades" (like "dnf-automatic" 
on RH-based Linuxes) or from failed cron jobs.

In our LAN we have an internal Postfix VM (not accessible from the Internet) 
that accepts any emails on port 25 and rewrites / replaces *any* recipient to a 
single admin mailbox.
We use this Postfix to collect all system messages from other VMs in the LAN. 
Each of them has Postfix installed, listening on 127.0.0.1 and with relay_host 
pointing to the central "collector" Postfix VM.

I'd like to have the laptops send their local system emails to this central 
admin mail server, as well.
As with the virtual machines, I'd install postfix and set the central mail 
collector Postfix as relay_host.

But the internal admin mail collector server is only accessible if the laptops 
are connected to our internal LAN or to our VPN (OpenVPN). It has an internal 
IP address from 10.0.0.0/8 range.

This leads to my question: What happens to laptop-locally generated / received 
emails, if their local Postfix can't reach the relay_host in the intranet?

1) Incoming emails on the laptop-local Postfix are not accepted and lost.
2) Laptop-local postfix will accept all incoming emails, independent of the 
state of relay_host, and try to deliver them to relay_host infinitely until 
relay_host can be reached?
3) ...?

Possible behavior (2) was what I'd like to achieve. Can this be configured? 
E.g. the retry interval?

Or would you suggest an entirely different approach to collect the local system 
emails from the laptops?

Thank you for your advice!
Reg

Re: What is happening here? (TLS Library Problem)

[Demi Marie Obenour]

On 6/10/22 08:55, Gerben Wierda wrote:
> 
>> On 10 Jun 2022, at 13:17, Wietse Venema  wrote:
>>
>> Wietse Venema:
>>> Gerben Wierda:
>>>>
>>>>> On 10 Jun 2022, at 02:30, Wietse Venema  wrote:
>>>>>
>>>>> Gerben Wierda:
>>>>>> What is happening here? (mail is delivered, I?m just curious)
>>>>>>
>>>>>> Jun 09 23:37:39 mail postfix/postscreen[4294]: CONNECT from 
>>>>>> [146.185.52.133]:10400 to [192.168.2.66]:25
>>>>>> Jun 09 23:37:45 mail postfix/postscreen[4294]: PASS NEW 
>>>>>> [146.185.52.133]:10400
>>>>>> Jun 09 23:37:45 mail smtp/smtpd[4296]: connect from 
>>>>>> ims-smtp133.persgroep-ops.net[146.185.52.133]
>>>>>> Jun 09 23:37:46 mail smtp/smtpd[4296]: CC868E75AA1E: 
>>>>>> client=ims-smtp133.persgroep-ops.net[146.185.52.133]
>>>>>> Jun 09 23:37:47 mail postfix/cleanup[4300]: CC868E75AA1E: 
>>>>>> message-id=<220609233739.sim_40lt1wa1poje3tjw6hnmtvk29xxj_ghn7vvejgut3cs3hljfekzafd9hipabzz8ro0vetlr2qj0j2ddp9oie2u%2bfuro...@ims-smtp133.persgroep-ops.net>
>>>>>> Jun 09 23:37:48 mail postfix/qmgr[8801]: CC868E75AA1E: 
>>>>>> from=, size=34628, nrcpt=1 (queue active)
>>>>>> Jun 09 23:37:48 mail smtp/smtpd[4296]: warning: TLS library problem: 
>>>>>> error:0A000126:SSL routines::unexpected eof while 
>>>>>> reading:ssl/record/rec_layer_s3.c:309:
>>>>>> Jun 09 23:37:48 mail smtp/smtpd[4296]: disconnect from 
>>>>>> ims-smtp133.persgroep-ops.net[146.185.52.133] ehlo=2 starttls=1 mail=1 
>>>>>> rcpt=1 data=1 commands=6
>>>>>>
>>>>>
>>>>> Did you look for 0A000126 with a web search engine?
>>>>
>>>> Yes. Searched on the entire error string as well.
>>>>
>>>> But that did not give me a clue.
>>>
>>> I got: OpenSSL 3 is more strict about clients that disconnect without
>>> fully following the protocol.
>>
>> Specifically, google 0A000126, the first result is PHP issue 8369a
> 
> Indeed. Interesting. I use duckduckgo (which relies on Bing afaik) and it 
> doesn’t find that.
> 
>> which links to https://github.com/openssl/openssl/issues/11378 
>> <https://github.com/openssl/openssl/issues/11378>. The
>> latter had a breaking fix, backed it out for OpenSSL 1.1.1, but
>> kept it in the branch that become OpenSSL 3.
> 
> So basically, the sender doesn’t properly close the SSL protocol, their MTA 
> is using an SSL which isn’t properly implemented.

My understanding is that a truncation attack is never a problem in
SMTP, as a premature EOF is always an SMTP error.  If this is in
fact the case, Postfix should set SSL_OP_IGNORE_UNEXPECTED_EOF to
tell OpenSSL to not treat a missing close_notify as an error.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: What is happening here? (TLS Library Problem)

[Viktor Dukhovni]

On Fri, Jun 10, 2022 at 02:55:24PM +0200, Gerben Wierda wrote:

> > which links to https://github.com/openssl/openssl/issues/11378 
> > . The
> > latter had a breaking fix, backed it out for OpenSSL 1.1.1, but
> > kept it in the branch that become OpenSSL 3.
> 
> So basically, the sender doesn’t properly close the SSL protocol,
> their MTA is using an SSL which isn’t properly implemented.

No, the sending application tears down the TLS connections abruptly,
without calling SSL_shutdown(), it is free to do so, and also the TCP
connection can terminate before the "close_notify" alert is received.

This is expected to happen some of the time, not an SSL library bug.
Many application protocols (e.g. SMTP) have some sort of explicit
message framing, and are resilient against message truncation at
connection close.

-- 
Viktor.

Re: What is happening here? (TLS Library Problem)

[Viktor Dukhovni]

On Fri, Jun 10, 2022 at 07:17:45AM -0400, Wietse Venema wrote:

> Specifically, google 0A000126, the first result is PHP issue 8369a
> which links to https://github.com/openssl/openssl/issues/11378. The
> latter had a breaking fix, backed it out for OpenSSL 1.1.1, but
> kept it in the branch that become OpenSSL 3.

I guess that makes for a bit of bitrot to handle in the Postfix TLS
layer.  We need to add "SSL_OP_IGNORE_UNEXPECTED_EOF" to the SSL options
when defined (OpenSSL 3.0 and later).

-- 
Viktor.

--- src/tls/tls.h
+++ src/tls/tls.h
@@ -387,6 +387,13 @@ extern void tls_param_init(void);
 #define SSL_OP_NO_TLSv1_3  0L  /* Noop */
 #endif
 
+/*
+ * Always used when defined, SMTP has no trucation attacks.
+ */
+#ifndef SSL_OP_IGNORE_UNEXPECTED_EOF
+#define SSL_OP_IGNORE_UNEXPECTED_EOF0L
+#endif
+
 #define TLS_KNOWN_PROTOCOLS \
( TLS_PROTOCOL_SSLv2 | TLS_PROTOCOL_SSLv3 | TLS_PROTOCOL_TLSv1 \
   | TLS_PROTOCOL_TLSv1_1 | TLS_PROTOCOL_TLSv1_2 | TLS_PROTOCOL_TLSv1_3 
)
@@ -403,7 +410,8 @@ extern void tls_param_init(void);
  * just exposed via hex codes or named elements of tls_ssl_options.
  */
 #define TLS_SSL_OP_MANAGED_BITS \
-   (SSL_OP_CIPHER_SERVER_PREFERENCE | TLS_SSL_OP_PROTOMASK(~0))
+   (SSL_OP_CIPHER_SERVER_PREFERENCE | SSL_OP_IGNORE_UNEXPECTED_EOF | \
+TLS_SSL_OP_PROTOMASK(~0))
 
 extern int tls_proto_mask_lims(const char *, int *, int *);
 
--- src/tls/tls_client.c
+++ src/tls/tls_client.c
@@ -713,6 +713,16 @@ TLS_APPL_STATE *tls_client_init(const 
TLS_CLIENT_INIT_PROPS *props)
 }
 tls_dane_digest_init(client_ctx, fpt_alg);
 
+/*
+ * Presently we use TLS only with SMTP where truncation attacks are not
+ * possible as a result of application framing.  If we ever use TLS in
+ * some other application protocol where truncation could be relevant,
+ * we'd need to disable truncation detection conditionally, or expcitly
+ * clear the option in that code path.
+ *
+ */
+off |= SSL_OP_IGNORE_UNEXPECTED_EOF;
+
 /*
  * Protocol selection is destination dependent, so we delay the protocol
  * selection options to the per-session SSL object.
--- src/tls/tls_server.c
+++ src/tls/tls_server.c
@@ -512,6 +512,16 @@ TLS_APPL_STATE *tls_server_init(const 
TLS_SERVER_INIT_PROPS *props)
 if (scache_timeout <= 0)
cachable = 0;
 
+/*
+ * Presently we use TLS only with SMTP where truncation attacks are not
+ * possible as a result of application framing.  If we ever use TLS in
+ * some other application protocol where truncation could be relevant,
+ * we'd need to disable truncation detection conditionally, or expcitly
+ * clear the option in that code path.
+ *
+ */
+off |= SSL_OP_IGNORE_UNEXPECTED_EOF;
+
 /*
  * Protocol work-arounds, OpenSSL version dependent.
  */

Re: What is happening here? (TLS Library Problem)

[Gerben Wierda]

> On 10 Jun 2022, at 13:17, Wietse Venema  wrote:
> 
> Wietse Venema:
>> Gerben Wierda:
>>> 
>>>> On 10 Jun 2022, at 02:30, Wietse Venema  wrote:
>>>> 
>>>> Gerben Wierda:
>>>>> What is happening here? (mail is delivered, I?m just curious)
>>>>> 
>>>>> Jun 09 23:37:39 mail postfix/postscreen[4294]: CONNECT from 
>>>>> [146.185.52.133]:10400 to [192.168.2.66]:25
>>>>> Jun 09 23:37:45 mail postfix/postscreen[4294]: PASS NEW 
>>>>> [146.185.52.133]:10400
>>>>> Jun 09 23:37:45 mail smtp/smtpd[4296]: connect from 
>>>>> ims-smtp133.persgroep-ops.net[146.185.52.133]
>>>>> Jun 09 23:37:46 mail smtp/smtpd[4296]: CC868E75AA1E: 
>>>>> client=ims-smtp133.persgroep-ops.net[146.185.52.133]
>>>>> Jun 09 23:37:47 mail postfix/cleanup[4300]: CC868E75AA1E: 
>>>>> message-id=<220609233739.sim_40lt1wa1poje3tjw6hnmtvk29xxj_ghn7vvejgut3cs3hljfekzafd9hipabzz8ro0vetlr2qj0j2ddp9oie2u%2bfuro...@ims-smtp133.persgroep-ops.net>
>>>>> Jun 09 23:37:48 mail postfix/qmgr[8801]: CC868E75AA1E: 
>>>>> from=, size=34628, nrcpt=1 (queue active)
>>>>> Jun 09 23:37:48 mail smtp/smtpd[4296]: warning: TLS library problem: 
>>>>> error:0A000126:SSL routines::unexpected eof while 
>>>>> reading:ssl/record/rec_layer_s3.c:309:
>>>>> Jun 09 23:37:48 mail smtp/smtpd[4296]: disconnect from 
>>>>> ims-smtp133.persgroep-ops.net[146.185.52.133] ehlo=2 starttls=1 mail=1 
>>>>> rcpt=1 data=1 commands=6
>>>>> 
>>>> 
>>>> Did you look for 0A000126 with a web search engine?
>>> 
>>> Yes. Searched on the entire error string as well.
>>> 
>>> But that did not give me a clue.
>> 
>> I got: OpenSSL 3 is more strict about clients that disconnect without
>> fully following the protocol.
> 
> Specifically, google 0A000126, the first result is PHP issue 8369a

Indeed. Interesting. I use duckduckgo (which relies on Bing afaik) and it 
doesn’t find that.

> which links to https://github.com/openssl/openssl/issues/11378 
> <https://github.com/openssl/openssl/issues/11378>. The
> latter had a breaking fix, backed it out for OpenSSL 1.1.1, but
> kept it in the branch that become OpenSSL 3.

So basically, the sender doesn’t properly close the SSL protocol, their MTA is 
using an SSL which isn’t properly implemented.

G

Re: What is happening here? (TLS Library Problem)

[Wietse Venema]

Wietse Venema:
> Gerben Wierda:
> > 
> > > On 10 Jun 2022, at 02:30, Wietse Venema  wrote:
> > > 
> > > Gerben Wierda:
> > >> What is happening here? (mail is delivered, I?m just curious)
> > >> 
> > >> Jun 09 23:37:39 mail postfix/postscreen[4294]: CONNECT from 
> > >> [146.185.52.133]:10400 to [192.168.2.66]:25
> > >> Jun 09 23:37:45 mail postfix/postscreen[4294]: PASS NEW 
> > >> [146.185.52.133]:10400
> > >> Jun 09 23:37:45 mail smtp/smtpd[4296]: connect from 
> > >> ims-smtp133.persgroep-ops.net[146.185.52.133]
> > >> Jun 09 23:37:46 mail smtp/smtpd[4296]: CC868E75AA1E: 
> > >> client=ims-smtp133.persgroep-ops.net[146.185.52.133]
> > >> Jun 09 23:37:47 mail postfix/cleanup[4300]: CC868E75AA1E: 
> > >> message-id=<220609233739.sim_40lt1wa1poje3tjw6hnmtvk29xxj_ghn7vvejgut3cs3hljfekzafd9hipabzz8ro0vetlr2qj0j2ddp9oie2u%2bfuro...@ims-smtp133.persgroep-ops.net>
> > >> Jun 09 23:37:48 mail postfix/qmgr[8801]: CC868E75AA1E: 
> > >> from=, size=34628, nrcpt=1 (queue active)
> > >> Jun 09 23:37:48 mail smtp/smtpd[4296]: warning: TLS library problem: 
> > >> error:0A000126:SSL routines::unexpected eof while 
> > >> reading:ssl/record/rec_layer_s3.c:309:
> > >> Jun 09 23:37:48 mail smtp/smtpd[4296]: disconnect from 
> > >> ims-smtp133.persgroep-ops.net[146.185.52.133] ehlo=2 starttls=1 mail=1 
> > >> rcpt=1 data=1 commands=6
> > >> 
> > > 
> > > Did you look for 0A000126 with a web search engine?
> > 
> > Yes. Searched on the entire error string as well.
> > 
> > But that did not give me a clue.
> 
> I got: OpenSSL 3 is more strict about clients that disconnect without
> fully following the protocol.

Specifically, google 0A000126, the first result is PHP issue 8369a
which links to https://github.com/openssl/openssl/issues/11378. The
latter had a breaking fix, backed it out for OpenSSL 1.1.1, but
kept it in the branch that become OpenSSL 3.

Wietse

Re: What is happening here? (TLS Library Problem)

[Wietse Venema]

Gerben Wierda:
> 
> > On 10 Jun 2022, at 02:30, Wietse Venema  wrote:
> > 
> > Gerben Wierda:
> >> What is happening here? (mail is delivered, I?m just curious)
> >> 
> >> Jun 09 23:37:39 mail postfix/postscreen[4294]: CONNECT from 
> >> [146.185.52.133]:10400 to [192.168.2.66]:25
> >> Jun 09 23:37:45 mail postfix/postscreen[4294]: PASS NEW 
> >> [146.185.52.133]:10400
> >> Jun 09 23:37:45 mail smtp/smtpd[4296]: connect from 
> >> ims-smtp133.persgroep-ops.net[146.185.52.133]
> >> Jun 09 23:37:46 mail smtp/smtpd[4296]: CC868E75AA1E: 
> >> client=ims-smtp133.persgroep-ops.net[146.185.52.133]
> >> Jun 09 23:37:47 mail postfix/cleanup[4300]: CC868E75AA1E: 
> >> message-id=<220609233739.sim_40lt1wa1poje3tjw6hnmtvk29xxj_ghn7vvejgut3cs3hljfekzafd9hipabzz8ro0vetlr2qj0j2ddp9oie2u%2bfuro...@ims-smtp133.persgroep-ops.net>
> >> Jun 09 23:37:48 mail postfix/qmgr[8801]: CC868E75AA1E: 
> >> from=, size=34628, nrcpt=1 (queue active)
> >> Jun 09 23:37:48 mail smtp/smtpd[4296]: warning: TLS library problem: 
> >> error:0A000126:SSL routines::unexpected eof while 
> >> reading:ssl/record/rec_layer_s3.c:309:
> >> Jun 09 23:37:48 mail smtp/smtpd[4296]: disconnect from 
> >> ims-smtp133.persgroep-ops.net[146.185.52.133] ehlo=2 starttls=1 mail=1 
> >> rcpt=1 data=1 commands=6
> >> 
> > 
> > Did you look for 0A000126 with a web search engine?
> 
> Yes. Searched on the entire error string as well.
> 
> But that did not give me a clue.

I got: OpenSSL 3 is more strict about clients that disconnect without
fully following the protocol.

Wietse

Re: What is happening here? (TLS Library Problem)

[Gerben Wierda]

> On 10 Jun 2022, at 02:30, Wietse Venema  wrote:
> 
> Gerben Wierda:
>> What is happening here? (mail is delivered, I?m just curious)
>> 
>> Jun 09 23:37:39 mail postfix/postscreen[4294]: CONNECT from 
>> [146.185.52.133]:10400 to [192.168.2.66]:25
>> Jun 09 23:37:45 mail postfix/postscreen[4294]: PASS NEW 
>> [146.185.52.133]:10400
>> Jun 09 23:37:45 mail smtp/smtpd[4296]: connect from 
>> ims-smtp133.persgroep-ops.net[146.185.52.133]
>> Jun 09 23:37:46 mail smtp/smtpd[4296]: CC868E75AA1E: 
>> client=ims-smtp133.persgroep-ops.net[146.185.52.133]
>> Jun 09 23:37:47 mail postfix/cleanup[4300]: CC868E75AA1E: 
>> message-id=<220609233739.sim_40lt1wa1poje3tjw6hnmtvk29xxj_ghn7vvejgut3cs3hljfekzafd9hipabzz8ro0vetlr2qj0j2ddp9oie2u%2bfuro...@ims-smtp133.persgroep-ops.net>
>> Jun 09 23:37:48 mail postfix/qmgr[8801]: CC868E75AA1E: 
>> from=, size=34628, nrcpt=1 (queue active)
>> Jun 09 23:37:48 mail smtp/smtpd[4296]: warning: TLS library problem: 
>> error:0A000126:SSL routines::unexpected eof while 
>> reading:ssl/record/rec_layer_s3.c:309:
>> Jun 09 23:37:48 mail smtp/smtpd[4296]: disconnect from 
>> ims-smtp133.persgroep-ops.net[146.185.52.133] ehlo=2 starttls=1 mail=1 
>> rcpt=1 data=1 commands=6
>> 
> 
> Did you look for 0A000126 with a web search engine?

Yes. Searched on the entire error string as well.

But that did not give me a clue.

G

Re: What is happening here? (TLS Library Problem)

[Viktor Dukhovni]

On Thu, Jun 09, 2022 at 11:58:23PM +0200, Gerben Wierda wrote:

> What is happening here? (mail is delivered, I’m just curious)

The client TLS connection ended before the client sent a TLS
close_notify.  The Postfix SMTP server attempted to read the client
connection, but saw an unexpected EOF.  Since this happened after "."
(successful message delivery), it is basically normal, and nothing to
worry about.  The client is a bit "rude" to disconnect abruptly after
message delivery, but this is basically harmless.

> 
> Jun 09 23:37:39 mail postfix/postscreen[4294]: CONNECT from 
> [146.185.52.133]:10400 to [192.168.2.66]:25
> Jun 09 23:37:45 mail postfix/postscreen[4294]: PASS NEW [146.185.52.133]:10400
> Jun 09 23:37:45 mail smtp/smtpd[4296]: connect from 
> ims-smtp133.persgroep-ops.net[146.185.52.133]
> Jun 09 23:37:46 mail smtp/smtpd[4296]: CC868E75AA1E: 
> client=ims-smtp133.persgroep-ops.net[146.185.52.133]
> Jun 09 23:37:47 mail postfix/cleanup[4300]: CC868E75AA1E: 
> message-id=<220609233739.sim_40lt1wa1poje3tjw6hnmtvk29xxj_ghn7vvejgut3cs3hljfekzafd9hipabzz8ro0vetlr2qj0j2ddp9oie2u%2bfuro...@ims-smtp133.persgroep-ops.net>
> Jun 09 23:37:48 mail postfix/qmgr[8801]: CC868E75AA1E: 
> from=, size=34628, nrcpt=1 (queue active)
> Jun 09 23:37:48 mail smtp/smtpd[4296]: warning: TLS library problem: 
> error:0A000126:SSL routines::unexpected eof while 
> reading:ssl/record/rec_layer_s3.c:309:
> Jun 09 23:37:48 mail smtp/smtpd[4296]: disconnect from 
> ims-smtp133.persgroep-ops.net[146.185.52.133] ehlo=2 starttls=1 mail=1 rcpt=1 
> data=1 commands=6

The client disconnected abruptly, indeed manifestly without sending
"QUIT", given the list of commands above (pre and post TLS EHLO, MAIL,
RCPT and DATA).

> main.cf on smtpd tls:
> 
> smtpd_tls_loglevel = 0

I'd recommend "1" rather than "0".

> smtpd_tls_security_level = may

This is correct.

> smtpd_enforce_tls = no
> smtpd_use_tls = yes

These are deprecated and redundant.

> smtpd_tls_exclude_ciphers = SSLv2, 3DES, aNULL, ADH, eNULL, EXPORT, LOW, MD5, 
> SEED, IDEA, RC2

No need to list "aNULL", "ADH", "eNULL", "EXPORT" or "LOW"

> smtpd_tls_eecdh_grade = ultra

This is a bad idea now, the "auto" setting is preferred since Postfix
3.2, and the parameter is ignored since Postfix 3.6, just drop this
from main.cf and use the default.

-- 
Viktor.

Re: What is happening here? (TLS Library Problem)

[Wietse Venema]

Gerben Wierda:
> What is happening here? (mail is delivered, I?m just curious)
> 
> Jun 09 23:37:39 mail postfix/postscreen[4294]: CONNECT from 
> [146.185.52.133]:10400 to [192.168.2.66]:25
> Jun 09 23:37:45 mail postfix/postscreen[4294]: PASS NEW [146.185.52.133]:10400
> Jun 09 23:37:45 mail smtp/smtpd[4296]: connect from 
> ims-smtp133.persgroep-ops.net[146.185.52.133]
> Jun 09 23:37:46 mail smtp/smtpd[4296]: CC868E75AA1E: 
> client=ims-smtp133.persgroep-ops.net[146.185.52.133]
> Jun 09 23:37:47 mail postfix/cleanup[4300]: CC868E75AA1E: 
> message-id=<220609233739.sim_40lt1wa1poje3tjw6hnmtvk29xxj_ghn7vvejgut3cs3hljfekzafd9hipabzz8ro0vetlr2qj0j2ddp9oie2u%2bfuro...@ims-smtp133.persgroep-ops.net>
> Jun 09 23:37:48 mail postfix/qmgr[8801]: CC868E75AA1E: 
> from=, size=34628, nrcpt=1 (queue active)
> Jun 09 23:37:48 mail smtp/smtpd[4296]: warning: TLS library problem: 
> error:0A000126:SSL routines::unexpected eof while 
> reading:ssl/record/rec_layer_s3.c:309:
> Jun 09 23:37:48 mail smtp/smtpd[4296]: disconnect from 
> ims-smtp133.persgroep-ops.net[146.185.52.133] ehlo=2 starttls=1 mail=1 rcpt=1 
> data=1 commands=6
> 

Did you look for 0A000126 with a web search engine?

Wietse

What is happening here? (TLS Library Problem)

[Gerben Wierda]

What is happening here? (mail is delivered, I’m just curious)

Jun 09 23:37:39 mail postfix/postscreen[4294]: CONNECT from 
[146.185.52.133]:10400 to [192.168.2.66]:25
Jun 09 23:37:45 mail postfix/postscreen[4294]: PASS NEW [146.185.52.133]:10400
Jun 09 23:37:45 mail smtp/smtpd[4296]: connect from 
ims-smtp133.persgroep-ops.net[146.185.52.133]
Jun 09 23:37:46 mail smtp/smtpd[4296]: CC868E75AA1E: 
client=ims-smtp133.persgroep-ops.net[146.185.52.133]
Jun 09 23:37:47 mail postfix/cleanup[4300]: CC868E75AA1E: 
message-id=<220609233739.sim_40lt1wa1poje3tjw6hnmtvk29xxj_ghn7vvejgut3cs3hljfekzafd9hipabzz8ro0vetlr2qj0j2ddp9oie2u%2bfuro...@ims-smtp133.persgroep-ops.net>
Jun 09 23:37:48 mail postfix/qmgr[8801]: CC868E75AA1E: 
from=, size=34628, nrcpt=1 (queue active)
Jun 09 23:37:48 mail smtp/smtpd[4296]: warning: TLS library problem: 
error:0A000126:SSL routines::unexpected eof while 
reading:ssl/record/rec_layer_s3.c:309:
Jun 09 23:37:48 mail smtp/smtpd[4296]: disconnect from 
ims-smtp133.persgroep-ops.net[146.185.52.133] ehlo=2 starttls=1 mail=1 rcpt=1 
data=1 commands=6

main.cf on smtpd tls:

smtpd_tls_loglevel = 0
smtpd_tls_security_level = may
smtpd_enforce_tls = no
smtpd_use_tls = yes
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = medium
smtpd_tls_exclude_ciphers = SSLv2, 3DES, aNULL, ADH, eNULL, EXPORT, LOW, MD5, 
SEED, IDEA, RC2
smtpd_tls_cert_file = /opt/local/etc/letsencrypt/live/www.rna.nl/fullchain.pem
smtpd_tls_key_file = /opt/local/etc/letsencrypt/live/www.rna.nl/privkey.pem
smtpd_tls_dh1024_param_file=${data_directory}/dh2048.pem
smtpd_tls_eecdh_grade = ultra
smtpd_tls_auth_only = yes
smtpd_sasl_tls_security_options = noanonymous, noplaintext
smtpd_tls_received_header = yes

Note: I suspect my main.cf hasn’t been updated enough for the LCM actions I’ve 
done on postfix itself.

Gerben

Re: What does AW mean - was - Re: AW: RSA and ECDSA - warning: No certs for key at index 1

[Bernardo Reino]

On 31/05/2022 16:38, Jaroslaw Rafa wrote:

Dnia 31.05.2022 o godz. 22:18:56 Bret Busby pisze:


I keep seeing "AW" prepended to message subjects and I have no idea
of what it means.

What does it mean?


Some MUA authors falsely assume that the string "Re:" at the beginning of
subject of a reply is a shortcut for the English word "Reply", and translate
that string. "AW" is an example of such translation. It is a shortcut for
German word "Antwort", which means "Reply".

It is a completely wrong concept, but you can still find it in some MUAs.
"Re:" actually comes from the Latin phrase "in re," which means "in the
matter of", so it should never be translated.


I'd just add that Outlook is apparently the main perpetrator here, 
unless you enable/disable some hard-to-find (for the average user 
anyway) option to enable/disable localized headers or such.


Plus most German web-mail systems (gmx) apparently do that too, which is 
also a pity..

Re: What does AW mean - was - Re: AW: RSA and ECDSA - warning: No certs for key at index 1

[Jaroslaw Rafa]

Dnia 31.05.2022 o godz. 22:18:56 Bret Busby pisze:
> 
> I keep seeing "AW" prepended to message subjects and I have no idea
> of what it means.
> 
> What does it mean?

Some MUA authors falsely assume that the string "Re:" at the beginning of
subject of a reply is a shortcut for the English word "Reply", and translate
that string. "AW" is an example of such translation. It is a shortcut for
German word "Antwort", which means "Reply".

It is a completely wrong concept, but you can still find it in some MUAs.
"Re:" actually comes from the Latin phrase "in re," which means "in the
matter of", so it should never be translated.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: [External] What does AW mean - was - Re: AW: RSA and ECDSA - warning: No certs for key at index 1

[Kevin A. McGrail]

On 5/31/2022 10:18 AM, Bret Busby wrote:
I keep seeing "AW" prepended to message subjects and I have no idea of 
what it means.


What does it mean?

I believe it's the German equivalent for re: 
(https://en.wikipedia.org/wiki/List_of_email_subject_abbreviations) as 
in Regarding.


Regards,
KAM

What does AW mean - was - Re: AW: RSA and ECDSA - warning: No certs for key at index 1

[Bret Busby]

On 31/5/22 7:05 pm, Maurizio Caloro wrote:


Hello.

I keep seeing "AW" prepended to message subjects and I have no idea of 
what it means.


What does it mean?

--
Bret Busby
Armadale
West Australia
(UTC+0800)
..

Re: Alias and user same name: What happens?

[Viktor Dukhovni]

On Tue, May 10, 2022 at 09:03:59AM +0200, lutz.niede...@gmx.net wrote:

> userA and userB are real local users with a mailbox. What happens in
> case of an aliases line like this:
> 
> userA:   userA, userB
> 
> Does it deliver to local users userA and userB? I assume that it does not 
> loop.

Yes, if all goes well, and "$myorigin" is listed in "$mydestination",
then the message is delivered to both users without a loop.

However, if one delivery soft-fails (mailbox full, ...), but the other
succeeds, then the behaviour is suboptimal, because both will be
retried later (there's only one queue-file recipient with local
aliases(5)), and the "good" recipient will get multiple copies of
the message.

For this and other reasons, it is best to avoid local aliases(5) as much
as possible, and use virtual(5) aliases instead.

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

transport
localhost.localdomain   local

virtual:
userA   userA@localhost.localdomain, userB@localhost.localdomain

Use local aliases(5) solely for ":include:" mailing lists, other lists
with an "owner-" alias and perhaps "|command" aliases (that will run as
"nobody").

-- 
Viktor.

Alias and user same name: What happens?

[lutz . niederer]

Hi,

userA and userB are real local users with a mailbox. What happens in case of an 
aliases line like this:

userA:   userA, userB

Does it deliver to local users userA and userB? I assume that it does not loop.

Thanks & cheers!
-lutzn

Re: for what file need to run postmap

[Viktor Dukhovni]

On Wed, Apr 27, 2022 at 06:12:53PM +0800, al...@coakmail.com wrote:

> I guess this kind of file doesn't need to run postmap against it?
> 
>  virtual_mailbox_domains = /etc/postfix/virtual_mailbox_domains
>  virtual_alias_domains = /etc/postfix/virtual_alias_domains

These are "match lists", the syntax allows a list of literal values, or
a file with one value per line, or a table with keys and ignored values.

Tables types that are "indexed files" (hash, btree, cdb, lmdb, ...)
don't use the source file directly, instead a "database" file is
created from the source file in order to support more efficient
lookup than linear search.

Table syntax always specifies the table type "type:table", and
postmap is needed for the "types" that construct "indexed file"
representations of the data.

> But this file need postmap after the modification?
> 
>  virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps

This parameter requires lookup tables, and does not support a list of
literal values.  The values associated with the lookup keys are
meaningful and not ignored.

-- 
Viktor.

Re: for what file need to run postmap

[Wietse Venema]

al...@coakmail.com:
> Hello
> 
> I guess this kind of file doesn't need to run postmap against it?

All tables that are created with the postmap command, as described
in https://www.postfix.org/DATABASE_README.html#types

Wietse

Re: for what file need to run postmap

[Aban Dokht]

Hello Alice,

check out:

http://www.postfix.org/postconf.5.html

For every parameter you'll find the expected values, e.g. for virtual_alias_maps , which 
expects a "lookup table".
If you use hash:*, you must postmap this file.





al...@coakmail.com wrote:

Hello

I guess this kind of file doesn't need to run postmap against it?

  virtual_mailbox_domains = /etc/postfix/virtual_mailbox_domains
  virtual_alias_domains = /etc/postfix/virtual_alias_domains

But this file need postmap after the modification?

  virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps

please give an explanation. thank you



Regards
Aban

--
 Aban Dokht   aban.do...@abando.de
--

for what file need to run postmap

[alice]

Hello

I guess this kind of file doesn't need to run postmap against it?

 virtual_mailbox_domains = /etc/postfix/virtual_mailbox_domains
 virtual_alias_domains = /etc/postfix/virtual_alias_domains

But this file need postmap after the modification?

 virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps

please give an explanation. thank you

Re: I got an email from "myself?" what the heck!

[Peter]

On 25/10/21 2:59 pm, Thomas Anderson wrote:

Here is a clean email:

Received: from example.net (unknown [192.168.1.10])
by mail.example.com (Postfix) with ESMTPSA id D7C3F1980059
for; Mon, 25 Oct 2021 03:42:29 +0200 (CEST)

Here is a non-clean email:

Received: by mail.example.com (Postfix, from userid 1005)
id F1E621982CA9; Sun, 13 Jun 2021 15:32:28 +0200 (CEST)


This looks legitimate, and generated by the sendmail binary on your 
system.  Check your Postfix logs for a pickup entry that matches that 
queue id (you can grep for F1E621982CA9 and then look back for the 
pickup line).  It likely indicates some sort of spam coming through a 
web form on your system, like on a php script, fix the web form to make 
it harder for spammers to use.



Peter

Re: I got an email from "myself?" what the heck!

[Wietse Venema]

Benny Pedersen:
> On 2021-10-25 07:11, Thomas Anderson wrote:
> > The IP it came from was outside my network.
> 
> you can reject all evevelope senders if its claims its your domain in 
> port 25, you will never send it there, never as never, spf is just a 
> global world protection not needed for postfix to make thar policy

# Disallow sen...@example.com (and subdomains) from strangers.
main.cf:
smtpd_sender_restrictions = 
inline:{{ example.com = permit_mynetworks, reject }}

# Allow from authenticated mail user agents.
master.cf:
submission ...
-o smtpd_sender_restrictions=
...
smtps ...
-o smtpd_sender_restrictions=
...

It's not the default because historically, some mailing lists did
not reset the envelope sender, and your postings to such a list
could have your own envelope sender address.

Wietse

Re: I got an email from "myself?" what the heck!

[Benny Pedersen]

On 2021-10-25 07:11, Thomas Anderson wrote:

The IP it came from was outside my network.


you can reject all evevelope senders if its claims its your domain in 
port 25, you will never send it there, never as never, spf is just a 
global world protection not needed for postfix to make thar policy

Re: I got an email from "myself?" what the heck!

[Richard Salts]

On 25/10/2021 4:11 pm, Thomas Anderson wrote:

The IP it came from was outside my network.

I think it's just a spoofing email. I had not actually seen on, so 
that raised my alarm, but I think it's ok. I need to go through and 
make sure my SFP and DMARC are sound. I just checked my DKIM couple 
days ago, so that's good.


Keep in mind that even with SPF, DKIM and DMARC in place there is still 
the possibility of legitimate emails that your users have sent coming 
back to you and being unable to authenticate them as such.


For example a user is a member of a mailing list that receiving a copy 
of their post where the mailing list has altered the body or a header 
which you've signed (the postfix mailing list takes pains not to damage 
DKIM signatures but does use the longstanding convention of adding a 
"Sender" header with the list address. If you were to sign an existing 
"Sender" header or sign the non-existence of the "Sender" header then 
the original DKIM signature would break even here. Other mailing lists 
are much worse, breaking the body with a footer and/or tagging the 
subject with the list name)


The converse is also true in some cases, that a message can appear as a 
valid DKIM signed message from an authorized source while being 
malicious. There are certain things to watch out for as covered in 
https://noxxi.de/research/breaking-dkim-on-purpose-and-by-chance.html 
which lets an unauthorized 3rd party take a previous email from a 
particular sender and convince many DKIM validators that it's legitimate 
on that basis while also adding their own payload which gets displayed 
to the recipient.





Thanks for the replies.

On 10/25/21 4:59 AM, post...@ptld.com wrote:
My concern is that the email APPEARED to come from me! I was listed 
as the sender.


Any email server can send any email claiming to come from anyone. 
DKIM Signatures and SPF records working together with DMARC provides 
a way to verify if a sending email server is authorized to send an 
email on behalf of the address used. If your server is not using, 
checking and validating DMARC then anyone can easily send you or send 
someone else an email claiming to be from you. Doesn't mean they 
compromised or got inside of your system or account. They just 
slapped your name on the "outside of the envelope".


Was the connecting client server IP your servers IP? The IP of the 
connecting client in the logs is who really sent the message, not the 
arbitrary email address slapped in the Envelope-From, From header or 
Sender header.

Re: I got an email from "myself?" what the heck!

[Thomas Anderson]

The IP it came from was outside my network.

I think it's just a spoofing email. I had not actually seen on, so that 
raised my alarm, but I think it's ok. I need to go through and make sure 
my SFP and DMARC are sound. I just checked my DKIM couple days ago, so 
that's good.


Thanks for the replies.

On 10/25/21 4:59 AM, post...@ptld.com wrote:
My concern is that the email APPEARED to come from me! I was listed 
as the sender.


Any email server can send any email claiming to come from anyone. DKIM 
Signatures and SPF records working together with DMARC provides a way 
to verify if a sending email server is authorized to send an email on 
behalf of the address used. If your server is not using, checking and 
validating DMARC then anyone can easily send you or send someone else 
an email claiming to be from you. Doesn't mean they compromised or got 
inside of your system or account. They just slapped your name on the 
"outside of the envelope".


Was the connecting client server IP your servers IP? The IP of the 
connecting client in the logs is who really sent the message, not the 
arbitrary email address slapped in the Envelope-From, From header or 
Sender header.

Re: I got an email from "myself?" what the heck!

[postfix]

My concern is that the email APPEARED to come from me! I was listed as 
the sender.


Any email server can send any email claiming to come from anyone. DKIM 
Signatures and SPF records working together with DMARC provides a way to 
verify if a sending email server is authorized to send an email on 
behalf of the address used. If your server is not using, checking and 
validating DMARC then anyone can easily send you or send someone else an 
email claiming to be from you. Doesn't mean they compromised or got 
inside of your system or account. They just slapped your name on the 
"outside of the envelope".


Was the connecting client server IP your servers IP? The IP of the 
connecting client in the logs is who really sent the message, not the 
arbitrary email address slapped in the Envelope-From, From header or 
Sender header.

I got an email from "myself?" what the heck!

[Thomas Anderson]

Yes, it was spam, and it was caught by SpamAssassin. It was some bitcoin 
plot or something.


The characters were not anything I could read, and the few I could make 
out were of a south-east asian descent.


My concern is that the email APPEARED to come from me! I was listed as 
the sender.


I examined the message source, against other valid emails sent by this 
user, and there wasn't anything that I could clearly see as the reason 
or how this was done. I have checked against password hacked sites, and 
the email password of the user doesn't seem to be compromised. I have 
only received maybe 2-3 of these emails in the past year, and only on 
this user--all caught by spam assassin.


I guess I am concerned, because I don't how this happened.

Here is my best stab at where the problem could be.

Here is a clean email:

Received: from example.net (unknown [192.168.1.10])
by mail.example.com (Postfix) with ESMTPSA id D7C3F1980059
for ; Mon, 25 Oct 2021 03:42:29 +0200 (CEST)

Here is a non-clean email:

Received: by mail.example.com (Postfix, from userid 1005)
id F1E621982CA9; Sun, 13 Jun 2021 15:32:28 +0200 (CEST)

Just trying to figure out if my system is compromised, thanks!

Re: What is the proper value in solrconfig.xml for dovecot?

[Jan Ceuleers]

On 19/04/2021 02:15, Steve Dondley wrote:
> I'm looking at config documentation for solr on dovecot:
> https://doc.dovecot.org/configuration_manual/fts/solr/
>
> In the suggested solrconfig.xml file
> (https://raw.githubusercontent.com/dovecot/core/master/doc/solr-config-7.7.0.xml),
> it has the following line:
>
> 7.7.0
>
> I'm running solr version 8.8.1, however. I'm wondering if I should
> change this line to:
>
> 8.8.1
>
> Things seems to work fine with the 7.7.0 value but there is a comment
> in the config file that says:
>
>   
>
> I'm not familiar with Lucene or Solr so I'm uncertain as to what to
> set this to.
>
> Thanks.

Presumably you meant to ask this on a dovecot-related mailing list?

What is the proper value in solrconfig.xml for dovecot?

[Steve Dondley]

I'm looking at config documentation for solr on dovecot: 
https://doc.dovecot.org/configuration_manual/fts/solr/


In the suggested solrconfig.xml file 
(https://raw.githubusercontent.com/dovecot/core/master/doc/solr-config-7.7.0.xml), 
it has the following line:


7.7.0

I'm running solr version 8.8.1, however. I'm wondering if I should 
change this line to:


8.8.1

Things seems to work fine with the 7.7.0 value but there is a comment in 
the config file that says:


  

I'm not familiar with Lucene or Solr so I'm uncertain as to what to set 
this to.


Thanks.

Re: What am I missing here?

[Antonio Leding]

FWIW, I had very similar issues and implemented fail2ban with very tight 
parameters to essentially block offensive probing hosts.  I went from 
something around 75k probes per month down to less than 50.


Also, out of respect for our counterparts on this PF dedicated mailer, 
feel free to ping me directly to discuss F2B.


- Tony -

- - -

On 15 Mar 2021, at 13:23, Wietse Venema wrote:


Bill Cole:

On 15 Mar 2021, at 12:17, Viktor Dukhovni wrote:


You've enabled SASL with dovecot as a backend.  You could limit this
to
port 587 (enable SASL via master.cf only for the submission 
service),
and require TLS there.  It'll probably still get probed.  That's 
life

on the public Internet.


Not only "could" but for most systems, SHOULD. The primary purpose 
would
be to reduce your attack surface. You will still get some auth 
attempts

on the port 25 service, but far less than with SASL enabled and of
course there is zero potential for those attacks ever working. Since
auth attacks have mostly graduated from "brute force" (i.e. 
random-ish
guessing) to "credential stuffing" (trying user+password pairs known 
to

work somewhere else) it has become important to limit the ways
successful authentication can work to only what is necessary. In 
2021,
no one should need to do authenticated mail submission on port 25. 
You

also can gain simpler and clearer configuration for other sorts of
policy enforcement (e.g. spam control) by not having any need to make
exceptions for submission on port 25 (e.g. exemptions from  DNSBL 
and/or

spam filters for trusted networks.)


I agree. Don't enabls SASL AUTH (or any MUA-specific features) on
the MTA service (port 25), and Do give the Postfix submission and
smtps services their own set of smtpd_mumble_restrictions.

Wietse

Re: What am I missing here?

[Wietse Venema]

Bill Cole:
> On 15 Mar 2021, at 12:17, Viktor Dukhovni wrote:
> 
> > You've enabled SASL with dovecot as a backend.  You could limit this 
> > to
> > port 587 (enable SASL via master.cf only for the submission service),
> > and require TLS there.  It'll probably still get probed.  That's life
> > on the public Internet.
> 
> Not only "could" but for most systems, SHOULD. The primary purpose would 
> be to reduce your attack surface. You will still get some auth attempts 
> on the port 25 service, but far less than with SASL enabled and of 
> course there is zero potential for those attacks ever working. Since 
> auth attacks have mostly graduated from "brute force" (i.e. random-ish 
> guessing) to "credential stuffing" (trying user+password pairs known to 
> work somewhere else) it has become important to limit the ways 
> successful authentication can work to only what is necessary. In 2021, 
> no one should need to do authenticated mail submission on port 25. You 
> also can gain simpler and clearer configuration for other sorts of 
> policy enforcement (e.g. spam control) by not having any need to make 
> exceptions for submission on port 25 (e.g. exemptions from  DNSBL and/or 
> spam filters for trusted networks.)

I agree. Don't enabls SASL AUTH (or any MUA-specific features) on
the MTA service (port 25), and Do give the Postfix submission and
smtps services their own set of smtpd_mumble_restrictions.

Wietse

Re: What am I missing here?

[Bill Cole]

On 15 Mar 2021, at 12:17, Viktor Dukhovni wrote:

You've enabled SASL with dovecot as a backend.  You could limit this 
to

port 587 (enable SASL via master.cf only for the submission service),
and require TLS there.  It'll probably still get probed.  That's life
on the public Internet.


Not only "could" but for most systems, SHOULD. The primary purpose would 
be to reduce your attack surface. You will still get some auth attempts 
on the port 25 service, but far less than with SASL enabled and of 
course there is zero potential for those attacks ever working. Since 
auth attacks have mostly graduated from "brute force" (i.e. random-ish 
guessing) to "credential stuffing" (trying user+password pairs known to 
work somewhere else) it has become important to limit the ways 
successful authentication can work to only what is necessary. In 2021, 
no one should need to do authenticated mail submission on port 25. You 
also can gain simpler and clearer configuration for other sorts of 
policy enforcement (e.g. spam control) by not having any need to make 
exceptions for submission on port 25 (e.g. exemptions from  DNSBL and/or 
spam filters for trusted networks.)




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: What am I missing here?

[Viktor Dukhovni]

On Mon, Mar 15, 2021 at 09:07:43AM -0700, Stephen Satchell wrote:

> Problem:  someone is probing my Ubuntu 20.04 LTS based mail server. 
> Along with SSH attacks (now mitigated) I had a number of log messages 
> saying auth failures in Dovecot.  When I traced packets generating these 
> messages, I found that the packets were being directed to 25/tcp -- Postfix.

This is expected.

> > smtpd_sasl_auth_enable = yes
> > smtpd_sasl_path = private/auth
> > smtpd_sasl_type = dovecot

You've enabled SASL with dovecot as a backend.  You could limit this to
port 587 (enable SASL via master.cf only for the submission service),
and require TLS there.  It'll probably still get probed.  That's life
on the public Internet.

If you turn on DNSSEC and DANE, one of the SMTP probes (about one per
day) will even come from my DANE survey bot:

https://stats.dnssec-tools.org/
https://stats.dnssec-tools.org/about.html

but it only connects to port 25, and only for MX hosts with DANE TLSA
records.

-- 
Viktor.

What am I missing here?

[Stephen Satchell]

Problem:  someone is probing my Ubuntu 20.04 LTS based mail server. 
Along with SSH attacks (now mitigated) I had a number of log messages 
saying auth failures in Dovecot.  When I traced packets generating these 
messages, I found that the packets were being directed to 25/tcp -- Postfix.


I know I'm doing something stupid.  Or not doing something stupid. 
Pointers?


All mailboxes have associated entries in /etc/passwd, with certain role 
accounts redirected to admin in /etc/aliases



satch@mail:~$ postconf local_recipient_maps
local_recipient_maps = proxy:unix:passwd.byname $alias_maps



$ postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
compatibility_level = 2
default_destination_concurrency_limit = 5
disable_vrfy_command = yes
header_checks = regexp:/etc/postfix/header_checks
header_size_limit = 5
inet_interfaces = all
inet_protocols = ipv4
mailbox_size_limit = 5120
mime_header_checks = $header_checks
mydestination = satchell.net
myhostname = mail.satchell.net
mynetworks = 127.0.0.0/8, 10.1.1.0/24
myorigin = satchell.net
nested_header_checks =
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_client_connection_count_limit = 25
smtpd_data_restrictions = reject_multi_recipient_bounce permit
smtpd_etrn_restrictions = reject
smtpd_helo_required = yes
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, 
reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.satchell.net/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.satchell.net/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
virtual_transport = lmtp:unix:private/dovecot-lmtp


Sample log entries:


Mar 14 18:41:12 mail auth: pam_unix(dovecot:auth): authentication failure; 
logname= uid=0 euid=0 tty=dovecot ruser=a...@satchell.net rhost=45.144.225.181
Mar 12 10:12:25 mail auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=scan rhost=176.111.173.48 
Mar 12 10:14:11 mail auth: pam_unix(dovecot:auth): check pass; user unknown
Mar 12 10:14:11 mail auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=f...@q0z.net rhost=193.169.255.72 
Mar 12 10:18:45 mail auth: pam_unix(dovecot:auth): check pass; user unknown
Mar 12 10:18:45 mail auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=marketing rhost=193.169.252.8 
Mar 12 17:58:24 mail auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=spamfilter rhost=218.73.134.32  user=spamfilter

Mar 12 17:59:08 mail auth: pam_unix(dovecot:auth): check pass; user unknown
Mar 12 17:59:08 mail auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=spamfil...@satchell.net rhost=218.73.134.32 
Mar 12 17:59:23 mail auth: pam_unix(dovecot:auth): check pass; user unknown
Mar 12 17:59:23 mail auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=spamfil...@satchell.net rhost=218.73.134.32 


(Note: this mail server is not set up yet to process mail to domain 
q0z.net yet.  I'll be following the documentation for "virtual" when it 
comes time to add entries for this domain.)


"spamfilter" is an account in /etc/passwd.

And the PostFix files:


root@mail:/etc/postfix# tree .
.
├── dynamicmaps.cfcat 
├── dynamicmaps.cf.d

├── header_checks
├── main.cf
├── main.cf.bak
├── main.cf.proto
├── makedefs.out -> /usr/share/postfix/makedefs.out
├── master.cf
├── master.cf.proto
├── postfix-files
├── postfix-files.d
├── postfix-script
├── post-install
└── sasl



root@mail:/etc# tree . | grep aliases
├── aliases
├── aliases.db
│   │   ├── 30-cjk-aliases.conf
│   │   ├── 30-metric-aliases.conf
│   │   ├── 30-cjk-aliases.conf -> ../conf.avail/30-cjk-aliases.conf
│   │   ├── 30-metric-aliases.conf -> ../conf.avail/30-metric-aliases.conf

Re: What is the right way to update a postfix sqlite database?

[Wietse Venema]

Ron Garret:
> WAL mode was previously discussed here:
> 
> https://marc.info/?l=postfix-users=160096626120296=2

In other words the reader requires database write permission. I
fully agree that is not desirable.

> The upshot appears to be this, at least as things currently stand:
> 
> > DO NOT use SQLite as a Postfix backend database updated live while
> > Postfix is running.

Just like other file-based databases, the safest update
approach is

create a temporary db file
rename the temporary db file

The exception is LMDB which can handle concurrent reads and writes
without reader permission errors, busy errors, and so on.

So, who adds a busy timer to the sqlite client?

Wietse

Re: What is the right way to update a postfix sqlite database?

[Ron Garret]

On Feb 23, 2021, at 11:41 AM, Richard Damon  wrote:

> On 2/23/21 2:18 PM, Wietse Venema wrote:
>> Ron Garret:
 If we take this route, then there needs to be a new field in the
 Postfix sqlite config file that controls the time limit.
>>> Not necessarily.  You could just hard-code a reasonable value (like
>>> 1 second), or make it a #define so you need a recompile to change
>>> it.  That?s sub-optimal, obviously, but still a major improvement
>>> over the current situation for very little effort and no down-side
>>> that I can see.
>> The limit should be configurable. It takes:
>> 
>> - one line of code to define a C variable, 
>> 
>> - one line of code to read its value from an sqlite_table configuration
>>  file (or to use a documented default value),
>> 
>> - a few lines of text to document the new field in the sqlite_table manpage.
>> 
>>  Wietse
> 
> One thng to look at is WAL mode. WAL mode increases the cost of writes
> to the database, as all writes become two stage, first to the WAL
> journal, and then flushed to the main database (called A checkpoint),
> and reads reads can get a bit more expensive if the second stage of the
> write gets delayed by long accesses (but that may not be an issue with
> postfix).
> 
> In exchange, the database allows for simultaneous reads and writes,
> except possibly for the period when the second phase of the writes are
> occurring, and it will try to allow as much overlap there as possible,
> and try to find a time when no readers are active to do this operation.
> 
> Without a busy timeout being set, the reader should only get a busy in
> fairly rare conditions, the main one being if the last connection to the
> database is closing, then SQLite does some cleanup that locks the
> database for just a little bit, or if the last connection 'crashes' than
> the next connection will do some cleanup. Even a fairly short busy wait
> should handle these cases most of the time.

WAL mode was previously discussed here:

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

The upshot appears to be this, at least as things currently stand:

> DO NOT use SQLite as a Postfix backend database updated live while
> Postfix is running.

rg

Re: What is the right way to update a postfix sqlite database?

[Richard Damon]

On 2/23/21 2:18 PM, Wietse Venema wrote:
> Ron Garret:
>>> If we take this route, then there needs to be a new field in the
>>> Postfix sqlite config file that controls the time limit.
>> Not necessarily.  You could just hard-code a reasonable value (like
>> 1 second), or make it a #define so you need a recompile to change
>> it.  That?s sub-optimal, obviously, but still a major improvement
>> over the current situation for very little effort and no down-side
>> that I can see.
> The limit should be configurable. It takes:
>
> - one line of code to define a C variable, 
>
> - one line of code to read its value from an sqlite_table configuration
>   file (or to use a documented default value),
>
> - a few lines of text to document the new field in the sqlite_table manpage.
>
>   Wietse

One thng to look at is WAL mode. WAL mode increases the cost of writes
to the database, as all writes become two stage, first to the WAL
journal, and then flushed to the main database (called A checkpoint),
and reads reads can get a bit more expensive if the second stage of the
write gets delayed by long accesses (but that may not be an issue with
postfix).

In exchange, the database allows for simultaneous reads and writes,
except possibly for the period when the second phase of the writes are
occurring, and it will try to allow as much overlap there as possible,
and try to find a time when no readers are active to do this operation.

Without a busy timeout being set, the reader should only get a busy in
fairly rare conditions, the main one being if the last connection to the
database is closing, then SQLite does some cleanup that locks the
database for just a little bit, or if the last connection 'crashes' than
the next connection will do some cleanup. Even a fairly short busy wait
should handle these cases most of the time.

-- 
Richard Damon

Re: What is the right way to update a postfix sqlite database?

[Wietse Venema]

Ron Garret:
> > If we take this route, then there needs to be a new field in the
> > Postfix sqlite config file that controls the time limit.
> 
> Not necessarily.  You could just hard-code a reasonable value (like
> 1 second), or make it a #define so you need a recompile to change
> it.  That?s sub-optimal, obviously, but still a major improvement
> over the current situation for very little effort and no down-side
> that I can see.

The limit should be configurable. It takes:

- one line of code to define a C variable, 

- one line of code to read its value from an sqlite_table configuration
  file (or to use a documented default value),

- a few lines of text to document the new field in the sqlite_table manpage.

Wietse

Re: What is the right way to update a postfix sqlite database?

[Ron Garret]

On Feb 23, 2021, at 10:19 AM, Wietse Venema  wrote:

> Ron Garret:
>>>> Isn't SQLite supposed to deal with concurrent access?
>>>> https://sqlite.org/lockingv3.html
>>> 
>>> Yes, it does, but the way it ?deals? with it is to throw an error
>> if one connection tried to read while another is writing.  The net
> 
> Bleh, it does not retry the operation?

Nope.  See postfix-3.5.9/src/global/dict_sqlite.c.

It’s not clear that retrying would even be the right thing to do because you 
could just get unlucky again.  The failure can happen in three different 
places: the query itself (obviously) but also statement preparation and 
finalization.  I’ve seen all three actually happen in practice.  So you really 
want it to wait.  That’s a lot simpler, and it guarantees success as long as 
there are no slow writers (which is a reasonable constraint).

> What happens when you update the table while some Postfix code is
> READING from the DB? Does the writer also fail?

No idea, but because I control all the writers that would be easy for me to 
fix.  In any event I don’t think that’s something postfix should be worried 
about.

>> result of this is that if Postfix tries to read during a concurrent
>> update from somewhere else, it fails catastrophically (mail is
>> actually lost).
> 
> Losing mail would be a bug in the sending program. Postfix never
> loses mail because of a fatal error.

What can I say?  When this happens, I can’t find the message that was being 
processed anywhere.  It is not delivered (obviously) and it is not bounced.  
The way I first found out this was happening was an error notification in the 
root mailbox of the machine where postfix is running.

>> It would be nice if postfix would set a non-zero busy timeout.
>> It?s a simple code change, just a call to sqlite3_busy_timeout.
> 
> What about https://www.sqlite.org/pragma.html#pragma_busy_timeout ?
> I don't know if that is a DB property or a session property.

It’s a session/connection property.  The problem with trying to use a pragma in 
the config file is that the C interface to sqlite does not allow multiple 
semicolon-separated statements in a call to sqlite3_prepare_v2, so just putting 
the pragma in the postfix sql config as part of the query with a semicolon 
after will not work.  Postfix would have to know to separate multiple 
statements and prepare them separately.  Since a source code change would be 
needed anyway, a much simpler solution is just to call sqlite3_busy_timeout 
directly.

>> That would not be a guarantee, but it would at least make it
>> *possible* to safely update a sqliite database in-place.  I?m going
>> to head on over to the postfix-dev list to see if it?s possible
>> to get this done.
> 
> If we take this route, then there needs to be a new field in the
> Postfix sqlite config file that controls the time limit.

Not necessarily.  You could just hard-code a reasonable value (like 1 second), 
or make it a #define so you need a recompile to change it.  That’s sub-optimal, 
obviously, but still a major improvement over the current situation for very 
little effort and no down-side that I can see.

rg

Re: What is the right way to update a postfix sqlite database?

[Viktor Dukhovni]

On Tue, Feb 23, 2021 at 01:19:24PM -0500, Wietse Venema wrote:

> > > Yes, it does, but the way it ?deals? with it is to throw an error
> > if one connection tried to read while another is writing.  The net
> 
> Bleh, it does not retry the operation?

Only if you specify a retry timeout. SQLite is mostly for embedded
use-cases, and support for sharing has warts.

> What happens when you update the table while some Postfix code is
> READING from the DB? Does the writer also fail?

No, only if the writer has no retry timeout.  This typically works,
but is sub-optimal.

> > It would be nice if postfix would set a non-zero busy timeout.
> > It?s a simple code change, just a call to sqlite3_busy_timeout.
> 
> What about https://www.sqlite.org/pragma.html#pragma_busy_timeout ?
> I don't know if that is a DB property or a session property.

It is a session property.

> If we take this route, then there needs to be a new field in the
> Postfix sqlite config file that controls the time limit.

Yes.

-- 
Viktor.

Re: What is the right way to update a postfix sqlite database?

[Wietse Venema]

Ron Garret:
> >> Isn't SQLite supposed to deal with concurrent access?
> >> https://sqlite.org/lockingv3.html
> > 
> > Yes, it does, but the way it ?deals? with it is to throw an error
> if one connection tried to read while another is writing.  The net

Bleh, it does not retry the operation?

What happens when you update the table while some Postfix code is
READING from the DB? Does the writer also fail?

> result of this is that if Postfix tries to read during a concurrent
> update from somewhere else, it fails catastrophically (mail is
> actually lost).

Losing mail would be a bug in the sending program. Postfix never
loses mail because of a fatal error.

> It would be nice if postfix would set a non-zero busy timeout.
> It?s a simple code change, just a call to sqlite3_busy_timeout.

What about https://www.sqlite.org/pragma.html#pragma_busy_timeout ?
I don't know if that is a DB property or a session property.

> That would not be a guarantee, but it would at least make it
> *possible* to safely update a sqliite database in-place.  I?m going
> to head on over to the postfix-dev list to see if it?s possible
> to get this done.

If we take this route, then there needs to be a new field in the
Postfix sqlite config file that controls the time limit.

Wietse

Re: What is the right way to update a postfix sqlite database?

[Ron Garret]

On Feb 22, 2021, at 4:56 PM, Ron Garret (gmail)  wrote:

> 
> On Feb 22, 2021, at 2:57 PM, Wietse Venema  wrote:
> 
>> Ron Garret:
>> [ Charset windows-1252 converted... ]
>>> I ran into the sqlite locked database problem discussed in these threads:
>>> 
>>> https://marc.info/?l=postfix-users=160096626120296=2
>>> 
>>> https://marc.info/?l=postfix-users=151561295721906=2
>>> 
>>> The problem occurs (AFAICT) because the database file was shared with a 
>>> spam filter which was writing to the db.  But that raises the following 
>>> question: what is the right way to update a sqlite db used by postfix?  The 
>>> only safe way I can think of doing it is to actually shut down postifx, 
>>> update the db, and then start postfix back up again.  But that feels like 
>>> an overly brutal solution.  Is there a better way? Even a non-shared db 
>>> needs to be updated now and then.
>>> 
>>> I can guarantee that all writes will complete within a short time, so what 
>>> I would really like to do is to get postfix to issue a ?PRAGMA busy_timeout 
>>> = ?? command before doing the query, but I don?t want to have to rebuild 
>>> postfix from source in order to do this.  Is this possible?  How?
>>> 
>> 
>> Isn't SQLite supposed to deal with concurrent access?
>> https://sqlite.org/lockingv3.html
> 
> Yes, it does, but the way it “deals” with it is to throw an error if one 
> connection tried to read while another is writing.  The net result of this is 
> that if Postfix tries to read during a concurrent update from somewhere else, 
> it fails catastrophically (mail is actually lost).

Just for the record: I spent some more time groveling around in the docs and 
source code and AFAICT it is actually not possible to safely update a sqlite DB 
that is in use by postfix.  The only safe way to do it is to make a copy of the 
DB, update that, and then mv it to the active path.  This is according to both 
the docs and the code.

It would be nice if postfix would set a non-zero busy timeout.  It’s a simple 
code change, just a call to sqlite3_busy_timeout.  That would not be a 
guarantee, but it would at least make it *possible* to safely update a sqliite 
database in-place.  I’m going to head on over to the postfix-dev list to see if 
it’s possible to get this done.

rg

Re: What is the right way to update a postfix sqlite database?

[Wietse Venema]

Ron Garret:
[ Charset windows-1252 converted... ]
> I ran into the sqlite locked database problem discussed in these threads:
> 
> https://marc.info/?l=postfix-users=160096626120296=2
> 
> https://marc.info/?l=postfix-users=151561295721906=2
> 
> The problem occurs (AFAICT) because the database file was shared with a spam 
> filter which was writing to the db.  But that raises the following question: 
> what is the right way to update a sqlite db used by postfix?  The only safe 
> way I can think of doing it is to actually shut down postifx, update the db, 
> and then start postfix back up again.  But that feels like an overly brutal 
> solution.  Is there a better way? Even a non-shared db needs to be updated 
> now and then.
> 
> I can guarantee that all writes will complete within a short time, so what I 
> would really like to do is to get postfix to issue a ?PRAGMA busy_timeout = 
> ?? command before doing the query, but I don?t want to have to rebuild 
> postfix from source in order to do this.  Is this possible?  How?
> 

Isn't SQLite supposed to deal with concurrent access?
https://sqlite.org/lockingv3.html

Wietse

What is the right way to update a postfix sqlite database?

[Ron Garret]

I ran into the sqlite locked database problem discussed in these threads:

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

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

The problem occurs (AFAICT) because the database file was shared with a spam 
filter which was writing to the db.  But that raises the following question: 
what is the right way to update a sqlite db used by postfix?  The only safe way 
I can think of doing it is to actually shut down postifx, update the db, and 
then start postfix back up again.  But that feels like an overly brutal 
solution.  Is there a better way? Even a non-shared db needs to be updated now 
and then.

I can guarantee that all writes will complete within a short time, so what I 
would really like to do is to get postfix to issue a “PRAGMA busy_timeout = …” 
command before doing the query, but I don’t want to have to rebuild postfix 
from source in order to do this.  Is this possible?  How?

Thanks,
rg

Re: What is lost by using self-signed certs for TLS?

[Viktor Dukhovni]

On Mon, Jul 27, 2020 at 07:53:09PM -0400, Scott Hollenbeck wrote:

> If you use them, you're going to need to do some scripting using the
> Let's Encrypt renewal hooks and gcloud to update your TLSA record(s)
> every time you renew your certificate(s). Viktor does some automated
> checking that's caught the few times when my TLSA re-generation script
> has gone awry, so don't worry, if you publish a bad TLSA record you'll
> find out soon enough!

I don't recommend relying solely on the DANE survey engine for
monitoring.  The alerts are neither especially timely, nor will continue
to be sent indefinitely.  One enough notices fail to break the pattern
of periodic outages, I stop sending the notices.

-- 
Viktor.

RE: What is lost by using self-signed certs for TLS?

[Scott Hollenbeck]

> -Original Message-
> From: owner-postfix-us...@postfix.org 
> On Behalf Of Antonio Leding
> Sent: Monday, July 27, 2020 6:56 PM
> To: postfix-users@postfix.org
> Subject: Re: What is lost by using self-signed certs for TLS?
> 
> Thanks Victor - actually watching some of the presos now…
> 
> BTW…any choice you like for DNSSEC providers?  Google seems like a safe
> bet but I figured you might have some feedback on this as well…

I use Google. They've been reliable, inexpensive (for my small zones), and they 
do support DNSSEC and TLSA record publication. If you use them, you're going to 
need to do some scripting using the Let's Encrypt renewal hooks and gcloud to 
update your TLSA record(s) every time you renew your certificate(s). Viktor 
does some automated checking that's caught the few times when my TLSA 
re-generation script has gone awry, so don't worry, if you publish a bad TLSA 
record you'll find out soon enough!

Scott

Re: What is lost by using self-signed certs for TLS?

[Viktor Dukhovni]

On Mon, Jul 27, 2020 at 10:55:31PM +, Antonio Leding wrote:

> Thanks Victor - actually watching some of the presos now…
> 
> BTW…any choice you like for DNSSEC providers?  Google seems like a safe bet 
> but I figured you might have some feedback on this as well…

I self-host, so my direct experience is limited.  Google are signing a
lot of domains lately.  On any given day, most of the newly signed
domains are operated by them, so they certainly are doing it at scale.

In Europe, there are many providers that also host DANE TLSA RRs for
their DNS+MX hosted domains.

one.com
transip.nl
domeneshop.no
...

https://mail.sys4.de/pipermail/dane-users/2020-July/000571.html

Though somewhat out of date (I update it infrequently), the below shows
which MX-hosting providers have many DNSSEC-signed customer domains:

http://dnssec-stats.ant.isi.edu/~viktor/hosters.html

Cloudflare also does DNSSEC hosting, but does not do much if any email
hosting, so don't show up in the above stats.  At some point I should
starting populating NS and/or SOA records to the DANE survey database,
which would provide better insight into who operates DNSSEC-signed
domains.  Presently, I only collect the DS, DNSKEY, MX, A,  and
TLSA RRs, which cover the MX-operator, but not the DNS operator.

-- 
Viktor.

Re: What is lost by using self-signed certs for TLS?

[Antonio Leding]

Thanks Victor - actually watching some of the presos now…

BTW…any choice you like for DNSSEC providers?  Google seems like a safe bet but 
I figured you might have some feedback on this as well…



> On Jul 27, 2020, at 3:36 PM, Viktor Dukhovni  
> wrote:
> 
> On Mon, Jul 27, 2020 at 09:48:29PM +, Antonio Leding wrote:
> 
>> Again, great feedback…I am definitely diving into DANE now…may have
>> more questions but I will try to keep those to a minimum.
> 
> https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
> 
> -- 
>Viktor.

Re: What is lost by using self-signed certs for TLS?

[Viktor Dukhovni]

On Mon, Jul 27, 2020 at 09:48:29PM +, Antonio Leding wrote:

> Again, great feedback…I am definitely diving into DANE now…may have
> more questions but I will try to keep those to a minimum.

https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources

-- 
Viktor.

Re: What is lost by using self-signed certs for TLS?

[Antonio Leding]

Again, great feedback…I am definitely diving into DANE now…may have more 
questions but I will try to keep those to a minimum.

Thanks again Victor - very much appreciated…


> On Jul 27, 2020, at 2:44 PM, Viktor Dukhovni  
> wrote:
> 
> On Mon, Jul 27, 2020 at 08:58:19PM +, Antonio Leding wrote:
>>> You can of course use an LE cert, it does not do any obvious harm,
>>> unless you also do DANE, and neither freeze the key, nor handle TLSA
>>> updates correctly (in advance of cert deployment).
>> 
>> So I’m gathering (a) not much will be gained by using a public-A
>> signed cert; and (b) the PROs of using DANE + self-signed likely (or
>> actually) outweigh going with an LE cert sans DANE.
> 
> Yes, (a) not much gained.
> 
> And, (b) while it is not in principle that difficult to combine DANE
> with automated renewal of Let's Encrypt certs, some struggle getting all
> the gears to move in unison.
> 
> If you do want to secure your inbound email, do consider DANE, but
> make sure that the first thing you implement is monitoring that
> checks whether DANE is working correctly, then a robust rollover
> process that ensures that even somewhat stale TLSA records (in
> secondary nameservers or downstream caches) never fail to
> match the deployed certificate chain.
> 
> Once you have monitoring, and sound rollover process, enable DANE.
> You'll of course need to have a DNSSEC-signed domain, and monitoring for
> that too (including checking that signatures on key RRsets are not
> unexpectedly close to expiring).
> 
> -- 
>Viktor.

Re: What is lost by using self-signed certs for TLS?

[Viktor Dukhovni]

On Mon, Jul 27, 2020 at 08:58:19PM +, Antonio Leding wrote:
> > You can of course use an LE cert, it does not do any obvious harm,
> > unless you also do DANE, and neither freeze the key, nor handle TLSA
> > updates correctly (in advance of cert deployment).
> 
> So I’m gathering (a) not much will be gained by using a public-A
> signed cert; and (b) the PROs of using DANE + self-signed likely (or
> actually) outweigh going with an LE cert sans DANE.

Yes, (a) not much gained.

And, (b) while it is not in principle that difficult to combine DANE
with automated renewal of Let's Encrypt certs, some struggle getting all
the gears to move in unison.

If you do want to secure your inbound email, do consider DANE, but
make sure that the first thing you implement is monitoring that
checks whether DANE is working correctly, then a robust rollover
process that ensures that even somewhat stale TLSA records (in
secondary nameservers or downstream caches) never fail to
match the deployed certificate chain.

Once you have monitoring, and sound rollover process, enable DANE.
You'll of course need to have a DNSSEC-signed domain, and monitoring for
that too (including checking that signatures on key RRsets are not
unexpectedly close to expiring).

-- 
Viktor.

Re: What is lost by using self-signed certs for TLS?

[Antonio Leding]

> You can of course use an LE cert, it does not do any obvious harm,
> unless you also do DANE, and neither freeze the key, nor handle TLSA
> updates correctly (in advance of cert deployment).

So I’m gathering (a) not much will be gained by using a public-A signed cert; 
and (b) the PROs of using DANE + self-signed likely (or actually) outweigh 
going with an LE cert sans DANE.



> On Jul 27, 2020, at 1:52 PM, Viktor Dukhovni  
> wrote:
> 
> On Mon, Jul 27, 2020 at 07:32:41PM +, Antonio Leding wrote:
> 
>> I’ve always been dubious about the auth requirement by some (i.e. the
>> brain deads to which you refer) to allow TLS connections for
>> server-to-server communications.
> 
> Without DANE or (weaker) MTA-STS, indeed X.509 authentication of SMTP MX
> hosts is mere appearance of security.
> 
>> In any event, people do what people do so I guess in order to ensure
>> my server will employ the highest number of TLS sessions, I should use
>> a CA-signed cert...  
> 
> That's not the conclusion I reached.  My MTA uses a self-signed cert.
> The domains that abort STARTTLS with untrusted certs are few and don't
> send anything sensitive.
> 
>> Agreed?
> 
> You can of course use an LE cert, it does not do any obvious harm,
> unless you also do DANE, and neither freeze the key, nor handle TLSA
> updates correctly (in advance of cert deployment).
> 
> -- 
>Viktor.

Re: What is lost by using self-signed certs for TLS?

[Viktor Dukhovni]

On Mon, Jul 27, 2020 at 07:32:41PM +, Antonio Leding wrote:

> I’ve always been dubious about the auth requirement by some (i.e. the
> brain deads to which you refer) to allow TLS connections for
> server-to-server communications.

Without DANE or (weaker) MTA-STS, indeed X.509 authentication of SMTP MX
hosts is mere appearance of security.

> In any event, people do what people do so I guess in order to ensure
> my server will employ the highest number of TLS sessions, I should use
> a CA-signed cert...  

That's not the conclusion I reached.  My MTA uses a self-signed cert.
The domains that abort STARTTLS with untrusted certs are few and don't
send anything sensitive.

> Agreed?

You can of course use an LE cert, it does not do any obvious harm,
unless you also do DANE, and neither freeze the key, nor handle TLSA
updates correctly (in advance of cert deployment).

-- 
Viktor.

Re: What is lost by using self-signed certs for TLS?

[Antonio Leding]

Hi Victor…

Thanks so much for the feedback…very helpful…

I’ve always been dubious about the auth requirement by some (i.e. the brain 
deads to which you refer) to allow TLS connections for server-to-server 
communications.  My view is this — when my server sends outbound mail, do I 
really care that the server I looked up via DNS is who they purport to be in 
the cert?  I have to imagine if a bad actor is able to somehow hack\forge DNS 
records that they will also be able to take care of the cert especially given 
that LE is free and very easy to obtain after the DNS has been cfg’d.

In any event, people do what people do so I guess in order to ensure my server 
will employ the highest number of TLS sessions, I should use a CA-signed 
cert...  

Agreed?


> On Jul 25, 2020, at 8:03 PM, Viktor Dukhovni  
> wrote:
> 
> On Sun, Jul 26, 2020 at 02:45:38AM +, Antonio Leding wrote:
> 
>> My goal is to fully understand what is lost by using only self-signed
>> certs on my PF server.  Here’s what I think I know:
>> 
>> — The fact that the cert is self-signed really only impacts mail
>> coming into our organization from those who are outside the
>> organization.
> 
> Assuming that no internal system fails to implement opportunistic TLS in
> a sane manner.
> 
>> — Because the cert cannot be verified, only anonymous ciphers can be
>> negotiated between my server and the other side’s client.
> 
> No. that's false.  A majority of clients will solicit certificates they
> then proceed to ignore.  It's to some extent a cargo-cult thing, someone
> on the Internet said that anonymous ciphers are insecure, and so users
> avoid them, though they don't exactly know why.  But the sickness is
> deep, TLS 1.3 has completely removed support for anonymous ciphers, so
> in a few years their use will be rather exotic.
> 
>> I have to believe there are more considerations here which of course
>> is why I came to you all…
> 
> A few brain-dead bulk mail systems (you probably don't care about),
> abort the TLS handshake when they see a certificate chain they can't
> verify, and then proceed to deliver in clear text, as though that's more
> secure than using unauthenticated TLS.  Again cargo-cult, someone on the
> Internet said that certificate verification is not optional.
> 
> Otherwise, you're free to use self-signed certs, they work just fine for
> quite a lot of receiving systems.
> 
> You can even implement DNSSEC for your domain (with monitoring to
> check that it is working, that signatures are not too close to
> expiration, ...) and then publish DANE TLSA records:
> 
>https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
> 
> but again only if you also implement monitoring to ensure that
> the certificate chain and TLSA records match, and a cert rollover
> process that avoids periodic outages caused by rolling the cert
> and TLSA RRs at the same time and ignoring remote caches, and/or
> older authoritative zone data on secondary servers.
> 
> -- 
>Viktor.

Re: What is lost by using self-signed certs for TLS?

[Viktor Dukhovni]

On Sun, Jul 26, 2020 at 02:45:38AM +, Antonio Leding wrote:

> My goal is to fully understand what is lost by using only self-signed
> certs on my PF server.  Here’s what I think I know:
> 
> — The fact that the cert is self-signed really only impacts mail
> coming into our organization from those who are outside the
> organization.

Assuming that no internal system fails to implement opportunistic TLS in
a sane manner.

> — Because the cert cannot be verified, only anonymous ciphers can be
> negotiated between my server and the other side’s client.

No. that's false.  A majority of clients will solicit certificates they
then proceed to ignore.  It's to some extent a cargo-cult thing, someone
on the Internet said that anonymous ciphers are insecure, and so users
avoid them, though they don't exactly know why.  But the sickness is
deep, TLS 1.3 has completely removed support for anonymous ciphers, so
in a few years their use will be rather exotic.

> I have to believe there are more considerations here which of course
> is why I came to you all…

A few brain-dead bulk mail systems (you probably don't care about),
abort the TLS handshake when they see a certificate chain they can't
verify, and then proceed to deliver in clear text, as though that's more
secure than using unauthenticated TLS.  Again cargo-cult, someone on the
Internet said that certificate verification is not optional.

Otherwise, you're free to use self-signed certs, they work just fine for
quite a lot of receiving systems.

You can even implement DNSSEC for your domain (with monitoring to
check that it is working, that signatures are not too close to
expiration, ...) and then publish DANE TLSA records:

https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources

but again only if you also implement monitoring to ensure that
the certificate chain and TLSA records match, and a cert rollover
process that avoids periodic outages caused by rolling the cert
and TLSA RRs at the same time and ignoring remote caches, and/or
older authoritative zone data on secondary servers.

-- 
Viktor.

What is lost by using self-signed certs for TLS?

[Antonio Leding]

Hello all,

Please allow me to apologize in advance for any ignorance here…and also, I have 
researched and am just not seeing the entire picture here.

My goal is to fully understand what is lost by using only self-signed certs on 
my PF server.  Here’s what I think I know:

— The fact that the cert is self-signed really only impacts mail coming into 
our organization from those who are outside the organization.
— Because the cert cannot be verified, only anonymous ciphers can be negotiated 
between my server and the other side’s client.

I have to believe there are more considerations here which of course is why I 
came to you all…

OK - please educate as required…and as always many thanks in advance...

Re: What is this?

[Phil Biggs]

Friday, February 28, 2020, 8:06:51 PM, Matus UHLAR - fantomas  wrote:

> On 27.02.20 08:09, Phil Biggs wrote:
>>A friend and I experienced this in October last year.
>>
>>I believe these SYNs have forged source addresses. The objectives being one 
>>or more of:
>>- a DOS attack on the legit owner of the IP,
>>- create a state table size issue for you,
>>- to have you block legitimate sources.
>>The last of these certainly happened here.

> per my last e-mail...
> https://marc.info/?l=postfix-users=158272022625515=2

> SYN with forged address can not cause this kind of error.  This error
> requires connection be made (until then postfix does not know about it) and
> then closed. Thus it requires SYN - SYN+ACK - ACK which does not work with
> forged address.

You are completely correct, of course.  I mistakenly replied to and quoted the 
OP instead
of Doug Hardie.  Very careless of me.  My apologies.

>>I set up a fail2ban rule to pick these up and, after one day,
>>nearly 9,500 sources had been blocked at the firewall.
>>However, the pf table included addresses that belonged to the likes of 
>>MessageLabs.
>>I dropped the rule and unbanned them after realizing that.

> It's more likely that messagelabs scan the internet for open relays,
> mailservers features to gather statistics about the internet.

The SYN (or SYN+ACK) attack was targeting whole address blocks belonging
to AWS, MessageLabs, a Turkish bank and many others.

Phil