[pfx] Howto Whitelist an unknown Sender Domain

[Norbert Schmidt via Postfix-users]

I've dmarc configured to send out reports to those domains, that have dmarc
configuration too. 

 

A lot of those are misconfigured in one way or another. 

Mostly the mailaddress stated in DNS is not accepting my mails or is not
existent at all. 

But some have got their mailserver misconfigured in a way that the
MAILER-DAEMON sends mail from a non existent domain as you can see in this
log:

 

In:  EHLO mail1.tk.de

Out: 250-mail2.proris.com

.

.

.

In:  MAIL FROM:<  mailer-dae...@esa2.tk.de>
SIZE=1823

Out: 250 2.1.0 Ok

In:  RCPT TO:<  dm...@proris.com>

Out: 450 4.1.8 < 
mailer-dae...@esa2.tk.de>: Sender address rejected: Domain not

 found

In:  RSET

Out: 250 2.0.0 Ok

In:  QUIT

Out: 221 2.0.0 Bye

 

Now I would like to whitelist such domains within postfix so it does accept
these mails.

I tried by creating a file /etc/postfix/whitelist_unknown_domain with:

 

mailer-dae...@esa2.tk.deOK

 

Then added it to smtpd_sender_restrictions:

smtpd_sender_restrictions = pcre:/etc/postfix/blacklist_domains_pcre,
hash:/etc/postfix/whitelist_unknown_domain

 

But the mails are still not accepted. 

What am I missing?

 

Thanks

Norbert

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

[pfx] Re: PATCH: Segfault with Postfix 3.10

[A. Schulze via Postfix-users]

Am 16.02.25 um 19:11 schrieb Wietse Venema via Postfix-users:

measurem...@mail-mtasts-rn-mult-ivv.measurement.email-security-scans.org


I was able reproduce a crash sending mail to that address, without
needing any smtp_tls_policy_maps plugin stuff.


I was unable to reproduce a segfault. postfix-3.10-20250207 (without the patch)
handled my message to the address above as usual.
Also all my other lab systems do not log any segfault. OK, maybe they simply 
hit no server with an expired certificate.

Are there additional requirements that this error occur?

But, as it is identified and fixed, maybe that does no longer matter ...

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

[pfx] BDAT and the line length limit

[Damian via Postfix-users]

I would like some opinions on how certain RFCs are to be interpreted.

My core question is: Is it possible to send mail RFC-conformly into a 
Postfix, such that there are more than 1000 consecutive Non-CRLFs?


I think everybody agrees that this is not possible with DATA. The 
BDAT_README seems to imply that this isn't possible without BINARYMIME 
either (which Postfix does not support):



Postfix does not support BINARYMIME at this time because:
BINARYMIME support would require moderately invasive changes to 
Postfix, to

support email content that is not line-oriented. [...] Without BINARYMIME
support, email RFCs require that binary content is base64-encoded, and
formatted as lines of text


I am not so sure about the last sentence.

It is clear that the transported payload needs to adhere to RFC2045, 
with DATA or BDAT, with or without BINARYMIME.
RFC3030 explicitly associates BINARYMIME with RFC2045's "binary" 
mechanism, i.e. "Content-Transfer-Encoding: binary". RFC2045 even 
acknowledges the following for binary:



As of the initial publication of this document, there are no standardized
Internet mail transports for which it is legitimate to include 
unencoded binary

data in mail bodies. Thus there are no circumstances in which the "binary"
Content-Transfer-Encoding is actually valid in Internet mail.


But the same paragraph also states:

However, in the event that binary mail transport becomes a reality in 
Internet
mail, or when MIME is used in conjunction with any other 
binary-capable mail

transport mechanism, binary bodies must be labelled as such using this
mechanism.


It seems that the BDAT_README sees the announcement of BINARYMIME 
support as necessary to "becoming reality", while I do not see a reason 
why BDAT support itself could not already have made it become reality. 
BINARYMIME has been explicitly designed for RFC2045's binary mechanism, 
yes, but BDAT might just be one of "any other binary-capable" mechanisms.


So where does some of the RFCs forbid to combine BDAT with BODY=7BIT or 
BODY=8BITMIME, Content-Transfer-Encoding: binary, and a 1000+ octet 
Non-CRLF-ASCII string?


Note that the term "binary-capable" cannot be defined as 
"BINARYMIME-capable", because RFC2045 is older than RFC3030, so one 
cannot mechanically infer "not binary-capable" from "not 
BINARYMIME-capable".


Also note that although RFC1652 (8BITMIME) explicitly mentions the 1000 
octet limit itself, it also mentions dot-stuffing, which Postfix 
(rightfully) ignores when using BDAT.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: BDAT and the line length limit

[Damian via Postfix-users]

Postfix supports 8bit Data, with lines of 998 between CRLF, as
defined inhttps://datatracker.ietf.org/doc/html/rfc2045#section-2.8
Therefore, Postfix announces 8BITMIME in EHLO.

Postfix does not support Binary Data, as defined in
https://datatracker.ietf.org/doc/html/rfc2045#section-2.9 Binary
Therefore, Postfix does not announce BINARYMIME in EHLO.

Systems that do not announce BINARYMIME in EHLO can receive only
content with lines of 998 between CRLF.

Only systems that anounce BINARYMIME in EHLO can receive content
that is not lines of 998 between CRLF.


Your last two statements are exactly the crux of the matter, and I don't 
see them justified, yet. RFC2045 cannot tie its Binary Data to 
BINARYMIME, because RFC2045 does not know about RFC3030. RFC2045 just 
tells us that Binary Data must be transmitted by a binary-capable 
transport. RFC2045 does not say that this needs to be announced by a 
specifically named EHLO keyword defined by a specifically numbered RFC. 
In my opinion, BDAT itself could already be meant to signal support for 
binary payload, as the name most probably stands for Binary DATa.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: BDAT and the line length limit

[Wietse Venema via Postfix-users]

Postfix supports 7bit data, with lines of 998 between CRLF, as
defined in https://datatracker.ietf.org/doc/html/rfc2045#section-2.7
This is non-negotiable, and is not announced in EHLO.

Postfix supports 8bit Data, with lines of 998 between CRLF, as 
defined in https://datatracker.ietf.org/doc/html/rfc2045#section-2.8
Therefore, Postfix announces 8BITMIME in EHLO.

Postfix does not support Binary Data, as defined in
https://datatracker.ietf.org/doc/html/rfc2045#section-2.9 Binary
Therefore, Postfix does not announce BINARYMIME in EHLO.

Systems that do not announce BINARYMIME in EHLO can receive only
content with lines of 998 between CRLF.

Only systems that anounce BINARYMIME in EHLO can receive content
that is not lines of 998 between CRLF.

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

[pfx] Re: BDAT and the line length limit

[Wietse Venema via Postfix-users]

You may have noticed that BDAT and BINARYMIME are distinct features.

For reasonable people, both must be supported if one wants to send
content other than lines with 998 bytes before CRLF.

For other people, BINARYMIME is some kind of mistake, and BDAT alone
is sufficient to send content other than lines with 998 bytes before
CRLF.

Fortunately, the latter people don't write widely used email standards
and don't implement widely used email software.

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

[pfx] Re: BDAT and the line length limit

[Damian via Postfix-users]

Your last two statements are exactly the crux of the matter, and I don't see
them justified, yet.

And yet they are justified.  Wishful thinking does not change that. 🙁
Absent BINARYMIME the body time of a BDAT message is 8BITMIME, which is
still line-oriented.
If they are justified, then not by RFC2045. Or would you say that it is 
impossible to design an SMTP-unrelated binary-capable protocol that can 
transport RFC2045-compliant Binary Data?___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: BDAT and the line length limit

[Viktor Dukhovni via Postfix-users]

On Mon, Feb 17, 2025 at 04:10:30PM +0100, Damian via Postfix-users wrote:

> > Systems that do not announce BINARYMIME in EHLO can receive only
> > content with lines of 998 between CRLF.
> > 
> > Only systems that anounce BINARYMIME in EHLO can receive content
> > that is not lines of 998 between CRLF.
> 
> Your last two statements are exactly the crux of the matter, and I don't see
> them justified, yet.

And yet they are justified.  Wishful thinking does not change that. :-(
Absent BINARYMIME the body time of a BDAT message is 8BITMIME, which is
still line-oriented.  The only change from normal SMTP rules is that "."
characters at the start of a line are no longer special, and don't need
to be stuttered.

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

[pfx] Postfix stable release 3.10.0

[Wietse Venema via Postfix-users]

[An updated version of this announcement will be available at
https://www.postfix.org/announcements/postfix-3.10.0.html]

Postfix stable release 3.10.0 is available. Postfix 3.6 - 3.9 were updated
earlier this week; after that, Postfix 3.6 will no longer be updated.

The main changes are below. See the RELEASE_NOTES file for further
details.

Changes that need restart:

  * Internal protocol change: Postfix needs "postfix reload" (or "postfix
stop" and "postfix start") after upgrade, because of a change in the
delivery agent protocol. If this step is skipped, Postfix delivery
agents will log a warning:

unexpected attribute smtputf8 from xxx socket (expecting: sendopts)

where xxx is the delivery agent service name.

Changes in TLS support:

  * Forward compatibility: Support for OpenSSL 3.5 post-quantum
cryptography. To manage algorithm selection, OpenSSL introduces new
TLS group syntax that Postfix will not attempt to imitate. Instead,
Postfix now allows the tls_eecdh_auto_curves and tls_ffdhe_auto_groups
parameter values to have an empty value. When both are set empty, the
algorithm selection can be managed through OpenSSL configuration. For
more, look for "Post-quantum" in the postconf(5) manpage.

  * Support for the RFC 8689 "TLS-Required: no" message header to request
delivery of messages (such as TLSRPT summaries) even if the preferred
TLS security policy cannot be enforced. This limits the Postfix SMTP
client to "smtp_tls_security_level = may" which does not authenticate
server certificates and which allows falling back to plaintext.

  * Support for the REQUIRETLS SMTP service extension will evolve in
Postfix 3.11.

  * Support for the TLSRPT protocol (defined in RFC 8460). With this,
a domain can publish a policy in DNS that requests daily summary
reports for successful and failed SMTP-over-TLS connections to that
domain's MX hosts. This supports both DANE (built-in) and MTA-STS
(via an smtp_tls_policy_maps plugin). The implementation uses a
TLSRPT library and reporting infrastructure that are maintained by
sys4. For details, see TLSRPT_README.

Miscellaneous changes:

  * Privacy: With "smtpd_hide_client_session = yes", the Postfix
SMTP server generates a Received: header without client session
info. This setting may be used with the MUA submission services
(port 465 and 587).

  * Support for RFC 2047 encoding of non-ASCII "full name" information
in Postfix-generated From: message headers. Encoding non-ASCII full
names can avoid the need to use SMTPUTF8, and therefore can avoid
incompatibility with sites that do not support SMTPUTF8. See the
full_name_encoding_charset parameter description for details.

  * Database performance: When mysql: or pgsql: configuration specifies
a single host, assume that it is a load balancer and reconnect
immediately after a single failure, instead of failing all requests
for 60s.

Changes in logging:

  * The Postfix Milter implementation now logs the reason for a
'quarantine' action, instead of "milter triggers HOLD action".

  * The SMTP server now logs the queue ID (or "NOQUEUE") when a connection
ends abnormally (timeout, lost connection, or too many errors),
and the cleanup server now logs "queueid: canceled" when a message
transaction is started but not completed. These changes simplify
logfile analysis.

  * Dovecot SASL client logging for "Invalid authentication mechanism"
now includes the name of that mechanism.

  * Postfix SMTP server 'reject' logging now shows the sasl_method,
sasl_username, and sasl_sender if available.

You can find the Postfix source code at the mirrors listed at
https://www.postfix.org/.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: PATCH: Segfault with Postfix 3.10

[Wietse Venema via Postfix-users]

?mer G?ven via Postfix-users:
> At the end, fixing any possible segfault makes the smtp process
> more stable. It re-queued the same mail 6-7 times before the fix,

Given that Andreas and I were unable to reproduce this without some
amount of tweaking, the impact of failure is easily over-stated.
Also, the problem was reported a month after detection; that shows
problem was not deemed urgent.

I'll give you credit for reporting it, but I am not impressed with
the process.

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

[pfx] Re: PATCH: Segfault with Postfix 3.10

[Ömer Güven via Postfix-users]

Totally agree! Thanks for finding the tiny typo and fixing though!

> Am 17.02.2025 um 20:51 schrieb Wietse Venema via Postfix-users 
> :
> 
> ?mer G?ven via Postfix-users:
>> At the end, fixing any possible segfault makes the smtp process
>> more stable. It re-queued the same mail 6-7 times before the fix,
> 
> Given that Andreas and I were unable to reproduce this without some
> amount of tweaking, the impact of failure is easily over-stated.
> Also, the problem was reported a month after detection; that shows
> problem was not deemed urgent.
> 
> I'll give you credit for reporting it, but I am not impressed with
> the process.
> 
>Wietse
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org


smime.p7s
Description: S/MIME cryptographic signature
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: XOAUTH2 without Dovecot?

[Jim Garrison via Postfix-users]

On 2/12/2025 11:22, Wietse Venema via Postfix-users wrote:

Jim Garrison via Postfix-users:

I have a Postfix server that does outbound-only relay in a small network
via a smarthost.  There is no incoming mail (so no Dovecot), and
outbound is restricted to a very small set of clients.

The relay has to go through GMail, which I have had working with
user/password auth for several years.  That's going away and GMail will
require OAUTH2.

I've followed the thread at
https://www.mail-archive.com/postfix-users@postfix.org/msg104614.html
but solutions seem to require Dovecot, which I'd rather not add to this
server.

[snip] > My armchair review:


This is a Cyrus SASL plugin that extends Cyrus SASL and thus requires
no changes to Postfix. Along with Cyrus library code it is loaded
into the Postfix SMTP client address space. The code is small but
has significant dependencies (besides Cyrus SASL, it depends on
libcurl, and on the C++ runtime library). It has (C) Google LLC,
and uses the Apache 2.0 license.

It is available as a binary package for some Debian-like distributions.
The Github repo has instrcutions for building Debian-like and
RedHat-like binary packages. Along with Cyruslibrary code it is
loaded into the Postfix SMTP client address space.

Still looking like the better option.


I successfully used this SASL plugin to get XOAUTH2 working with GMail 
as an outbound smarthost.  A couple of notes:


* Debian 12 installs postfix chroot, which I wasn't aware of. It just
  worked out of the box and I had no reason to expect chroot.

* The list of dependencies at
 
https://github.com/tarickb/sasl-xoauth2/blob/packaging/ubuntu/debian/control

  is complete, but on a minimal system you might not have python3-pip,
  which is also required.  Also it lists libstdc++6-4.6-dev, which
  might be out of date, my system had libstdc++-12-dev, which seems to
  work.

* Be sure to read and *carefully* follow the excellent instructions in
  the repo's README.md.

After a couple of false starts (due to me not following instructions
EXACTLY ;-), it's all working.


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

[pfx] Re: PATCH: Segfault with Postfix 3.10

[Ömer Güven via Postfix-users]

At the end, fixing any possible segfault makes the smtp process more stable. It 
re-queued the same mail 6-7 times before the fix, and the crashing process 
resulted in delayed sending to the „correct“ recipients (because they were in 
Cc/Bcc). As expired certificates do appear in real-world scenarios, it is an 
important fix. Now TLSRPT will also report the expired cert condition, whereas 
it didn‘t before.

> Am 17.02.2025 um 20:14 schrieb Wietse Venema via Postfix-users 
> :
> 
> A. Schulze via Postfix-users:
>> 
>> 
>> Am 16.02.25 um 19:11 schrieb Wietse Venema via Postfix-users:
>> measurem...@mail-mtasts-rn-mult-ivv.measurement.email-security-scans.org
>>> 
>>> I was able reproduce a crash sending mail to that address, without
>>> needing any smtp_tls_policy_maps plugin stuff.
>> 
>> I was unable to reproduce a segfault. postfix-3.10-20250207 (without the 
>> patch)
>> handled my message to the address above as usual.
>> Also all my other lab systems do not log any segfault. OK, maybe they simply 
>> hit no server with an expired certificate.
>> 
>> Are there additional requirements that this error occur?
>> 
>> But, as it is identified and fixed, maybe that does no longer matter ...
> 
> It did not segfault unless there was a 'certificate expired'
> condition. That required a tls security level that verifies
> certificates. I used the level 'secure' and a certificate match
> with tls-force.measurement.email-security-scans.org
> 
>Wietse
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org


smime.p7s
Description: S/MIME cryptographic signature
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: PATCH: Segfault with Postfix 3.10

[Ömer Güven via Postfix-users]

Well, you could try removing „reject_unknown_recipient_domain“ from the mua 
restrictions. This will accept invalid domains during „Reply All“. But 
according to Wietse, he was able to reproduce it with no extraordinary 
configuration. For me fixing the typo (8 to 0) solved the problem.

> Am 17.02.2025 um 19:25 schrieb A. Schulze via Postfix-users 
> :
> 
> 
> 
> Am 16.02.25 um 19:11 schrieb Wietse Venema via Postfix-users:
> measurem...@mail-mtasts-rn-mult-ivv.measurement.email-security-scans.org
>> I was able reproduce a crash sending mail to that address, without
>> needing any smtp_tls_policy_maps plugin stuff.
> 
> I was unable to reproduce a segfault. postfix-3.10-20250207 (without the 
> patch)
> handled my message to the address above as usual.
> Also all my other lab systems do not log any segfault. OK, maybe they simply 
> hit no server with an expired certificate.
> 
> Are there additional requirements that this error occur?
> 
> But, as it is identified and fixed, maybe that does no longer matter ...
> 
> Andreas
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org


smime.p7s
Description: S/MIME cryptographic signature
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: PATCH: Segfault with Postfix 3.10

[Wietse Venema via Postfix-users]

A. Schulze via Postfix-users:
> 
> 
> Am 16.02.25 um 19:11 schrieb Wietse Venema via Postfix-users:
>  measurem...@mail-mtasts-rn-mult-ivv.measurement.email-security-scans.org
> > 
> > I was able reproduce a crash sending mail to that address, without
> > needing any smtp_tls_policy_maps plugin stuff.
> 
> I was unable to reproduce a segfault. postfix-3.10-20250207 (without the 
> patch)
> handled my message to the address above as usual.
> Also all my other lab systems do not log any segfault. OK, maybe they simply 
> hit no server with an expired certificate.
> 
> Are there additional requirements that this error occur?
> 
> But, as it is identified and fixed, maybe that does no longer matter ...

It did not segfault unless there was a 'certificate expired'
condition. That required a tls security level that verifies
certificates. I used the level 'secure' and a certificate match
with tls-force.measurement.email-security-scans.org

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

[pfx] Re: BDAT and the line length limit

[Damian via Postfix-users]

You may have noticed that BDAT and BINARYMIME are distinct features.


Yes, but I have argued that RFC2045 compliance of mail data is a property of said data, not of the transport, so that BDAT, 
BINARYMIME and even SMTP don't actually matter. RFC2045 has references to RFC821 because it was designed to be compatible with

SMTP if SMTP is used as the transport, given SMTP's restrictions at the time of 
writing of RFC2045.

But as its section 6.2 explicitly states that other binary-capable mail 
transport mechanisms might be possible to transport MIME,
one cannot infer RFC2045 non-compliance from the presence or absence of SMTP 
features.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org