[pfx] Re: Detect/extract attachments in broken messages composed by Apple Mail

[Viktor Dukhovni via Postfix-users]

On Fri, May 26, 2023 at 01:05:09PM +0200, Paul Menzel via Postfix-users wrote:

> > This behaviour is to be expected given the incorrect MIME structure
> > of the message. It is:
> > 
> > multipart/alternative
> >   text/plain
> >   multipart/mixed
> > text/html
> > attachment

Note that sometimes the "attachment" in question is specifically related
to the HTML part (an image referenced from the HTML or similar).  And
though in principle the enclosing multipart should then be a
"multipart/related", I suspect that might not always be the case in
pratice.

> > So when selecting the plain part, you don't see the attachment
> > associated with the alternative part.
> > 
> > The message structure should be:
> > 
> > multipart/mixed
> >   multipart/alternative
> > text/plain
> > text/html
> >   attachment
> 
> If we wanted to detect such messages, and add a notification or extract 
> the attachment, what component would be the right part for such message 
> alteration? A milter?

Perhaps "altermime" could do this (though I am sceptical).  You'd
probably need to write a milter specifically for this (PyMilter).

Is this a compelling problem?  Perhaps it should be fixed on the
sender's end.

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

[pfx] "danebot" beta release (was: DANE and DNSSEC)

[Viktor Dukhovni via Postfix-users]

On Mon, May 22, 2023 at 09:53:36PM -0400, Viktor Dukhovni via Postfix-users 
wrote:

> Key reuse as a *default* rollover approach is robust.  When it is time
> to change keys, one can do so deliberately, and with due care to
> prepublish TLSA records matching the *next* key, then after a few TTLs
> deploy the next certificate, and at that point drop the outdated TLSA RR
> matching the old keys.  Meanwhile, root CAs reuse the same RSA 2048-bit
> key for decades.

To that end, though it is not yet feature-complete, I am announcing
a "beta" release of "danebot", which is a wrapper around "certbot"
that supports safe key rollover (with by default stable reused keys)
in combination with "3 1 1" TLSA records.

At this point, I am particularly looking for adoption from experienced
shell script developers, who might add missing features or having
examined the code might help to improve the documentation.

That said, "danebot" can be used as-is (I've been using it for over a
year) by anyone who is not a novice with "certbot".

https://github.com/tlsaware/danebot

The same design principles can surely (and perhaps even more easily)
be adapted to other ACME clients.  Contributions along those lines
also welcome (likely as variants of the "certbot" script).

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

[pfx] Re: TLS client policy according to domain MTA-STS policy

[Viktor Dukhovni via Postfix-users]

On Wed, May 24, 2023 at 02:25:38PM +0200, Paul Menzel via Postfix-users wrote:

> Running the *Public Email & DNS Testbed* [1], I was reminded, that we 
> have MTA-STS set up, but do not take the MTAT-STS policy of other 
> domains into account.
> 
> As a solution I found *postfix-mta-sts-resolver* [2], which warns about 
> a “RFC violation” [3]:
> 
> Do you know of other solutions?

Given how thinly MTA-STS is implemented, the simplest solution is to
just route a few of the major mta-sts domains (gmail.com, outlook.com,
and a few others) to a dedicated smtp(8) transport that uses the mta-sts
policy addon, and just enable DANE for the rest.

We may yet integrate mta-sts support into Postfix some day, but for now
you'll need to compromise in some manner.

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

[pfx] Re: wildcast for virtual domains

[Viktor Dukhovni via Postfix-users]

On Tue, May 23, 2023 at 11:56:41AM +0800, Tom Reed via Postfix-users wrote:

> Does virtual domains (such as virtual_alias_domains) support wildcard?
> such as putting this one in the file:
> 
> *.foo.com
> 
> so that one.foo.com, two.foo.com... will be a recipient domain.

You may think you want this, but in fact you really don't.
Do you have a *compelling* reason to do this?  As opposed
to listing a small number of actual domains?

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

[pfx] Re: DANE and DNSSEC

[Viktor Dukhovni via Postfix-users]

On Mon, May 22, 2023 at 02:34:41PM +0200, Joachim Lindenberg via Postfix-users 
wrote:

> reusing the private key for too long (say a year or more) is
> considered a bad security practice. Imho it is easier to monitor
> changes of the issuing CA (I do) or just mark your calendar to update
> in September 2025 than to pin 3 1 1.  Don´t want to be fundamental,
> just opinionated. Everyone has to decide on her/his own.

FWIW, I don't agree.  There are still ~270 domains publishing TLSA
records matching the long-retired Let's Encrypt X3/X4 CAs.  Dilligently
tracking issuing CA transitions is not that easy in practice, and the
security of ACME is fairly dubious.

Key reuse as a *default* rollover approach is robust.  When it is time
to change keys, one can do so deliberately, and with due care to
prepublish TLSA records matching the *next* key, then after a few TTLs
deploy the next certificate, and at that point drop the outdated TLSA RR
matching the old keys.  Meanwhile, root CAs reuse the same RSA 2048-bit
key for decades.

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

[pfx] Re: content filter sends mail twice

[Viktor Dukhovni via Postfix-users]

On Mon, May 22, 2023 at 06:06:00PM -0400, Alex wrote:

> Yes, I wasn't aware that's how it worked. I've now explicitly defined the
> bcc-user to use the same transport, but the problem is that there is one
> bcc-user but multiple transports, each with their own policy.

This is where recipient_bcc_maps comes into play, you can have a bcc
recipient per domain or per-user (the latter preserves the message
envelope as part of the BCC side-channel).

Or (in a multi-instance configuration), you can add Bcc recipients
in a per-domain output (back-end) instance.

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

[pfx] Re: delivery loop?

[Viktor Dukhovni via Postfix-users]

On Mon, May 22, 2023 at 08:26:19PM +0800, Tom Reed via Postfix-users wrote:

> 1. postfix is a backup MX for foo.com
> 2. this postfix uses other MTA as relay_host

This would be a misconfiguration.  A backup MX host MUST NOT be an
effective null client that relays *all* non-local mail to a "smarthost"
relay.  Rather, a backup MX host MUST be at least smart enough to
relay mail for the domain(s) in question to better (lower) preference
MX hosts.

The best way to do this, is to configure an explicit nexthop in 
default_transport, and be sure to leave relayhost empty. 

main.cf:
# MUST be empty, to avoid backup MX domain loops.
relayhost =
relay_domains = foo.com

# Regularly updated list of valid foo.com (and any other relay
# domain) recipients:
relay_recipient_maps = ...

# Replace "smarthost.example" with actual default relayhost.
default_transport = smtp:smarthost.example

Relay domains will use "relay_transport" (default "relay", which is
a clone of "smtp"), so will not in error use the smarhost.

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

[pfx] Re: content filter sends mail twice

[Viktor Dukhovni via Postfix-users]

On Sun, May 21, 2023 at 02:05:31PM -0400, Alex via Postfix-users wrote:

> Can I follow up on this? I can't figure out why always_bcc mail is being
> sent through the default content filter while mail designated for my
> domain-specific transport is sent through another in my multi-instance
> postfix config. I'd like the always_bcc user mail to still benefit from
> being filtered through amavis, but through the transport designed for the
> domain for which it was intended.

The BCC recipient is processed in much the same way as any other message
recipient.  The only special handling that comes to mind is DSN, where
this recipient is treated as if NOTIFY=NEVER were specified.

> local_transport = error:5.1.1 Mailbox unavailable
> default_transport = smtp:[127.0.0.1]:10024
> relay_transport = $default_transport
> virtual_transport = $default_transport
> transport_maps = ${indexed}transport

Perhaps the BCC recipient (domain) did not match any transport
table keys, but the real recipient did?

> 
> /etc/postfix-120/transport
> domain1.comalex:[127.0.0.1]:10029

What is the domain part of the always BCC address.

> May 21 13:40:12 cable postfix-120/qmgr[3714211]: 494948B53: from=<
> mysqlstud...@gmail.com>, size=3214, nrcpt=2 (queue active)

This message has two recipients, one original and one BCC.

> May 21 13:40:12 cable amavis[3558243]: (3558243-06) ESMTP [127.0.0.1]:10024
> /var/spool/amavisd/tmp/amavis-20230521T020900-3558243-jefENl_V: <
> mysqlstud...@gmail.com> ->  SIZE=3214 Received:
> from cable.example.com ([145.239.111.120]) by localhost (cable.example.com
> [127.0.0.1]) (amavis, port 10024) with ESMTP for ;
> Sun, 21 May 2023 13:40:12 -0400 (EDT)


The Bcc address  does not match
"domain1.com", and unsurprisingly went to the default transport.

> May 21 13:40:18 cable postfix/alex/smtp[3719703]: 494948B53: to=<
> jre...@domain1.com>, relay=127.0.0.1[127.0.0.1]:10029, delay=6.9,
> delays=1.2/0.02/0.01/5.7, dsn=2.0.0, status=sent (250 2.0.0 from
> MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 0671630014B43)

You neglected to share the other delivery log entry.  Presumably BCC
address via port 10024.

The BCC address does not "inherit" the transport entry of any particular
original recipient of the message, it gets resolved to a
transport:nexthop "naturally".

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

[pfx] Re: per-domain header/body checks?

[Viktor Dukhovni via Postfix-users]

On Sun, May 21, 2023 at 06:26:34PM -0400, Alex via Postfix-users wrote:

> I don't have any content filters set up in the front-end postfix. How do I
> connect the front-end postfix with the filters?

For per-domain message content modification you need to first "split the
envelope", so that each copy of the original message has recipients for
just one domain.  This is of course of the case already, because the
envelope was split by recipient domain at the source MTA, but some MTAs
can detect that multiple domains share the same MX host(s) and send a
single message for multiple recipient domains.

There are two ways to split the envelope:

- Use multiple (logical) MX hosts.

  * If the domain count is small enough, and you have sufficiently
many (IPv4) addresses, you can set up a separate front-end
instance for each domain.

- Use a single MX host, and do the content modification in
  multiple backend instances.

  * This requires a separate backend port(!) per-domain.  All
the backend instances can listen on different ports of the same
loopback IP addresses.

Outline:

* Multi-instance configuration with a single frontend instance
  receiving SMTP traffic from the public Internet on behalf of all the
  domains.

foo.example. IN MX 0 smtp.shared.example.
bar.example. IN MX 0 smtp.shared.example.
baz.example. IN MX 0 smtp.shared.example.

* Frontend instance (smtp.shared.example), splits the envelope:

main.cf:
# Listens on the public IP address
inet_interfaces = 192.0.2.1
relay_domains = foo.example, bar.example, baz.example
relay_recipient_maps = ...
transport_maps = inline:{
{ foo.example = scan:127.0.0.1:25001 }
{ bar.example = scan:127.0.0.1:25002 }
{ baz.example = scan:127.0.0.1:25003 }
}
default_transport = scan:127.0.0.1:25000

master.cf:
scan unix ... smtp
-o smtp_send_xforward_command=yes

* Backend instances implement per-domain message content modification:

"foo" instance:
main.cf:
inet_interfaces = 127.0.0.1
smtpd_authorized_xforward_hosts = 127.0.0.1
master.cf:
25001 inet ... smtpd

"bar" instance:
main.cf:
inet_interfaces = 127.0.0.1
smtpd_authorized_xforward_hosts = 127.0.0.1
master.cf:
25002 inet ... smtpd

"baz" instance:
main.cf:
inet_interfaces = 127.0.0.1
smtpd_authorized_xforward_hosts = 127.0.0.1
master.cf:
25003 inet ... smtpd

"default" instance: handles outbound messages, e.g. bounces,
or recipient domains that don't need custom processing.

main.cf:
inet_interfaces = 127.0.0.1
smtpd_authorized_xforward_hosts = 127.0.0.1
master.cf:
25000 inet ... smtpd

The content transformations can be per-backend milters, per-backend
content_filters, or just header/body checks if sufficient.  In each
backend instance the recipients will all be in the dedicated domain. 

You can also deploy multiple amavis or similar SMTP proxies to listen
on the 127.0.0.1:2500X ports, and do the content filtering "in-flight".

Always consider how bounces will be routed, and also locally generated
mail from cron, ...

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

[pfx] Re: delivery number question

[Viktor Dukhovni via Postfix-users]

On Fri, May 19, 2023 at 08:57:34AM +0800, Tom Reed via Postfix-users wrote:
> 
> 
> > On Thu, May 18, 2023 at 07:48:32PM +0800, Tom Reed via Postfix-users
> > wrote:
> >
> >> If a sender write a message which has N recipients in the same
> >> destination domain (say gmx.de), when postfix deliver this message to
> >> peer MTA, will it deliver one copy, or N copies?
> >
> > For a typical message the number of deliveries to a given domain is
> >
> > floor( #recipients /  )

FWIW, I should have said "ceiling" not "floor", but I think the intent
was clear.

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

[pfx] Re: per-domain sender_checks?

[Viktor Dukhovni via Postfix-users]

On Thu, May 18, 2023 at 07:07:55PM -0400, Alex via Postfix-users wrote:

> > Is there a way to control smtpd_recipient_restrictions on a per-domain
> > > basis [...]

To resolve the ambiguity, you might have said: "per *recipient* domain"

> If I interpret your instructions properly, this is kind of an as-needed
> fqdn bypass, when what I'm trying to do is allow non-fqdn senders just for
> certain recipient domains.

This time it is more clear:

main.cf:
pcre = pcre:${config_directory}/
smtpd_recipient_restrictions =
reject_unauth_destination,
check_recipient_access ${pcre}rcpt-checks.pcre
...

rcpt-checks:
/@example\.com$/ DUNNO
/@example\.org$/ DUNNO
/^/ reject_unknown_sender_domain

Unfortunately, we don't yet have a non-regexp map type that has a
default result.  This could be a variant of unionmap that takes the
first matching value instead of combining all values:

firstmatch:{ type1:name1, type2:name2, ..., static:{ default } }

With that, it'd be:

main.cf:
indexed = ${default_database_type}:${config_directory}/
smtpd_recipient_restrictions =
reject_unauth_destination,
check_recipient_access firstmatch:{
${indexed}rusd-optout,
static:reject_unknown_sender_domain
}
...

rusd-optout:
example.com DUNNO
example.org DUNNO

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

[pfx] Re: content filter sends mail twice

[Viktor Dukhovni via Postfix-users]

On Thu, May 18, 2023 at 09:20:38AM -0400, Alex via Postfix-users wrote:

> Maybe my issue is that the always_bcc user is going through a transport at
> all, and instead should just be delivered locally, or perhaps processed
> only by the local_transport? How can I do that?
> 
> I recall many years ago doing that, before I set up multi-instance postfix.

A not uncommon issue is that virtual alias expansion or other address
rewriting actions are performed twice, once on each side of a
content_filter.  This is covered in the "Advanced content filter:
requesting that all mail is filtered" section of:

http://www.postfix.org/FILTER_README.html#advanced_filter

(receive_override_options).

And of course you can always go multi-instance, and configure suitable
rewriting for the pre and post filter instances.

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

[pfx] Re: DANE and DNSSEC

[Viktor Dukhovni via Postfix-users]

On Thu, May 18, 2023 at 08:54:16PM +0200, Joachim Lindenberg via Postfix-users 
wrote:

> For Letsencrypt certificates I´d definitely go with 2 1 1
> 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D and
> optionally the R4 derivate and add their successors when these are
> about to expire, rather than 3 1 1 and change every two months.  Best

A well thought out "3 1 1 + 3 1 1" setup is IMHO more robust.  With "2 1 1", the
certificates occasionally expire, despite best intentions, and security is 
reduced
to TOFU, since ACME "proofs" boil down to an initial leap of faith.

That said, if you do go with "2 1 1", please look over:

https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html

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

[pfx] Re: DANE and DNSSEC

[Viktor Dukhovni via Postfix-users]

On Thu, May 18, 2023 at 09:22:34PM +0900, Byung-Hee HWANG via Postfix-users 
wrote:

> And now i added TLSA record for only *outbond* smtp server,
> .

It is also your secondary MX host:

https://stats.dnssec-tools.org/explore/?doraji.xyz

the primary MX host does not yet have TLSA records.  The detailed
status is:

doraji.xyz. IN MX 1871 yw-0919.doraji.xyz.
doraji.xyz. IN MX 1895 yw-1204.doraji.xyz.
_25._tcp.yw-0919.doraji.xyz. IN TLSA ? ; NXDOMAIN
_25._tcp.yw-1204.doraji.xyz. IN TLSA 3 1 1 
b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f
  yw-1204.doraji.xyz[185.17.255.72]: pass: TLSA match: depth = 0, name = 
yw-1204.doraji.xyz
TLS = TLS13 with AES256GCM-SHA384,X25519,PubKeyALG_RSA
name = yw-1204.doraji.xyz
depth = 0
  Issuer CommonName = R3
  Issuer Organization = Let's Encrypt
  notBefore = 2023-03-20T06:03:54Z
  notAfter = 2023-06-18T06:03:53Z
  Subject CommonName = yw-1204.doraji.xyz
  pkey sha256 [matched] <- 3 1 1 
b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f
depth = 1
  Issuer CommonName = ISRG Root X1
  Issuer Organization = Internet Security Research Group
  notBefore = 2020-09-04T00:00:00Z
  notAfter = 2025-09-15T16:00:00Z
  Subject CommonName = R3
  Subject Organization = Let's Encrypt
  pkey sha256 [nomatch] <- 2 1 1 
8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
depth = 2
  Issuer CommonName = DST Root CA X3
  Issuer Organization = Digital Signature Trust Co.
  notBefore = 2021-01-20T19:14:03Z
  notAfter = 2024-09-30T18:14:03Z
  Subject CommonName = ISRG Root X1
  Subject Organization = Internet Security Research Group
  pkey sha256 [nomatch] <- 2 1 1 
0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3
  yw-1204.doraji.xyz[2a03:ebc0:5000:12::10]: pass: TLSA match: depth = 0, 
name = yw-1204.doraji.xyz
TLS = TLS13 with AES256GCM-SHA384,X25519,PubKeyALG_RSA
name = yw-1204.doraji.xyz
depth = 0
  Issuer CommonName = R3
  Issuer Organization = Let's Encrypt
  notBefore = 2023-03-20T06:03:54Z
  notAfter = 2023-06-18T06:03:53Z
  Subject CommonName = yw-1204.doraji.xyz
  pkey sha256 [matched] <- 3 1 1 
b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f
depth = 1
  Issuer CommonName = ISRG Root X1
  Issuer Organization = Internet Security Research Group
  notBefore = 2020-09-04T00:00:00Z
  notAfter = 2025-09-15T16:00:00Z
  Subject CommonName = R3
  Subject Organization = Let's Encrypt
  pkey sha256 [nomatch] <- 2 1 1 
8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
depth = 2
  Issuer CommonName = DST Root CA X3
  Issuer Organization = Digital Signature Trust Co.
  notBefore = 2021-01-20T19:14:03Z
  notAfter = 2024-09-30T18:14:03Z
  Subject CommonName = ISRG Root X1
  Subject Organization = Internet Security Research Group
  pkey sha256 [nomatch] <- 2 1 1 
0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3

Since your certificate is from Let's Encrypt, you've probably configured
automatic renewal.  If you haven't also implemented *monitoring* of your
DANE TLSA configuration that checks whether the TLSA records match the
certificate chain, you should do that immediately, and ideally before
publishing TLSA records for any servers carrying "non-test" traffic.

You can publish TLSA records for some test host with a self-signed
cert, and check monitoring detects incorrect TLSA records when
mismatched TLSA records are configured (and is not complaining
when the TLSA records are correct).

You then also need to make sure that your certificate rollover process
is robust, and either keeps the public key unchanged, or you pre-publish
matching TLSA records for future keys alongside current keys.

Setting up inbound DANE requires operational diligence.  Do consider
implemting DANE, but not as a fashion statement, rather only because
you understand how to coordinate certificate management with DANE
TLSA record upkeep.

-- 
Viktor.

P.S. Your certificate chain from Let's Encrypt includes a cross-cert for
the ISRG root from the expired DST root.  This is obsolete, if using
"certbot", make sure your "renewal.conf" includes the "reuse_key" and
"preferred_chain" settings below in the "[renewalparams]" setction.

[renewalparams]
reuse_key = True
preferred_chain = ISRG Root X1
...

adjust accordingly if using some other ACME client.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: delivery number question

[Viktor Dukhovni via Postfix-users]

On Thu, May 18, 2023 at 07:48:32PM +0800, Tom Reed via Postfix-users wrote:

> If a sender write a message which has N recipients in the same
> destination domain (say gmx.de), when postfix deliver this message to
> peer MTA, will it deliver one copy, or N copies?

For a typical message the number of deliveries to a given domain is

floor( #recipients /  )

where _destination_recipient_limit

or else (if the former is not defined):

$default_destination_recipient_limit

The latter defaults to 50.  Under much less common conditions, for
messages with many thousands of recipients, the less-popular
destinations may be under-represented in each batch of recipients read
by the queue manager, resulting in fewer recipients than the limit in
each delivery, despite presence of additional recipients in later
batches.

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

[pfx] Re: per-domain sender_checks?

[Viktor Dukhovni via Postfix-users]

On Tue, May 16, 2023 at 06:54:47PM -0400, Alex wrote:

> > The problems with their DNS are:
> >
> > - ns1.apr.gov.rs: EDNS(0) option intolerance, but returns
> >   FORMERR, so fallback to non-EDNS queries should (and does) work.
> >   [...]
> >   Disabling use of cookies in your BIND configuration would suffice.
> > [...]
> > Turn off coookies for queries to this domain, or generally.
> >
> 
> Turning off cookies for this server solved the problem, but it's not a very
> scalable method. I realize this isn't bind-users, but can I ask if there is
> a way to fallback to not using cookies, instead of having to create a
> server {} section for each broken server?
> 
> I have a bind-9.16.38 system and it's apparently able to query these broken
> servers without issue.

Perhaps BIND 9.18 does not fall back to non-EDNS queries as willingly,
and when using EDNS(0), assumes that cookies will be tolerated
(typically simply ignored, per RFC requirement for unknown/unsupported
options).  Your question does indeed belong on bind-users.

If you do find out something actionable, you can post the solution here.

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

[pfx] Re: per-domain sender_checks?

[Viktor Dukhovni via Postfix-users]

On Tue, May 16, 2023 at 11:27:52AM -0400, Alex via Postfix-users wrote:

> > > $ host info.apr.gov.rs
> > > Host info.apr.gov.rs not found: 2(SERVFAIL)
>
> There's definitely a problem with their name servers, but it also seems my
> version of bind is not permissive enough for such failures, although my
> bind-9.16.38 system is, using the same configuration.

The problems with their DNS are:

- ns1.apr.gov.rs: EDNS(0) option intolerance, but returns
  FORMERR, so fallback to non-EDNS queries should (and does) work.

$ dig -t a +nocomment +nocookie +nostats +nocmd +norecur +nocl +nottl 
@ns1.apr.gov.rs info.apr.gov.rs.
;info.apr.gov.rs.   IN A
info.apr.gov.rs.A   195.178.56.17

  Disabling use of cookies in your BIND configuration would suffice.

- ns2.apr.gov.rs: Supports EDNS(0), but returns SERVFAIL to all
  queries.

$ dig -t a +noall +comment +norecur +noedns +nocl +nottl 
@ns2.apr.gov.rs info.apr.gov.rs.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 42971
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

> Public name servers also appear to have no issues. I'm currently
> researching these FORMERR messages.

Turn off coookies for queries to this domain, or generally.

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

[pfx] Re: how to implement plus address

[Viktor Dukhovni via Postfix-users]

On Sat, May 13, 2023 at 06:06:59PM +0800, Tom Reed via Postfix-users wrote:

> How to setup dovecot then? Thank you.

In cases where all recipient addresses undergo some form of virtual or
local alias rewriting before being handed off for delivery to dovecot,
you can arrange for the address extension to be dropped during rewriting
if not needed for non-default delivery "folder" selection.

I have:

propagate_unmatched_extensions =

which means that extensions are dropped during both virtual(5) alias and
local aliases(5) expansion.  But I also use virtual(8), rather than
Dovecot LMTP, to deliver mail to IMAP users and the virtual(8) delivery
agent also knows how to deal with address extensions.

So there are many choices, including configuring Dovecot to recognise
extensions, but that's a question for the dovecot list as already
suggested.

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

[pfx] Re: postfix ports questions

[Viktor Dukhovni via Postfix-users]

On Sat, May 13, 2023 at 06:51:30PM +0800, Tom Reed via Postfix-users wrote:

> Can I setup only port 25 open to the world? If port 465/587 are filtered
> by iptables which only permit internal users to connect, does this make
> sense to external MTAs (such as google, MS's)?

You do not need to expose ports other than 25 to outside sources (you
don't have to operate anything on those ports except as needed by your
own users).

For the blocked ports, your firewall should typically reply with a TCP
RST, rather than just drop packets.  This could at least be useful on
the "ident" port:

auth113/tcpident tap#Authentication Service

in case some "qmail" systems are still expecting it to be available.

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

[pfx] Re: question: "said: 550 Mail was identified as spam"

[Viktor Dukhovni via Postfix-users]

On Sat, May 13, 2023 at 09:32:14AM +0800, l...@cndns.com wrote:

> We did not use a service like milter, but simply used postfix relays at
> both ends, nor did we use spamassassin. 

Retelling in your own words what you believe happened won't enable
anyone to help you. :-(

For actual help, follow the instructions at:

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

and post logs of all relevant mail deliveries, and the content of any
bounces (full headers of the bounce and returned message, leaving out
only the attached body of the original message).

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

[pfx] Re: mua config; with user; not with user@domain

[Viktor Dukhovni via Postfix-users]

On Fri, May 12, 2023 at 12:55:26PM -0400, Wietse Venema via Postfix-users wrote:

> NON-DEBUG logging for a Postfix SMTP session that shows the poblem.
> 
> Output from the command "postconf -nf". Be sure to sanitize passwords
> or othre private infprmation.

In other words, don't paste any of the "base64" data logged by the SASL
AUTH commands.  Example:

$ printf '\0luser\0sesame' | openssl base64
AGx1c2VyAHNlc2FtZQ==

The base64 output is no "encrypted", and is trivial to decode

$ printf "%s\n" AGx1c2VyAHNlc2FtZQ== | openssl base64 -d | od -An -c
  \0   l   u   s   e   r  \0   s   e   s   a   m   e

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

[pfx] Re: question: "said: 550 Mail was identified as spam"

[Viktor Dukhovni via Postfix-users]

On Fri, May 12, 2023 at 03:32:45PM +0800, lty--- via Postfix-users wrote:
>  
> 
> Hello 
> 
> The mail is transferred to the postfix service of the relay server
> through the postfix service. Occasionally, the mail will be rejected and
> the message "said: 550 Mail was identified as spam" will be returned. I
> checked the source code and found no similar error message! I cannot
> reproduce this problem, Because it is sporadic. 

The *REMOTE* server rejected the message, with an SMTP response
in which it "said" that the mail was identified as spam.

Since the problem was reported by the remote system, it is not
surprising that you won't find the message in the Postfix
source code.

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

[pfx] Re: TLS Library Problem? (SSL_accept error from ...)

[Viktor Dukhovni via Postfix-users]

On Mon, May 08, 2023 at 04:22:29PM -0500, E R via Postfix-users wrote:

> Thank you so much for the suggestion to review the crypto setting as this
> indeed a RedHat based distribution.  I confirmed it is set to "default"
> which means  “The default system-wide cryptographic policy level offers
> secure settings for current threat models. It allows the TLS 1.2 and 1.3
> protocols, as well as the IKEv2 and SSH2 protocols. The RSA keys and
> Diffie-Hellman parameters are accepted if they are at least 2048 bits long.”

Right, but the meaning of "DEFAULT" (e.g., whether SHA-1 signatures are
accepted in certificates and TLS messages) may vary from release to
release.  In Fedora 36 default allows SHA-1 signatures, but I've seen
documentation that suggests that in RHEL the default policy is more
strict.

You should be able to set your policy to allow SHA1:

# update-crypto-policies --set DEFAULT:SHA1

(no need to reboot, Postfix processes that use OpenSSL are not
long-lived).

> The [I assume client] system in question was located and is an older
> than dirt system running a LONG obsolete version of Gentoo.  My best
> guess is that the system was accidentally powered on during a
> generator test due to a former employee not properly decommissioning
> the system many years ago.  The configuration change that I wrote
> about (disabling the STARTTLS keyword for the IP address) did allow my
> Postfix gateways to route email without any issue.  I am going to
> guess the age or configuration of the system is to blame.  I have
> started the official process to pull the plug on the server so it can
> be wiped and recycled.

The system was very likely using TLS 1.0, and had no support for TLS 1.2
or later, so yes, quite old by now.

You may still consider whether disabling SHA1 signatures is really the
right policy for an MTA.  If you've never seen that error message in
your logs apart from the client in questions, perhaps the default is
good enough.  Otherwise, enabling SHA1 will in practice be fine, and
enable some legacy systems to establish TLS connections that would
otherwise have to fall back to cleartext (or fail to deliver mail).

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

[pfx] Re: working around crypto policies turned up to 11

[Viktor Dukhovni via Postfix-users]

On Mon, May 08, 2023 at 06:13:25PM -0400, Wietse Venema via Postfix-users wrote:

> We're thinking of adding a few new settings to the stable Postfix
> releases that allow Postfix to regain some control over crypto
> policies that do not necessarily improve matters for SMTP where
> the main result would be more plaintext communication.

> With stable releases, it would not be approprriate to introduce a
> boatload of features, but plausible candidates are:
> 
> tls_config_file = default | none(*) | /path/to/file
>   (*)only OpenSSL 1.1.b and later

Minor correction, the base OpenSSL release that supports configuration
file overrides is "1.1.1b", rather than "1.1.b".

- The minimum OpenSSL version supported by Postfix 3.6 and later is 1.1.1.
- The OpenSSL version in which RedHat started introducing strict crypto
  policies is OpenSSL 3.0.

This means that:

- If you're still using OpenSSL 1.0.2 (with Postfix <= 3.5) you
  probably don't need to override the system-wide openssl.cnf file.
  Though it may be possible to use:

import_environment =
... default value from "postconf -d"...
OPENSSL_CONF=/some/file

  An empty file would be equivalent to "none".

- If you're using OpenSSL 1.1.1 or 1.1.1a, you also probably don't
  need to override the system-wide openssl.cnf file.  Same
  work-around as before, or set the application name, and add
  appropriate application settings in the system-wide file.

- If you're using OpenSSL 1.1.1b or later, and in particular 3.0
  or, especially on a RedHat or Fedora system, you may choose to
  override the system-wide configuration file or the application
  name.  Then, overly strict cryptographic policy will not result
  in unnecessary downgrades to cleartext in opportunistic TLS.

We'll probably later have to extend support for tweaking additional
TLS-related settings through the "SSL_CONF" API, though that will have
the downside that non-expert users may end up cargo culting settings
that do more harm than good.  I'll try to discourage this as much
as possible, but the target audience will be those who know what
they are doing, or are following sound advice.

One goal may be to make some of the crypto hardening conditional on the
TLS security level, which means different settings for different levels.

Hopefully more on this as 3.9 snapshots evolve.

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

[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros

[Viktor Dukhovni via Postfix-users]

On Mon, May 08, 2023 at 12:33:31PM +1000, Sean Gallagher via Postfix-users 
wrote:

> > [ Yes, one could also craft "classless" access(5) tables, ... and rely
> >only on explicit transport(5) table entries, opting out of all the
> >taxonomy that makes it easier to reason about Postfix mail routing,
> >but this is not a good idea, and users advanced enough to do that
> >aren't the audience for the README tutorials. ]
> 
> With all due respect, there is no "advanced user" documentation, the 
> advanced users are reading the READMEs just like everyone else - or the 
> source code.

The "advanced users" are doing OK between the README tutorials, the
postconf(5) parameter docs and the source code.  There's also the
book by Patrick and Ralf as well as the O'Reilly book.

One thing that's under-documented from an advanced user perspective
is:

- String, hostname and address match lists.
- Which parameters are match lists and of which type.

The description of match lists could be in DATABASE_README, with
references from the various parameters as appropriate.  Care to
contribute some text?

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

[pfx] Re: postfix and ssl provlem

[Viktor Dukhovni via Postfix-users]

On Mon, May 08, 2023 at 01:29:55PM +0200, natan via Postfix-users wrote:

> I have some problem with cert - user who connect via 465
> 
> postfix/smtps/smtpd[6901]: warning: TLS library problem: 
>  error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:
>  ../ssl/record/rec_layer_s3.c:1544:SSL alert number 48:
> 
> Cert is new (renew) and  openssl x509 -in ... and key is ok
> server and client not connect via ssl3

The client cannot validate your server's certificate chain.
Perhaps you've deployed just the leaf certificate, rather
than a "chain" with the leaf certificate plus intermediate
issuing CA?

https://datatracker.ietf.org/doc/html/rfc8446#page-89

   unknown_ca:  A valid certificate chain or partial chain was received,
  but the certificate was not accepted because the CA certificate
  could not be located or could not be matched with a known trust
  anchor.

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

[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros

[Viktor Dukhovni via Postfix-users]

On Mon, May 08, 2023 at 11:00:55AM +1000, Sean Gallagher via Postfix-users 
wrote:

> check_rcpt_maps() in smtpd_check.c first looks for the recipient in 
> rcpt_canon_mapsand virt_alias_maps, that's the class-less part. Then it 
> classifies the recipient domain and checks the relevant recipient table 
> - that's the class-full part.

One could also turn off recipient validation entirely, and Postfix would
still have meaninful address classes, because these are the basis of
transport resolution and relay control.

Adding a recipient to virtual_alias_maps DOES NOT make Postfix accept
mail for the recipient from untrusted senders, for that the domain would
have to be listed in one of the address classes matched by
permit_auth_destination.

[ Yes, one could also craft "classless" access(5) tables, ... and rely
  only on explicit transport(5) table entries, opting out of all the
  taxonomy that makes it easier to reason about Postfix mail routing,
  but this is not a good idea, and users advanced enough to do that
  aren't the audience for the README tutorials. ]

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

[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros

[Viktor Dukhovni via Postfix-users]

On Mon, May 08, 2023 at 09:55:28AM +1000, Sean Gallagher via Postfix-users 
wrote:

> Q: how would an entry in virtual_alias_maps like
> localpart@$virtual_alias_domains localpart@$virtual_alias_domains be
> handled?
> A: It would stay in $virtual_alias_domains and be handed to 
> {$transport_maps, $default_transport} ???

No.  It is handed to the "error" transport, which will bounce the
recipient.

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

[pfx] Postfix vs. RedHat/Fedora crypto policies

[Viktor Dukhovni via Postfix-users]

On Fri, May 05, 2023 at 08:28:48PM -0400, Viktor Dukhovni via Postfix-users 
wrote:

> If your system is a RHEL or recent Fedora or similar system, or perhaps
> by now other distributions have joined the club, then you'll to find the
> relevant crypto policy file and dial it down a bit (on an MTA doing
> opportunistic TLS, RSA with SHA1 is better than cleartext).

This is looking increasingly likely, setting the crypto policy on
Fedora 36 to "DEFAULT:NO-SHA1", and disabling the anon-DH ciphers,
I observe:

$ /usr/sbin/posttls-finger -c -Lsummary,ssl-debug -o 
tls_medium_cipherlist='DEFAULT:@SECLEVEL=0' -lmay -p TLSv1 "[$(uname -n)]"
posttls-finger: SSL_connect:before SSL initialization
posttls-finger: SSL_connect:SSLv3/TLS write client hello
posttls-finger: SSL_connect:SSLv3/TLS write client hello
posttls-finger: SSL_connect:SSLv3/TLS read server hello
posttls-finger: SSL_connect:SSLv3/TLS read server certificate
posttls-finger: SSL3 alert write:fatal:internal error
posttls-finger: SSL_connect:error in error
posttls-finger: SSL_connect error to ... -1
posttls-finger: warning: TLS library problem: error:0398:digital 
envelope routines::invalid digest:crypto/evp/m_sigver.c:343:
posttls-finger: warning: TLS library problem: error:0A080006:SSL 
routines::EVP lib:ssl/statem/statem_clnt.c:2284:

The default setting of "tls_medium_cipherlist" enables and prefers
"aNULL" ciphers, for which the key exchange is not signed (with a
combined SHA1, MD5 PRF in TLS 1.0, IIRC), and the handshake succeeds.

In terms of decoupling Postfix from unfit for purpose system-wide crypto
policies, the below patch appears to be minimally sufficient, but a more
systematic fix would be to make the configuration file selectable (none
or an explicit choice), and for various "SSL_CONF" settings to be
accessible via suitable main.cf overrides.  I had hoped to do that circa
Postfix 3.6, but did not find the requisite cycles.

-- 
Viktor.

--- src/tls/tls_client.c
+++ src/tls/tls_client.c
@@ -682,6 +682,11 @@ TLS_APPL_STATE *tls_client_init(const 
TLS_CLIENT_INIT_PROPS *props)
  */
 tls_check_version();
 
+/*
+ * Opt out of default system-wide configuration settings
+ */
+OPENSSL_init_crypto(OPENSSL_INIT_NO_LOAD_CONFIG, NULL);
+
 /*
  * Create an application data index for SSL objects, so that we can
  * attach TLScontext information; this information is needed inside
--- src/tls/tls_server.c
+++ src/tls/tls_server.c
@@ -420,6 +420,11 @@ TLS_APPL_STATE *tls_server_init(const 
TLS_SERVER_INIT_PROPS *props)
  */
 tls_check_version();
 
+/*
+ * Opt out of default system-wide configuration settings
+ */
+OPENSSL_init_crypto(OPENSSL_INIT_NO_LOAD_CONFIG, NULL);
+
 /*
  * First validate the protocols. If these are invalid, we can't continue.
  */
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: TLS Library Problem? (SSL_accept error from ...)

[Viktor Dukhovni via Postfix-users]

On Fri, May 05, 2023 at 08:28:48PM -0400, Viktor Dukhovni via Postfix-users 
wrote:

> You should of course also share 
> (https://www.postfix.org/DEBUG_README.html#mail)
> 
> $ postconf -nf
> $ postconf -Mf
> 
> without any changes in whitespace, including line breaks.  Attaching
> these as text files may be simplest if your mail client won't coöperate.

And, if applicable, post the content of:

/usr/share/crypto-policies/DEFAULT/opensslcnf.txt

Which on a sample Fedora36 system holds:

CipherString = 
@SECLEVEL=2:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8
Ciphersuites = 
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256
TLS.MinProtocol = TLSv1.2
TLS.MaxProtocol = TLSv1.3
DTLS.MinProtocol = DTLSv1.2
DTLS.MaxProtocol = DTLSv1.2
SignatureAlgorithms = 
ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224

[openssl_init]
alg_section = evp_properties

[evp_properties]
rh-allow-sha1-signatures = yes

Postfix (at least in a default configuration) is not affected by:

CipherString
TLS.MinProtocol
TLS.MaxProtocol
DTLS.MinProtocol
DTLS.MaxProtocol

But currently has no controls to override:

# TLS 1.3 ciphersuites (not a priority to fine-tune)
Ciphersuites = ...

# TLS 1.2 signature algorithm negotiation (the RH list is fine)
SignatureAlgorithms = ...

# If this is set to "no", TLS 1.0 key exchange is likely to break.
# In some cases certificate verification may break.
rh-allow-sha1-signatures = yes

I don't even know whether RedHat exposes any mechanisms for applications
to opt-out of crypto policy and use only application-driven OpenSSL
configuration.  This is should perhaps be looked into in the Postfix 3.9
timeframe.

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

[pfx] Re: TLS Library Problem? (SSL_accept error from ...)

[Viktor Dukhovni via Postfix-users]

On Fri, May 05, 2023 at 06:55:23PM -0500, E R via Postfix-users wrote:

> postfix/smtpd[1234567]: SSL_accept error from xxx.xxx.xxx[yyy.yyy.yyy.yyy]: -1
> postfix/smtpd[1234567]: warning: TLS library problem:
>   error:0398:digital envelope routines::invalid 
> digest:crypto/evp/m_sigver.c:343:
> postfix/smtpd[1234567]: warning: TLS library problem:
>   error:0A0C0103:SSL routines::internal error:ssl/statem/statem_srvr.c:2684:

This problem may be worth further analysis.  It appears that OpenSSL has
chosen a signature algorithm (public key algorithm + digest method, e.g.
RSA with SHA256, ...) at the TLS layer, but failed to initialise a
signature context at the crypto API layer.  This is odd, because the
known TLS layer combinations should map to known crypto layer
primitives.

Are you on a RedHat system perhaps?  RedHat's latest releases have
turned up crypto policy to "11", and may refuse to, for example, support
RSA with SHA1.  The remote client may have one of the really dated TLS
stacks that doesn't know how to do anything better.

If your system is a RHEL or recent Fedora or similar system, or perhaps
by now other distributions have joined the club, then you'll to find the
relevant crypto policy file and dial it down a bit (on an MTA doing
opportunistic TLS, RSA with SHA1 is better than cleartext).

Similar considerations may apply not only to MTAs but also to validating
DNS resolvers, and perhaps other applications.

The various distributions may publish instructions on recommnded ways to
tune the crypto policy.

If all the above is false lead, then the problem is more mysterious, and
perhaps a PCAP file capturing a failed handshake would be a good next
step.

You should of course also share (https://www.postfix.org/DEBUG_README.html#mail)

$ postconf -nf
$ postconf -Mf

without any changes in whitespace, including line breaks.  Attaching
these as text files may be simplest if your mail client won't coöperate.

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

[pfx] Re: inet_interfaces documentation

[Viktor Dukhovni via Postfix-users]

On Fri, May 05, 2023 at 02:34:53PM +1000, Sean Gallagher via Postfix-users 
wrote:

> That makes sense, and is exactly what I would expect, but it still needs 
> to be documented.
> 
> But it does raise another question in my mind. Many places in the 
> documentation state that the "Local" domain class consists of $mydomain, 
> $inet_interfaces and $proxy_interfaces.

Correct, when the recipient is an address literal user@[ip].

> Presumably any listen address specified in master.cf would also be in
> the "Local" domain.

Actually, no, that's not the case, sorting of recipients into address
classes should not (and does not) depend on the message entry point.

This classification is performed by trivial-rewrite(8), which is not
aware of or sensitive to the list endpoints of various master.cf
services, its decisions are based on inet_interfaces and
proxy_interfaces alone (one could have custom overrides of these
for the trivial-rewrite service in master.cf, if feeling sufficiently
masochistic, but really, don't).

Complex configuratoins with multiple views of what's local and what's
not are best handled via multiple-instances, where each instance listens
on and considers local exactly the address in inet_interfaces, and there
are no explicit host/address-specific entries in master.cf.


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

[pfx] Re: inet_interfaces documentation

[Viktor Dukhovni via Postfix-users]

On Fri, May 05, 2023 at 01:57:19PM +1000, Sean Gallagher via Postfix-users 
wrote:

> > This is rarely what you want.  I'd be inclined to require that the
> > "inet_interfaces" parameter be non-empty (though it could still be
> > effectively empty as a list by setting it to be a mixture of spaces and
> > at least one comma).
>
> You need to be careful what "empty" means. If inet_interfaces has only 
> IPv4 addresses and inet_protocols includes "ipv6", then it is 
> effectively "empty" from the ipv6 point of view, but it is clearly not 
> "empty"

That's a non-issue.  With that, Postfix will only listen on IPv4 as
specified, when the "inet" endpoint only specifies the port.

In other words:

- The *primary* purpose of "inet_interfaces" is to specify the
  listen IP address for services with no explicit hostname or
  ip address specified.

- A secondary, convenience function, is that the same addresses,
  when exactly one non-loopback, per address family, are also
  used as the default bind address for the associated family.

An empty setting is fine for outbound connections (no fixed address),
but not so good for inbound services unless you really mean to always
use explicit hostname/ip prefixes for all "inet" services and want
"postfix start" to fail if any are lax.

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

[pfx] Re: inet_interfaces documentation

[Viktor Dukhovni via Postfix-users]

On Fri, May 05, 2023 at 02:08:29PM +1200, Peter via Postfix-users wrote:

> On 5/05/23 11:33, Wietse Venema via Postfix-users wrote:
> > An empty inet_interfaces means that there is no constraint for the
> > SMTP client source IP address. I am adding some text for that.
> 
> I think the question is, what effect does it have on the server 
> listening address.  This is from inet_listen.c:
> 
> /* .IP addr
> /*  The communication endpoint to listen on. The syntax is "host:port".
> /*  Host and port may be specified in symbolic form or numerically.
> /*  A null host field means listen on all network interfaces.
> 
> So I would assume from that setting inet_interfaces to empty has the 
> same effect as setting it to all (it will listen on all interfaces)?

No, it does not.  Rather, it leaves zero listener addresses enabled,
which only works if all "inet" services are disabled or all use explicit
IP endpoints:

May 05 03:43:45 amnesiac postfix/postfix-script[2812173]: starting the 
Postfix mail system
May 05 03:43:45 amnesiac postfix/master[2812175]: fatal: 
/etc/postfix/master.cf: line 12: no valid IP address found: smtp
May 05 03:43:47 amnesiac postfix/postfix-script[2812176]: fatal: mail 
system startup failed

This is rarely what you want.  I'd be inclined to require that the
"inet_interfaces" parameter be non-empty (though it could still be
effectively empty as a list by setting it to be a mixture of spaces and
at least one comma).

This is roughly what I expected, but did had not yet checked.

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

[pfx] Re: inet_interfaces documentation

[Viktor Dukhovni via Postfix-users]

On Fri, May 05, 2023 at 07:01:03AM +1000, Sean Gallagher via Postfix-users 
wrote:

> Specify "all" to receive mail on all network interfaces (default), 
> "loopback-only" to receive mail on loopback network interfaces only 
> (Postfix version 2.2 and later) or leave blank to disable the reception 
> of email (i.e. outgoing service only).

Actually, mail can still be received when the master.cf entry specifies
an explicit address:port.  There is just no implicit wildcard listen
address (or is a configuration error reported?).  I don't know what
actually happens when "inet_interfaces" is explicitly blank.

To actually disable inet services, use the "master_service_disable"
parameter.

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

[pfx] Re: Question on the CNAME

[Viktor Dukhovni via Postfix-users]

On Thu, May 04, 2023 at 01:02:14AM +, Ken Peng via Postfix-users wrote:

> I am just not sure, for this domain SpaceMail.com, who has a CNAME to
> CDN for the root domain, every query to this domain will get a CNAME.
> for instance,
> 
> $ dig spacemail.com mx +nocmd +noall +answer
> spacemail.com.60  IN  CNAME   
> spacemail.com.cdn.cloudflare.net.
> 
> $ dig spacemail.com txt +nocmd +noall +answer
> spacemail.com.47  IN  CNAME   
> spacemail.com.cdn.cloudflare.net.

Yes, so called "zone apex cnames" are a common abuse of DNS requirements
to meet customer demand until "SVCB" and "HTTPS" records eventually take
over that rôle.

> How does it get mail then? incoming mail was handled by
> spacemail.com.cdn.cloudflare.net?

MX records are not required to receive email, just A and sometimes even
just  records are sufficient.

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

[pfx] Re: inet_interfaces documentation

[Viktor Dukhovni via Postfix-users]

On Wed, May 03, 2023 at 12:48:28PM -0400, Wietse Venema via Postfix-users wrote:

> I updated the inet_interfaces documentation anmd clarified its
> relationship with smtp_bind*_address and system-chosen source IP
> addresses.
> 
>   Wietse
> 
>When smtp_bind_address and/or smtp_bind_address6 are not specified, the
>inet_interfaces setting may constrain the source IP  address  for  out-
>bound  connections over IPv4 and/or IPv6. Support for IPv6 is available
>in Postfix version 2.2 and later.
> 
>o  When inet_interfaces specifies one IPv4 address, and that is not
>   a  loopback  address,  the  Postfix SMTP client uses that as the
>   source address for outbound IPv4 connections.

I would perhaps change "one IPv4 address" to "only one IPv4 address
(along with zero or more IPv6 addresses)", to make it crystal clear
that the IPv4 behaviour is independent of the presence or absence of
any IPv6 addresses on the list.  The parenthetical clause is perhaps
redundant if a careful reader would infer from "only one IPv4" that
this does not restrict the count of IPv6 addresses, while "specifies
one IPv4 address" could be read to mean also no IPv6 addresses.

Though perhaps this level of attention to phrasing is only applicable in
Talmud scholarship...

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

[pfx] Re: relocated: Allow custom message

[Viktor Dukhovni via Postfix-users]

On Wed, May 03, 2023 at 02:53:06PM +0200, Paul Menzel via Postfix-users wrote:

> Some of our users, that relocate, ask for a custom message over the 
> current one:
> 
>  user has moved to new_location
> 
> For example:
> 
>  This address is out of service. For business please contact 
>  funct...@company.example.net, or n...@private.example.net for private 
>  contact.
> 
> I guess, it could be reworded to
> 
>  user has moved to n...@private.example.net, please contact
>  funct...@company.example.net for business
> 
> and use the current mechanism.
> 
> Could a third column for a custom message be added to satisfy everybody?

There's no need, a "relocated" entry is just a shorthand for a
user-specific transport table entry.  In the full transport table you
can add whatever string you want.

user@acme.example   error:5.1.6 This address is out of service. For business
please contact 
funct...@company.example.net, or
n...@private.example.net for private 
contact.

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

[pfx] THREAD CLOSED: (was: Contradicting Postfix documentation)

[Viktor Dukhovni via Postfix-users]

On Wed, May 03, 2023 at 02:57:34PM +1000, Sean Gallagher via Postfix-users 
wrote:

> Documentation can always be improved but there is nothing wrong with the 
> program itself in this respect.

We can close this thread.  The OP's membership in the list has been
terminated for uncivil behaviour.  If the OP rejoins, any repeats will
be dealt with more promptly.

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

[pfx] Re: Contradicting Postfix documentation

[Viktor Dukhovni via Postfix-users]

On Wed, May 03, 2023 at 04:57:57AM +0200, Kolusion K via Postfix-users wrote:

> Its not naive, its a fact- Postfix is broken. The inet_interfaces
> parameter is described in the documentation as making Postfix use only
> the interfaces listed for the parameter. In reality, Postfix ignores
> the parameter by using network interfaces that are not listed.

[ The hubris is grating.  If you plan to stick around on the list, it
  would be best to start cutting back... ]

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

When inet_interfaces specifies just one IPv4 and/or IPv6 address
that is not a loopback address, the Postfix SMTP client will use
this address as the IP source address for outbound mail. Support
for IPv6 is available in Postfix version 2.2 and later. 

Note the "and/or", in particular there can be one of each, and each
affects only connections made via the associated protocol.  Connections
made via the either protocol are of course not affected by the choice of
primary address for the other.  This could be made a bit more explicit,
but Postfix is behaving as intended.

Not everything you find unintuitive is necessarily a software or even a
documentation bug.  Though requests (rather than demands) for
documentation clarification may, when justified, elicit changes in
the text, not just clarifying on-list commentary.

> There is nothing mentioned in the Postfix documentation under the
> inet_interfaces parameter section that says the inet_interfaces
> parameter is for IPv4 only and that it will not have an effect on IPv6
> interfaces. That claim is your fairy tale.

It isn't for IPv4 only, it is for either or both protocols. The
overloading of inet_interfaces as a default source of "smtp_bind_adress"
and/or "smtpd_bind_address6" is a convenience that applies in limited
circumstances (exactly one "public" IP address for the associated address
family).  To be sure to set a bind address use the associated dedicated
parameters.

> Postfix needs to be patched so that the value of the inet_interfaces
> parameter is obeyed regardless of whether or not IPv6 (or other IP
> versions?) is enabled.

It is obeyed as intended, on a per-address-family basis.  If you want
just one address family, then you need to explicitly disable the other.

Listing only IPv4 or only IPv6 addresses in inet_interfaces leaves the
other protocol family unconstrained.  This is a feature, not a bug.

> Disabling IPv6 probably isn't an acceptable workaround anyway.

But that's exactly what you naîvely expected inet_interfaces to do,
so clearly it must be acceptable in your use case.

> What happens if both an IPv4 and IPv6 IP address is listed? Postfix
> may still use other network interfaces not listed (IP addresses).

If IPv6 is disabled, then IPv6 elements of inet_interfaces don't apply.
I don't recall whether they are then ignored, or a configuration error
is reported.

> Changing the parameter name wouldn't be a bad idea either seeing
> parameter values are actually IP addresses and not interface names, as
> the parameter name suggests.

That'd be a invalidation of long-standing practice for little gain.
In many cases there's just one address per interface and address
selection on a multi-homed host amounts to interface selection.

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

[pfx] Re: inbound failures only from outbound.protection.outlook.com. Cert issue in this log?

[Viktor Dukhovni via Postfix-users]

On Tue, May 02, 2023 at 07:03:55PM -0400, PGNet Dev via Postfix-users wrote:

> > Also look into other possibilities, the DST Root issue is a bit of a
> > longshot.  If you can get an account on Outlook.com, send mail and
> > see if it bounces with usable diagnostics in the bounce.
> 
> I changed the preferred chain here, and for all my domains (thx o/ !).
> it certainly didn't hurt.

Presumably you then also *force* renewed the certificate chain.

> But, i'm increasingly sure that your original speculation was correct
> -- bad rollover.  cleaning up DNS config, and forcing a clean
> rollover, seems to have done the trick.

But your original chain did validate as far as posttls-finger was
concerned, so perhaps the root CA was the issue?

> After the dns cleanup, switching BACK the preferred chain didn't
> reinit the issue.

Did you *force* renewal at that point?

> When I looked at the logs I was given, DNSSEC/dane issues didn't leap
> out at me -- but you mentioned them.
> 
> What in those logs suggested DNSSEC/dane to you?  Anything specific,
> or just likelihood?

Microsoft is one of the few *large* email providers (Google, Microsoft,
Yahoo) that supports DANE (for now just outbound).  But DANE appeared to
be fine on your end.

> In any case, I want to set up a DNSSEC rollover 'canary' ...
> tool/script that'll notify me on failures, like "this".  Before I cobble
> something up from scratch -- is there a recommended/best-practice tool
> for the job?

See


https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources#221-deployment-and-monitoring

Perhaps, specifically: https://github.com/PennockTech/smtpdane but let
us know which worked out best for you.

However, perhaps simple is best in which case tweak the attached bash
shell script to meet your needs.  Note this only tests one IP address
per probe, a full check would try all IP addresses both IPv4 and IPv6 as
well as all permutations of TLS 1.2/1.3 and preferred public key
algorithm.  Extending the script to do more tests should be easy.

Sample output from "danesmtp mx1-edge.pgnetwork.net":

===  TLS 1.3 with ECDSA preferred:
verify depth is 9
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_CHACHA20_POLY1305_SHA256
Requested Signature Algorithms: 
ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1
Peer certificate: CN = mx1-edge.pgnetwork.net
Hash used: SHA384
Signature type: ECDSA
Verification: OK
DANE TLSA 3 1 2 ...18133fc2d94d1260e012bf5a matched EE certificate at depth 0
Server Temp Key: X25519, 253 bits
250 SMTPUTF8
DONE

===  TLS 1.3 with RSA preferred:
verify depth is 9
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_CHACHA20_POLY1305_SHA256
Requested Signature Algorithms: 
ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1
Peer certificate: CN = mx1-edge.pgnetwork.net
Hash used: SHA384
Signature type: ECDSA
Verification: OK
DANE TLSA 3 1 2 ...18133fc2d94d1260e012bf5a matched EE certificate at depth 0
Server Temp Key: X25519, 253 bits
250 SMTPUTF8
DONE

===  TLS 1.3 with EDDSA preferred:
verify depth is 9
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_CHACHA20_POLY1305_SHA256
Requested Signature Algorithms: 
ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1
Peer certificate: CN = mx1-edge.pgnetwork.net
Hash used: SHA384
Signature type: ECDSA
Verification: OK
DANE TLSA 3 1 2 ...18133fc2d94d1260e012bf5a matched EE certificate at depth 0
Server Temp Key: X25519, 253 bits
250 SMTPUTF8
DONE

===  TLS 1.2 with ECDSA preferred:
verify depth is 9
CONNECTION ESTABLISHED
Protocol version: TLSv1.2
Ciphersuite: ECDHE-ECDSA-AES256-GCM-SHA384
Requested Signature Algorithms: 
ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1:DSA+SHA224:DSA+SHA1:DSA+SHA256:DSA+SHA384:DSA+SHA512
Peer certificate: CN = mx1-edge.pgnetwork.net
Hash used: SHA256
Signature type: ECDSA
Verification: OK
DANE TLSA 3 1 2 ...18133fc2d94d1260e012bf5a matched EE certificate at depth 0
Supported Elliptic Curve Point Formats: 
uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
Server Temp Key: X448, 448 bits
250 

[pfx] Re: Future Date:

[Viktor Dukhovni via Postfix-users]

On Tue, May 02, 2023 at 05:47:03PM +0200, Benny Pedersen via Postfix-users 
wrote:
> Matus UHLAR - fantomas via Postfix-users skrev den 2023-05-02 15:28:
> 
> > perhaps you would want to set up spam filter?
> > spamassassin has check for date in future and also many other for 
> > spammy signs.
> 
> Viktor provided a milter that test it before queue, while spamassassin 
> is after queue ?
> 
> but yes if sa-milter is in use it does not mater if date in future can 
> tempfail mails
> 
> Viktor would you mind add this milter to fuglu plugin 
> https://gitlab.com/fumail/fuglu/ ?

I posted a sketch of one function from a milter I am using.  I do not
intend to make it public.  The milter is largely trivial, and highly
specific to my use case.  Other Python milters can be used as a template
to similar ends.

-- 
Viktor.

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

[pfx] Re: inbound failures only from outbound.protection.outlook.com. Cert issue in this log?

[Viktor Dukhovni via Postfix-users]

On Tue, May 02, 2023 at 11:54:00AM -0400, PGNet Dev wrote:

> > The DST root, that issued the ISRG X1 cross cert.
> 
> https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
> 
> yikes. missed that by a mile!
> 
> >>From my renewal.conf file:
> > 
> >  [renewalparams]
> >  reuse_key = True
> >  preferred_chain = ISRG Root X1
> >  ...
> 
> and for acme,
> 
>   https://github.com/acmesh-official/acme.sh/wiki/Preferred-Chain
> 
> 
> i'll get this in place with the downstream, and see what it cures!

Also look into other possibilities, the DST Root issue is a bit of a
longshot.  If you can get an account on Outlook.com, send mail and see
if it bounces with usable diagnostics in the bounce.

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

[pfx] Re: Fw: Re: Re: Contradicting Postfix documentation

[Viktor Dukhovni via Postfix-users]

On Tue, May 02, 2023 at 04:45:13PM +0200, Kolusion K via Postfix-users wrote:

> Hang on a second... my Postfix is using a network interface that is
> not the one set with the inet_interfaces parameter. So, my experience
> is true- the inet_interfaces parameter has no effect.

No, it has exactly the documented effects, perhaps different from your
naïve expectations for your particular use case.  This is not the forum
to seek "validation", the most you can expect from this list is
technical help to configure Postfix to meet your stated requirements.

- The IPv4 addresses listed in inet_interfaces have no effect on
  the choice of outbound IPv6 address when IPv6 is enabled.

- When inet_interfaces list no IPv4 addresses other than loopback
  addresses, or lists multiple non-loopback IPv4 addresses, then
  inet_interfaces also has no effect on the choice of outbound IPv4
  addresses.

- To be sure that a particular IPv4 or IPv6 source address is used,
  configure an explicit "smtp_bind_address" or "smtp_bind_address6".
- To be sure that IPv6 is not used, set "inet_protocols = ipv4".
- To be sure that IPv4 is not used, set "inet_protocols = ipv6".

- If you have just one IPv4 address suitable for both sending and
  receiving mail, set it as the only IPv4 address in inet_interfaces.
  You then don't need an explicit "smtp_bind_address", though an
  explicit setting may be sensible in some cases.
- If you have just one IPv6 address suitable for both sending and
  receiving mail, set it as the only IPv6 address in inet_interfaces.
  You then don't need an explicit "smtp_bind_address6", though an
  explicit setting may be sensible in some cases.
- In either case disable any protocol that is not at all suitable for
  receiving or sending email.

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

[pfx] Re: inbound failures only from outbound.protection.outlook.com. Cert issue in this log?

[Viktor Dukhovni via Postfix-users]

On Tue, May 02, 2023 at 11:09:59AM -0400, PGNet Dev wrote:

> what root CA expiry are you referring to?

The DST root, that issued the ISRG X1 cross cert.

> > The "ISRG Root X1" CA no longer needs a cross cert.
> 
> it seems that LE still provides them,
> 
>https://letsencrypt.org/certificates/
> 
> need to see if the certbot/acme client has a knob to disable/remove the DST 
> cross.

>From my renewal.conf file:

[renewalparams]
reuse_key = True
preferred_chain = ISRG Root X1
...

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

[pfx] Re: Postfix is not using a specified interface

[Viktor Dukhovni via Postfix-users]

On Tue, May 02, 2023 at 11:18:26AM +0200, Kolusion K via Postfix-users wrote:

> I have specified Postfix to use a certain interface in 'main.cf':
> 
>   inet_interfaces = 192.168.2.2
> 
> http://www.postfix.org/postconf.5.html#inet_interfaces
> 
> The problem is, Postfix is not using this interface and is instead
> using another interface to send e-mail.
> 
> Is this a bug?

When inet_interfaces contains exactly one explicit non-loopback IPv4
address that address becomes the default bind address for outgoing
*IPv4* SMTP connections.  The same is separately true for IPv6, but
setting inet_interfaces to just an IPv4 address while at the same time
"inet_protocols = all", will not provide an IPv6 default bind address,
so IPv6 will bind dynamically based on your routing table.

-- 
Viktor.

A Ukranian commentator (and former army intelligence officer) covering
the chronology of the war periodically needs to explain the difference
between intelligence and counter-intelligence officers.

- Intelligence officers look for friends among enemies.
- Counter-intelligence officers look for enemies among friends.

Your attitude to Postfix and the advice you get on this list seems to be
that of a counter-intelligence officer.  This is not especially
productive.  Postfix is high quality software, and you'll get sound
advice here if you're less suspicious (or even disparaging) of both
Postfix and the advice given.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: inbound failures only from outbound.protection.outlook.com. Cert issue in this log?

[Viktor Dukhovni via Postfix-users]

On Tue, May 02, 2023 at 09:54:48AM -0400, Viktor Dukhovni via Postfix-users 
wrote:

> What are some domains your server accepts mail for?  Do you perhaps
> publish DANE TLSA records and have botched certificate rotation?

See if dropping the DST cross cert from your certificate chain will
help.  That root CA has long ago expired.

Issuer: C=US, O=Let's Encrypt, CN=R3
Not Before: Apr 12 12:15:32 2023 GMT
Not After : Jul 11 12:15:31 2023 GMT
Subject: CN=mx1-edge.pgnetwork.net

Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root X1
Not Before: Sep  4 00:00:00 2020 GMT
Not After : Sep 15 16:00:00 2025 GMT
Subject: C=US, O=Let's Encrypt, CN=R3

Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
Not Before: Jan 20 19:14:03 2021 GMT
Not After : Sep 30 18:14:03 2024 GMT
Subject: C=US, O=Internet Security Research Group, CN=ISRG Root X1

The "ISRG Root X1" CA no longer needs a cross cert.

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

[pfx] Re: inbound failures only from outbound.protection.outlook.com. Cert issue in this log?

[Viktor Dukhovni via Postfix-users]

On Tue, May 02, 2023 at 09:41:50AM -0400, PGNet Dev via Postfix-users wrote:

> a server that i don't have shell access to atm has, today, started
> seeing undelivered mail from only one domain --
> *outbound.protection.outlook.com.  apparently, everything else inbound
> is flowing.  and, i'm told, inbound from outlook.com was working
> yesterday.

The logging is much too verbose, pruned to just the expected normal
logging:

> 2023-05-02T08:23:16.757030-04:00 karma postfix/ps-int/smtpd[17881]:
>   connect from 
> mail-co1nam11on2041.outbound.protection.outlook.com[40.107.220.41]
> 2023-05-02T08:23:17.155534-04:00 karma postfix/ps-int/smtpd[17881]:
>   Untrusted TLS connection established from
>   mail-co1nam11on2041.outbound.protection.outlook.com[40.107.220.41]:
>   TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
> 2023-05-02T08:23:17.225393-04:00 karma postfix/ps-int/smtpd[17881]:
>   disconnect from > 
> mail-co1nam11on2041.outbound.protection.outlook.com[40.107.220.41]
>   ehlo=1 starttls=1 quit=1 commands=3

Either the client had no intention to send mail (some sort of liveness
probe), or perhaps it did not like the presented certificate chain.

What are some domains your server accepts mail for?  Do you perhaps
publish DANE TLSA records and have botched certificate rotation?

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

[pfx] Re: Future Date:

[Viktor Dukhovni via Postfix-users]

On Mon, May 01, 2023 at 03:41:37PM -0400, Jon LaBadie via Postfix-users wrote:

> I've been getting a lot of spam with Date: headers
> containing future dates, typically 1 year.
> 
> I don't find any header checks that would look for
> this type of message.  Have I over looked it?
> 
> In the meantime I've implemented a script and procmail
> rule to examine my messages.  But that is post-delivery
> and per-user.

I have a Python milter that defers some future-dated messages.

...

def __init__(self):
self.__id = Milter.uniqueID()
self.__ipname = None
self.__ip = None
self.__port = None
self.__from = None
self.__now = time.time()
...

...

def header(self, name, hval):
"""header callback gets called for each header
"""
if config.debug:
print("%s: %s" % (name, hval))

lc = name.lower()

# ...

if ... selection criteria ... :
if lc == "date":
tm = email.utils.parsedate_tz(hval)
if tm is not None:
try:
t = email.utils.mktime_tz(tm)
dt = t - self.__now
if config.debug:
print("Then %f, now %f, delta %f" % (t, self.__now, 
dt))
if ... no extenuating circumstances ...:
floor = -... allowance for clock drift ...
else:
floor = ... minimum delay penalty ...
if dt > floor:
self.setreply("454", xcode="4.7.0", msg="No thanks")
return Milter.TEMPFAIL
except Exception as _: pass

return Milter.CONTINUE

Some messages have to arrive some time after the implied date, some can
arrive a short time before, and some are not restricted at all.  No
message is refused if the remote MTA is willing to retry long enough.
The logic is narrowly targetted at a particular pattern of abuse.

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

[pfx] Re: tls_high_cipherlist parameter

[Viktor Dukhovni via Postfix-users]

On Mon, May 01, 2023 at 11:01:56AM +0200, Bernardo Reino via Postfix-users 
wrote:

> > Sadly, the documentation lacks specificness, and the output spit out about 
> > 500 lines, so I am not sure what I am suppose to be looking at.
> 
> postconf -d will print all the (default) settings, you can use grep to filter 
> the specific line you're looking for.

No need for grep (output for Postfix 3.8):

$ postconf -d tls_high_cipherlist
tls_high_cipherlist = 
aNULL:-aNULL:HIGH:!SEED:!IDEA:!3DES:!RC2:!RC4:!RC5:!kDH:!kECDH:!aDSS:!MD5:@STRENGTH

  or,

$ postconf -dhx tls_high_cipherlist

aNULL:-aNULL:HIGH:!SEED:!IDEA:!3DES:!RC2:!RC4:!RC5:!kDH:!kECDH:!aDSS:!MD5:@STRENGTH

  which then makes it possible to, for example, list the ciphers that
  could be used when TLS 1.2 is negotiated):

$ openssl ciphers -v -tls1_2 -s "$(postconf -dhx tls_high_cipherlist)"
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) 
Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(256) 
Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH   Au=RSA  Enc=AESGCM(256) 
Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA 
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA  
Enc=CHACHA20/POLY1305(256) Mac=AEAD
...

However, the advice in the documentation to NOT tinker with the
"tls_*_cipherlist" settings should not be taken lightly.  A common
rookie mistake is to cut/paste a cipherlist recommended in some random
HOWTO, and assume that using that particular cipherlist will improve
"security".  The various HOWTO's that recommend an explicit list of
concrete ciphers are all wrong, and their notion of "security" maps
poorly onto opportunistic TLS.

I repeat: DO NOT tinker with the "tls_*_cipherlist" parameters, they're
for emergency use only, in case many years after initial release some
new surprise vulnerability makes it necessary to fine-tune the list.  If
that should some day happen, we'll update the documentation and post a
message to the list.  For now, let the defaults stand.

If some test you run against your server tells you that your server uses
insecure cipher settings, and you haven't changed the Postfix defaults,
the problem is a misguided test, not incorrect settings.

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

[pfx] Re: Painful Postfix

[Viktor Dukhovni via Postfix-users]

On Mon, May 01, 2023 at 04:46:20AM +0200, Michael Grimm via Postfix-users wrote:

> > When I open a raw socket to the remote server on port 25 using
> > telnet, I am able to connect and see the server announce itself […]
> 
> Then, do continue to provide all essential *FURTHER* commands via
> telnet and see and report what happens.

There's no point in any of that.  The actual problem is TCP connection
establishment, not SMTP chit-chat.  The OP's various tunnels may behave
differently when tested by hand, but regardless no SMTP dialogues over
established connections shed any light on connection failure.

To debug networking issues, use "tcpdump" to record and analyse traffic.

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

[pfx] Re: Painful Postfix

[Viktor Dukhovni via Postfix-users]

On Sun, Apr 30, 2023 at 06:06:48PM -0500, Matthew McGehrin via Postfix-users 
wrote:

> You can try adding to your main.conf:
> 
> tcp_windowsize=65535
> 
> See also:
> 
> https://www.postfix.org/postconf.5.html
> 
> That can help fixing broken window sizes because of a firewall.

This won't help.  The choice of TCP window size can sometimes play a
contributing role in problems during message *transmission*, but not
during TCP connection setup.  [ TCP fast-open aside, the SYN and SYN-ACK
packets carry no data.  Postfix does not enable TFO, and it is not on by
default. ]

The OP may be on a network that is blocked by the receiving system, or
from which SMTP connections are filtered by the local provider.

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

[pfx] Re: Deny any sender address with subdomain

[Viktor Dukhovni via Postfix-users]

On Sun, Apr 30, 2023 at 01:33:13AM +0100, Allen Coates via Postfix-users wrote:

> Any ideas on the opposite - i.e. WITHOUT a domain?
> 
> I sometimes receive messages from "u...@co.uk"...

With eTLD (effective TLD) domains that have neither address nor MX
records the

reject_unknown_sender_domain

restriction will refuse mail with an *envelope* sender in such a domain.
However, there is no built-in feature in postfix to apply similar rules
to message headers.

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

[pfx] Re: Painful Postfix

[Viktor Dukhovni via Postfix-users]

On Sun, Apr 30, 2023 at 03:26:24PM +1000, Sean Gallagher via Postfix-users 
wrote:

> from smtp.c: debug_peer_check(request->nexthop, "noaddr");

That is not the only check:

src/smtp/smtp.c:debug_peer_check(request->nexthop, "noaddr");
src/smtp/smtp_session.c:debug_peer_check(host, addr);

> The string being compared to debug_peer_list is the nexthop.

Only in that call.  The additional call in smtp_session.c checks the MX
hostname and IP address (either matching is sufficient to enable more
verbose logging).

The debug_peer_level is equivalent to specifying that many "-v" options,
but only temporarily for traffic with the peer in question.  None of
this will be helpful in this case.

> have you tried debug_peer_list = example.com

The OP is wasting his time and yours.  The TCP connections are timing
out, and enabling debug_peer_list, will just drown that signal in more
noise.

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

[pfx] Re: Painful Postfix

[Viktor Dukhovni via Postfix-users]

On Sun, Apr 30, 2023 at 07:11:45AM +0200, Kolusion K wrote:

> - Does the word "list" suggest any possibilities?
> 
> Please shut the fuck up with your arrogance. Act like a normal person,
> otherwise, don't talk to me at all.

Best to accept help graciously, in all the ways it is offered.

> The connection is established,

Your log entry proves this is not the case.  All three IPs timed out
during TCP connection setup.  Take a look at Postfix SMTP timeouts:

smtp_connect_timeout = 30s
smtp_data_done_timeout = 600s
smtp_data_init_timeout = 120s
smtp_data_xfer_timeout = 180s
smtp_helo_timeout = 300s
smtp_mail_timeout = 300s
smtp_quit_timeout = 300s
smtp_rcpt_timeout = 300s
smtp_rset_timeout = 20s
smtp_starttls_timeout = 300s
smtp_tls_session_cache_timeout = 3600s
smtp_xforward_timeout = 300s

Only one of these timeouts is 30s.  The target domain has 3 SMTP server
addresses.  The third and final definitely timed out in SMTP connect, so
did the first two.

> but Postfix has been designed shit and does not differentiate in its
> log a connection that times and when trying to make a connection and a
> connection that has been made, but times out during the SMTP transaction.

You're welcome to switch to a different MTA.  Please do.

> That is why I am asking if its possible to see a SMTP session, so I
> can see what is going on, because chances are the remote server is
> sending me a non-complaint command which Postfix doesn't know how to
> handle.

You're wasting your time.  SMTP command logging will be of no help when
TCP connections fail.

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

[pfx] Re: Painful Postfix

[Viktor Dukhovni via Postfix-users]

On Sun, Apr 30, 2023 at 06:41:06AM +0200, Kolusion K wrote:

> Apr 30 14:32:16 generalpurpose postfix/smtp[2299]:
>   78D1D80AD7: to=, relay=none,
>   delay=414074, delays=413981/0.19/93/0, dsn=4.4.1,
>   status=deferred (connect to mxw.mxhichina.com[47.246.99.195]:25:
>   Connection timed out)  

The domain has two MX hosts, with three IPv4 addresses and 0 IPv6:

tnet.hk. IN MX 5 mxn.mxhichina.com.
tnet.hk. IN MX 10 mxw.mxhichina.com.

mxn.mxhichina.com. IN A 47.246.136.231
mxn.mxhichina.com. IN A 47.246.137.47
mxw.mxhichina.com. IN A 47.246.99.195

you're reporting the connection failure to the secondary, but the real
problem is typically the failure to connect/deliver via the primary.
The reason for the "93" second connection setup delay is that all
three connections timed out, taking ~30s each.

That said, I can connect to all three:

$ posttls-finger -c -lmay -Lsummary "[mxn.mxhichina.com]"
posttls-finger: Untrusted TLS connection established
  to mxn.mxhichina.com[47.246.137.47]:25:
  TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
  key-exchange X25519 server-signature RSA-PSS (2048 bits)
  server-digest SHA256

   $ posttls-finger -c -lmay -Lsummary "[47.246.136.231]"
   posttls-finger: Untrusted TLS connection established
 to 47.246.136.231[47.246.136.231]:25:
 TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits)
 server-digest SHA256

$ posttls-finger -c -lmay -Lsummary "[mxw.mxhichina.com]"
posttls-finger: Untrusted TLS connection established
  to mxw.mxhichina.com[47.246.99.195]:25:
  TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
  key-exchange X25519 server-signature RSA-PSS (2048 bits)
  server-digest SHA256

> The domain I am sending to has multiple e-mail server IP addresses.
> How can I add multiple IP addresses when using the 'debug_peer_list'
> attribute?   

  - Does the word "list" suggest any possibilities?

Mind you, if you can't make a TCP connection to port 25 on the IPs in
question, you won't find anything useful in the debug logs.  Perhaps the
firewalls in front of the SMTP servers in question are blocking
connections from your network.  Not much you can do about that.

> > > I am trying to send an e-mail, but the receving e-mail server is
> > > timing out, as per Postfix's mail log file.
> > 
> > 1. Per  post (this time in
> > plain text rather than HTML form!) your server's configuration settings:
> > 
> > $ postconf -nf
> > $ postconf -Mf
> > 
> > being sure to not rewrap line breaks. Attach the output as a text
> > file if that's the easiest way to preserve whitespace.

Is there a reason you failed to send the configuration details?

> > 2. At what stage in the email transaction is the timeout occuring?
> > Post the specific log entries related to the transmission of one
> > or a few messages that time out.

Is there a reason you did not send a more complete set of log entries,
for example also the failure via the primary MX?

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

[pfx] Re: Painful Postfix

[Viktor Dukhovni via Postfix-users]

On Sat, Apr 29, 2023 at 12:40:46PM +0200, Kolusion K via Postfix-users wrote:

> I am trying to send an e-mail, but the receving e-mail server is
> timing out, as per Postfix's mail log file.

1. Per  post (this time in
   plain text rather than HTML form!) your server's configuration settings:

$ postconf -nf
$ postconf -Mf

   being sure to not rewrap line breaks.  Attach the output as a text
   file if that's the easiest way to preserve whitespace. 

2. At what stage in the email transaction is the timeout occuring?
   Post the specific log entries related to the transmission of one
   or a few messages that time out.


> I would like to see the SMTP session Postfix has with the receiving
> e-mail server to see what is going wrong.

If you add the remote IP address to debug_peer_list, the SMTP commands
and responses received are be logged.  If your syslog subsystem is
not dropping messages, you'll find them in the log.

> I have tried to use the 'debug_peer_list' parameter with the domain of
> the e-mail address I am trying to send e-mail to, but nothing more
> shows in the mail log.

The "debug_peer_list" setting takes a list of remote SMTP server (MX
host) IP addresses or hostnames, which is not the same as the remote
domain.

> I can't tap into the connection to view the session from outside
> Postfix because the connection is encrypted.

So at least an SMTP connection is established, and STARTTLS is
accepted.

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

[pfx] Re: Deny any sender address with subdomain

[Viktor Dukhovni via Postfix-users]

On Fri, Apr 28, 2023 at 06:38:04PM +0200, Jaroslaw Rafa via Postfix-users wrote:

> Also take into account that many countries use two-level domain registration
> scheme ...

In Japan, 3rd-level public suffixes are quite common, taking the form:
...jp.

For example:

hospital.hekinan.aichi.jp. MX 10 mwbgw2.ocn.ad.jp.
hospital.hekinan.aichi.jp. MX 10 mwbgw1.ocn.ad.jp.

And there's even:

pike.pvt.k12.ma.us. MX 100 thepike.ne.client2.attbi.com. 

delegated from the PSL-listed 4LD:

pvt.k12.ma.us

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

[pfx] Re: forwarding questions

[Viktor Dukhovni via Postfix-users]

On Fri, Apr 28, 2023 at 08:32:29AM +0800, Tom Reed via Postfix-users wrote:

> I have a local real mailbox: u...@foo.com.  When I setup this alias
> map in virtual_alias_maps file:
> 
> u...@foo.com u...@gmail.com
> 
> (then postmap this file).  The message sent to u...@foo.com won't
> reach into mailbox, but just forwarded to gmail.
> 
> How can I setup it to both reach local mailbox and forwarding?

This is a bad idea.  Don't do this.  Forwarding spam to gmail, or mail
from external senders with SPF policies, ... will fail to be delivered,
and will tarnish your server's "reputation".

It can of course be made to "work" (in the sense of queueing the mail
for delivery), but really, don't.

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

[pfx] Re: Postfix server is sending non-delivery notifications with a blank "from" address

[Viktor Dukhovni via Postfix-users]

On Thu, Apr 27, 2023 at 02:15:38PM -0300, Rejaine Monteiro wrote:

> I know that bounces are necessary..
> but addresses like "noreply" are usually automation robots and do not
> receive responses and can generate double bounces..

Responses may not be read (or, in particular, *replied-to*), but bounces
are still expected to be processed, even with "noreply" addresses.

> Not be fixed (not an error), I just want to know if there is a way to avoid
> bounces to specific addresses (like nore...@somedomain.com)
> .. sorry if I wasn't clear (bad english)

The best solution is to not accept undeliverable messages.  Then you'll
rarely if ever send bounces.  When you do, the envelope sender will
be empty as required.

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

[pfx] Re: Postfix server is sending non-delivery notifications with a blank "from" address

[Viktor Dukhovni via Postfix-users]

On Thu, Apr 27, 2023 at 11:13:13AM -0300, Rejaine Monteiro via Postfix-users 
wrote:

> I have a Postfix 3.4.13 that sends non-delivery notifications with a blank
> "from" address, like so:
> 
> postfix/bounce[3337994]: 536301634D8: sender non-delivery notification: 
> 421CF1634EB
> postfix/qmgr[2272522]: 421CF1634EB: from=<>, size=8212, nrcpt=1 (queue active)

This is *required* by the SMTP specification, in order to avoid bounce
loops.

> How can I fix this?

There's nothing to fix.

> And is there any way to not send bounces to a specific email (ex:
> don't send bounces to nore...@domain.com)

Don't accept email from them (or anyone else for that matter) that will
later bounce.  As much as possible "reject" undeliverable mail *before*
it enters the queue.

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

[pfx] Re: Sender address rejected, but domain is found?

[Viktor Dukhovni via Postfix-users]

On Tue, Apr 25, 2023 at 08:43:26PM +0200, Gerald Galster via Postfix-users 
wrote:

> >; Delegation NS
> >eurobank-direktna.rs. IN NS ns1.eurobank.rs. ; AD=0
> >eurobank-direktna.rs. IN NS ns2.eurobank.rs. ; AD=0
> >eurobank-direktna.rs. IN NS ns3.eurobank.rs. ; AD=0
> > 
> >; Authoritative NS
> >eurobank-direktna.rs. IN NS bgdit01edns01.eurobank.rs.
> > 
> > The latter host does not exist:
> > 
> > [...]
> >
> > Once BIND learns the authoritative NS, the domain is bricked until that
> > data times out.
> 
> Is that implementation specific? It doesn't seem to be the case with unbound.

Some resolvers are "parent-centric" and some "child-centric".  The child
NS records are de jure more authoritative.

> It probably works because the NS records are already provided
> by the .rs tld nameservers:

That's typically the initial state.

> ;; QUESTION SECTION:
> ;eurobank-direktna.rs.IN  NS
> 
> ;; ANSWER SECTION:
> eurobank-direktna.rs. 3600IN  NS  bgdit01edns01.eurobank.rs.
> 
> This is obviously wrong, but why should a resolver query
> @ns1.eurobank.rs for eurobank-direktna.rs nameservers as
> this information is already known.

This can happen in a variety of ways.  Sometimes the child zone
"helpfully" includes NS records in the authority section along with
answers.  Sometimes this happens when the delegation records are
being refreshed due to TTL expiration, and sometimes an explicit user
or application query for the NS records.

In any case BIND is "entitled" to prefer the child zone NS RR, which
then turns out to be unusable.  The zone in question is misconfigured.

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

[pfx] Re: Postfix Amavis (Virus Checker) PHPList workaround

[Viktor Dukhovni via Postfix-users]

On Mon, Apr 24, 2023 at 02:23:54PM -0400, Wayne Spivak via Postfix-users wrote:

> My PHPList (broadcast only) goes through port 587, and since it sits on the
> server, it doesn't need authentication (I'm the only user).

How does it send mail, a separate message per recipient, or one message
with many envelope recipients?

> How do I create another smtp port that will allow PHPList to bypass Amavis?
> With a 15K address list, the load on the server would cripple it if it
> checked every list broadcast.

If the message is submitted with all 15k recipients in the envelope,
then it should be possible to scan it just once.

And of course Amavis has "policy banks" to tune inspection policy by
various features of the message.  (I don't use amavis, so can't provide
more detailed guidance).

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

[pfx] Re: Sender address rejected, but domain is found?

[Viktor Dukhovni via Postfix-users]

On Tue, Apr 25, 2023 at 12:24:04PM -0400, Alex via Postfix-users wrote:
> Hi, I realize this is probably one of the most frequently asked questions,
> but I really can't figure out why this was rejected.
> 
> Apr 25 12:06:01 petra postfix-226/smtpd[592344]: NOQUEUE: reject: RCPT from
> mail.email.eurobank.rs[195.242.76.237]: 450 4.1.8 :
> Sender address rejected: Domain not found; from=<
> obaveste...@eurobank-direktna.rs> to= proto=ESMTP helo=<
> mail.email.eurobank-direktna.rs>
> 
> What am I missing? eurobank-direktna.rs and mail.email.eurobank-direktna.rs
> both have forward and reverse DNS entries.
> 
> I thought maybe it just didn't resolve properly at the time the email was
> received, but it's been happening for hours.

See:

https://dnsviz.net/d/eurobank-direktna.rs/ZEgBpw/dnssec/

The most obvious problem is that the delegation NS (parent zone) records
for the domain don't agree with the authoritative NS (child zone) records.

; Delegation NS
eurobank-direktna.rs. IN NS ns1.eurobank.rs. ; AD=0
eurobank-direktna.rs. IN NS ns2.eurobank.rs. ; AD=0
eurobank-direktna.rs. IN NS ns3.eurobank.rs. ; AD=0

; Authoritative NS
eurobank-direktna.rs. IN NS bgdit01edns01.eurobank.rs.

The latter host does not exist:

; <<>> DiG 9.18.7 <<>> -t a bgdit01edns01.eurobank.rs.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19772
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1400
;; QUESTION SECTION:
;bgdit01edns01.eurobank.rs. IN  A

Once BIND learns the authoritative NS, the domain is bricked until that
data times out.

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

[pfx] Re: postfix mail server qmgr log entry query

[Viktor Dukhovni via Postfix-users]

On Mon, Apr 24, 2023 at 05:39:01PM +, Jitendra Chaudhari via Postfix-users 
wrote:

> Mail flow is as follows.
> 
> IceWarp (email Server)--->
>postfix--->
>cisco(ironport email gateway)--->
>Internet
> 
> I found some strange messages for qmgr process as follows

What looked strange to you?

> Can anyone please help me how to interpret this log entry?
> 
> Apr 20 14:04:09 fsmta1 postfix/smtpd[169407]: 36421809DB5: 
> client=localhost[127.0.0.1], orig_client=unknown[192.168.234.51]

This message is likely downstream of a content_filter, that forwarded it
with "xforward" enabled, to record the original client IP address.  That
IP address is an RFC1918 (192.168.0.0/16) non-public IP address, so the
message is purportedly from a client inside your network.

> Apr 20 14:04:09 fsmta1 postfix/cleanup[173827]: 36421809DB5: 
> message-id=295c0a7e4f14d016618afa55b5e5472f-1452568706@192.168.234.51

To see the log entries recording the original mesasge coming in, look
for other log entries that contain either "36421809DB5" or  the above
message-id.  Then find all entries for *that* queue-id.

> Apr 20 14:04:09 fsmta1 postfix/qmgr[2205]: 36421809DB5: 
> from=no-reply=19=tjsb@.co.in, size=2169, nrcpt=1 (queue active)

Nothing interesting here.  Unless you suspect that this message should
not have been accepted in the first place.

> Apr 20 14:04:09 fsmta1 postfix/smtp[167717]: 36421809DB5: to=x...@x.com, 
> relay=xxx:366, delay=0.05, delays=0/0.01/0.02/0.02, dsn=2.0.0, 
> status=sent (250 ok:  Message 14326499 accepted)
> Apr 20 14:04:09 fsmta1 postfix/qmgr[2205]: 36421809DB5: removed

The message was then delivered to some SMTP server on port 366 (or did
you also obfuscate the port number)?

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

[pfx] Re: Regarding transport maps (sender_dependent_relayhost_maps not working)

[Viktor Dukhovni via Postfix-users]

On Sat, Apr 22, 2023 at 07:58:25PM -0700, Andrew Athan wrote:

> If I understand it well enough I'll write and submit a doc PR.

This is unlikely to be productive.

> If I put all this together what I think I'm hearing is that transport_map
> overrides everything

The transport(5) table has the highest priority for the components of
the (transport, nexthop) pair that it specifies.  All the other sources
are fallback sources when either or both of the transport or nexthop are
not specified in transport(5).

> So does sender_dependent_relayhost_maps contain mappings from keys to
> transport:nexthop values or to nexthop values?

A "relayhost" is a host (i.e. a nexthop) so clearly not a transport
("smtp", "lmtp", "local", ...).

> I think what's generally missing in the transport(5) man page and any docs
> I've read so far, is a description of the concept that what postfix is
> trying to do is to get to a fully resolved transport:nexthop PAIR.

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

RESULT FORMAT
   The  lookup  result  is  of  the form transport:nexthop.  The transport
   field specifies a mail delivery transport such as smtp  or  local.  The
   nexthop field specifies where and how to deliver mail.

   The  transport  field  specifies  the name of a mail delivery transport
   (the first name of a mail delivery service entry in  the  Postfix  mas-
   ter.cf file).

   The  nexthop  field usually specifies one recipient domain or hostname.
   In the case of the Postfix SMTP/LMTP client, the nexthop field may con-
   tain  a  list  of nexthop destinations separated by comma or whitespace
   (Postfix 3.5 and later).

   ...

> Some of the settings can specify only the transport or both the
> transport:nexthop or only the nexthop. As soon as it's fully resolved
> or hit DUNNO, the search stop.

No.  "DUNNO" is an access(5) verb, but is NOT applicable in the case of
transport(5) lookups (it does apply in the sender-dependent table to
support creating NOP exceptions to broad rules).  Access control !=
routing.

> Do I have that right?

Not quite.  See above.

> I'm still left unsure as to whether there are differences in how the sender
> dependent tables are searched vs the non-sender dependent tables; however,

Barring minor oversights, each Postfix table-based feature documents the
lookup keys searched and the result format.

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

A sender-dependent override for the global relayhost parameter
setting. The tables are searched by the envelope sender address and
@domain.

This is slightly different from transport(5) where domains are matched
without a leading "@", as documented.

> I think the only reason for my confusion is that there is now
> misinformation out there that comes up whenever people google these topics.

Search engines index "relevant" information, that appears to be popular,
but accuracy isn't necessarily part of the equation.  Welcome to the
Internet.

> My guess is that if you want to match all relayed mail from bad_domain.com
> even if you put that rule into one of the sender dependent maps, the key is
> bad_domain.com or .bad_domain.com and never @bad_domain.com.

The lookup key formats for the various mumble_maps parameters are as
documented.  Consult the https://www.postfix.org documentation.

> > > the sender_transport_maps contains:
> > > @filtered_domain.com DISCARD
> 
> Ok. So this did not result in an error not only because my transport_map
> caused no further search to be done, but also because DISCARD or discard
> would just be interpreted as a "nexthop name" when encountered in that map.

You said "sender_dependent_transport_maps",


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

A sender-dependent override for the global default_transport
parameter setting. The tables are searched by the envelope sender
address and @domain. A lookup result of DUNNO terminates the search
without overriding the global default_transport parameter setting.
This information is overruled with the transport(5) table. 

> While not technically an error, again, a startup sweep of these maps could
> at least issue warnings for common misconfigurations like this one.

Postfix doesn't "sweep" maps.  They could be large, or could be regexp
based, ...  Map lookups are performed on demand, one key at a time.

> That being said, I suppose there could be a "blackhole" transport that
> sends everything to /dev/null, and then (assuming the sender specific maps
> can override any already resolved transport), the map could contain an .
> bad_domain.com => blackhole:foobar mapping, where foobar is irrelevant but
> servers to stop the search for a nexthop. Right?

There's a "discard" transport, to which specific recipient domains can
be delivered (post-queue discard).  There is also a "DISCARD" access(5)
verb which causes the 

[pfx] Re: Regarding transport maps (sender_dependent_relayhost_maps not working)

[Viktor Dukhovni via Postfix-users]

On Sat, Apr 22, 2023 at 05:56:12PM -0700, Andrew Athan via Postfix-users wrote:

> "This information is overruled with... the transport(5) table."

In other words, "transport_maps", a logical dictionary built from
a list of component tables (some of which may also be composite).

> But "sender_dependent_relayhost_maps" indicates that it can be overruled by
> "sender_dependent_default_transport_maps"

Bottom line "relayhost" and its sender-dependent versions provide a
non-default nexthop to override the recipient domain, but may in turn be
preëmpted by any explicit nexthop in the transport(5) map, whether
global, or sender-dependent.


> so there is apparently some relationship between relay_transport and
> default_transport or at least between the sender_dependent files
> amongst themselves?

All that's going on is that "bare" transports get their nexthop from
either the recipient domain, or some sort of relayhost override, while
complete "transport:nexthop" pairs do not.

> The transport(5) docs contain examples that indicate domains are searched
> without the @ sign, but in other places and in examples I find online it
> appears the @ sign is included in the sender_dependent...* searches??!!

The transport(5) table supports per-recipient lookups (user@domain) or
just per-domain lookups (I don't recommend reliance on per-recipient
transport tables except perhaps for a small set of "special" users, the
majority of transport decisions should be domain-wide).

> relay_domains = domain1.com domain2.com domain3.com

Postfix will inbound mail for these domains from any sender.

> transport_maps = hash:/etc/postfix/transport

This trumps all other transport choices, and also nexthop choices when
specified.

> sender_dependent_relayhost_maps = hash:/etc/postfix/sender_transport_maps

This overrides the nexthop for remote delivery, whenever the
transport(5) table does not.

> the /etc/postfix/transport map contains entries for each of the domain1.com

> domain1.com smtp:[domain1.mail.handler.com]:2000
> domain2.com smtp:[domain2.mail.handler.com]:2020

These specify a nexthop, so not affected by relayhost, sender-dependent
or otherwise.

> the sender_transport_maps contains:
> @filtered_domain.com DISCARD

"DISCARD" is access(5) verb, not a transport.  And should be used with
"check_sender_access" in one of "smtpd_mumble_restrictions" lists.

Recipient and sender Domains are looked up in access(5) tables without a
leading "@".

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

[pfx] Re: www.postfix.org certificate expired

[Viktor Dukhovni via Postfix-users]

On Sat, Apr 22, 2023 at 11:25:14AM -0400, Viktor Dukhovni via Postfix-users 
wrote:
> On Sat, Apr 22, 2023 at 01:08:06PM +0200, Matus UHLAR - fantomas via 
> Postfix-users wrote:
> 
> > >You should set a POST_HOOK in certbot renew (assuming you're using 
> > >certbot, that is) that restarts or reloads the web server.
> > 
> > I guess this exactly what failed.
> 
> The "post hooks" in certbot are not *reliable*.  If for some reason they
> don't succeed, they're retried on the next scheduled certbot run.  This
> is a design flaw.

Oops, I meant to write "*not* retried".

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

[pfx] Re: www.postfix.org certificate expired

[Viktor Dukhovni via Postfix-users]

On Sat, Apr 22, 2023 at 01:08:06PM +0200, Matus UHLAR - fantomas via 
Postfix-users wrote:

> >You should set a POST_HOOK in certbot renew (assuming you're using 
> >certbot, that is) that restarts or reloads the web server.
> 
> I guess this exactly what failed.

The "post hooks" in certbot are not *reliable*.  If for some reason they
don't succeed, they're retried on the next scheduled certbot run.  This
is a design flaw.

-- 
Viktor.

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

[pfx] Re: Reject mail by language

[Viktor Dukhovni via Postfix-users]

On Wed, Apr 19, 2023 at 11:33:36AM +0800, tom--- via Postfix-users wrote:

> I got a lot of spams (20+ every day) like the following for which i even 
> don't know what language they were.
> 

> مميز المنتدى العربي الثالث

The script is Arabic.  Language is harder for an MTA to deduce.  A
priori any of

- Arabic
- Farsi
- Urdu
- ...

Though in this case actually Arabic.  I'd focus more on the client IP,
sender domain, ... than the content language.

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

[pfx] Re: Reject mail by language

[Viktor Dukhovni via Postfix-users]

On Wed, Apr 19, 2023 at 02:54:22AM +0800, tom--- via Postfix-users wrote:

> How to reject messages by languages?
> For example, only English, Germany and Chinese messages will be 
> accepted. All others should be rejected.

Email messages almost never carry language information, they carry
character set information, which is increasingly either us-ascii, or
utf8.  Neither tell you much about the language used.

Nor is filtering by language wise.  Do you really know which languages
are accessible to every current and likely future user of your system?

Скорее всего нет!

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

[pfx] Re: smtp code 450 and delivery to secondary MX

[Viktor Dukhovni via Postfix-users]

On Tue, Apr 18, 2023 at 10:35:22AM +0800, tom--- via Postfix-users wrote:

> So my question is, smtp code 450 will cause the sender to retry delivery 
> to secondary MX?

Yes, if the client is a legitimate MTA, less common with a junk-sending
botnet.  Once you're confident your restriction settings are sound:

plaintext_reject_code = 550
unknown_address_reject_code = 550
unknown_client_reject_code = 550
unknown_hostname_reject_code = 550
unverified_recipient_reject_code = 550
unverified_sender_reject_code = 550

but you should rush to do this without watching your logs for some time
and fully understanding the rules you've configured.

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

[pfx] Re: is localhost.localdomain a FQDN?

[Viktor Dukhovni via Postfix-users]

On Tue, Apr 18, 2023 at 10:19:58AM +0800, tom--- via Postfix-users wrote:

> I saw many peer MTA connecting me with this default HELO hostname: 
> localhost.localdomain.
>
> Is this a FQDN?

Yes, it is a fully-qualified domain name.

> Is it valid?

Depends on your perspective.  This FQDN does not exist in the global DNS
(there is no "localdomain" TLD delegated in the root zone).  This sort
of name is typical for MUAs, and not typical of well run MTAs.  Whether
this sort of name is sufficient grounds to deny access is less obvious.

If this is not a significant fraction of your unwanted mail, the filter
may not be worth the risk of blocking something misguided, but useful.

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

[pfx] Re: Postfix refuses to accept email from video camera

[Viktor Dukhovni via Postfix-users]

On Sun, Apr 16, 2023 at 10:05:02PM +0300, Oleksandr wrote:
> > You now need to again post your configuration settings.  Post the output
> > of:
> > 
># postconf -nf smtpd_tls_cert_file smtpd_tls_key_file smtpd_tls_chain_files
># ls -l $(postconf -xh smtpd_tls_cert_file smtpd_tls_key_file 
> smtpd_tls_chain_files)
># grep -E '^-(BEGIN|END) ' $(postconf -xh smtpd_tls_cert_file 
> smtpd_tls_key_file smtpd_tls_chain_files)
> 
> The first two commands are executed silently.
> The third command does nothing and "hangs" and does not return to the command 
> line.
> 
> File main.cf is in the attachment.

Not surprising, since, while you've commented out the old settings:

-smtpd_tls_key_file = /etc/ssl/private/iRedMail.key
-smtpd_tls_cert_file = /etc/ssl/certs/iRedMail.crt
+### smtpd_tls_key_file = /etc/ssl/private/iRedMail.key
+### smtpd_tls_cert_file = /etc/ssl/certs/iRedMail.crt

you did not add either the corresponding replacements:

smtpd_tls_key_file = /etc/postfix/certkey.pem
smtpd_tls_cert_file = /etc/postfix/certkey.pem

or the now preferred:

smtpd_tls_chain_files = /etc/postfix/certkey.pem

Therefore, all three parameters are now empty, and the third hangs
waiting for input.  Do add either the legacy pair or (if using
Postfix 3.4 or later) the preferred replacement.

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

[pfx] Re: Postfix refuses to accept email from video camera

[Viktor Dukhovni via Postfix-users]

On Sun, Apr 16, 2023 at 09:24:09PM +0300, Oleksandr wrote:

> I think I've followed all your instructions, and now I've got another
> mistake:

That means that either my instructions had a typo, or your
implementation of correct instructions had a typo.

> Apr 16 21:20:29 mailserver postfix/smtps/smtpd[2496]: warning: No server 
> certs available. TLS won't be enabled

You now need to again post your configuration settings.  Post the output
of:

$ postconf -nf smtpd_tls_cert_file smtpd_tls_key_file smtpd_tls_chain_files
$ ls -l $(postconf -xh smtpd_tls_cert_file smtpd_tls_key_file 
smtpd_tls_chain_files)
# grep -E '^-(BEGIN|END) ' $(postconf -xh smtpd_tls_cert_file 
smtpd_tls_key_file smtpd_tls_chain_files)

At least the last of these needs root privileges

You can also attach the "main.cf" file in case the issue is with leading
whitespace or other formatting issues that are behind the content being
wrong.

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

[pfx] Re: Postfix refuses to accept email from video camera

[Viktor Dukhovni via Postfix-users]

On Sun, Apr 16, 2023 at 07:49:00PM +0300, Oleksandr wrote:

> > Did you reconfigure Postfix to use the generated PEM file 
> > as your certificate and private key file?
> 
> I didn't know it had to be done...  I just do what you recommend.  How
> do I need to do this reconfiguration?  Please tell me about this in
> more detail.

It seems you haven't learned even the most basic aspects of operating a
Postfix server.  Some reading is recommended:

- The No Starch Press book:
  https://www.amazon.com/Book-Postfix-State-Art-Transport/dp/1593270011
- The online docs:
  http://www.postfix.org/documentation.html
  https://www.postfix.org/BASIC_CONFIGURATION_README.html

You need to change the "main.cf" file to change the
"smtpd_tls_cert_file" and "smtpd_tls_key_file" as suggested in my
previous post:

Comment out the current settings:

# smtpd_tls_cert_file = /etc/ssl/certs/iRedMail.crt
# smtpd_tls_key_file = /etc/ssl/private/iRedMail.key

Replace with new settings of the same (somewhat outdated)
parameters:

# Install in /etc/postfix, chown root, chmod 0400 
smtpd_tls_cert_file = /etc/postfix/certkey.pem
smtpd_tls_key_file = /etc/postfix/certkey.pem

Or use the now preferred all-in-one setting:

# With Postfix 3.4 or later instead:
smtpd_tls_chain_files = /etc/postfix/certkey.pem

> And another question: do these commands have to be run as a normal user or as 
> a root?
> 
> $ dnsname=mailserver.mail.lan
> $ rm certkey.pem
> $ openssl req -new -nodes -newkey rsa:2048 -keyout /dev/stdout \
>   -config <(printf 'distinguished_name=dn\n[dn]\nprompt=yes\n') 
> -x509 -subj / -days 3653 \
>   -addext "basicConstraints = critical,CA:FALSE" \
>   -addext "extendedKeyUsage = serverAuth" \
>   -addext "subjectAltName = DNS:$dnsname" >> certkey.pem

These commands create a file called "certkey.pem" in the current working
directory.  The file contains potentially sensitive private key material
that should not be accessible to unauthorised users.

Therefore, to generate keys that are fully protected from all non-root
users and are not world-readable (umask 077):

$ sudo bash
# umask 077
# dnsname=mailserver.mail.lan
# cd /etc/postfix
# rm -f certkey.pem
# openssl req -new -nodes -newkey rsa:2048 -keyout /dev/stdout \
  -config <(
  printf 'distinguished_name=dn\n[dn]\nprompt=yes\n'
  ) -x509 -subj / -days 3653 \
  -addext "basicConstraints = critical,CA:FALSE" \
  -addext "extendedKeyUsage = serverAuth" \
  -addext "subjectAltName = DNS:$dnsname" >> certkey.pem

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

[pfx] Re: Postfix refuses to accept email from video camera

[Viktor Dukhovni via Postfix-users]

On Sun, Apr 16, 2023 at 06:03:09PM +0300, Oleksandr via Postfix-users wrote:
> Okay, Viktor! I executed these commands and got this result:
> 
> $ dnsname=mailserver.mail.lan
> $ rm certkey.pem
> rm: Unable to delete 'certkey.pem': No such file or directory
> user@mailserver:~$ openssl req -new -nodes -newkey rsa:2048 -keyout 
> /dev/stdout \
> -config <(printf 'distinguished_name=dn\n[dn]\nprompt=yes\n') -x509 
> -subj / -days 3653 \
> -addext "basicConstraints = critical,CA:FALSE" \
> -addext "extendedKeyUsage = serverAuth" \
> -addext "subjectAltName = DNS:$dnsname" >> certkey.pem
> Generating a RSA private key
> ..+
> ..+
> writing new private key to '/dev/stdout'
> -
> 
> But the 465/SSL mail is still not accepted.
> The PF logs still have the same lines:
> 
> Apr 16 17:55:46 mailserver postfix/smtps/smtpd[1512]: connect from 
> unknown[192.168.8.144]
> Apr 16 17:55:46 mailserver postfix/smtps/smtpd[1512]: SSL_accept error from 
> unknown[192.168.8.144]: Connection reset by peer
> Apr 16 17:55:46 mailserver postfix/smtps/smtpd[1512]: lost connection after 
> CONNECT from unknown[192.168.8.144]
> Apr 16 17:55:46 mailserver postfix/smtps/smtpd[1512]: disconnect from 
> unknown[192.168.8.144] commands=0/0
> 
> What else do I need to do?

Did you reconfigure Postfix to use the generated PEM file as your
certificate and private key file?

# smtpd_tls_cert_file = /etc/ssl/certs/iRedMail.crt
# smtpd_tls_key_file = /etc/ssl/private/iRedMail.key

# Install in /etc/postfix, chown root, chmod 0400 
smtpd_tls_cert_file = /etc/postfix/certkey.pem
smtpd_tls_key_file = /etc/postfix/certkey.pem

# With Postfix 3.4 or later instead:
smtpd_tls_chain_files = /etc/postfix/certkey.pem

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

[pfx] Re: Postfix refuses to accept email from video camera

[Viktor Dukhovni via Postfix-users]

On Sun, Apr 16, 2023 at 03:07:38AM +0300, Oleksandr via Postfix-users wrote:

> Yes, it looks like this :-) 
> But I was hoping that it would be enough to make corrections in the main.cf 
> and master.cf, and  Postfix friendship with the camera would be restored.

It isn't actually Postfix performing the server side of the TLS
handshake, it is actually OpenSSL and it is the camera that decices to
hang up.

> Unfortunately, I will not be able to implement the Steps 1-3 proposed
> by you, because my knowledge is not enough for this.

Just step 1 should be easy, replace your server certificate with a
2048-bit self-signed certificate.  4096-bit RSA certificates are
pointless.

> Thefore apparently, me will have to use plain text, although it's not safe :-(

Any particular reason you can't replace the key and certificate with a
more reasonable 2048-bit pair?

$ dnsname=mailserver.mail.lan
$ rm certkey.pem
$ openssl req -new -nodes -newkey rsa:2048 -keyout /dev/stdout \
-config <(
printf 'distinguished_name=dn\n[dn]\nprompt=yes\n'
) -x509 -subj / -days 3653 \
-addext "basicConstraints = critical,CA:FALSE" \
-addext "extendedKeyUsage = serverAuth" \
-addext "subjectAltName = DNS:$dnsname" >> certkey.pem

(On Linux systems make sure to use ">>" not ">" to redirect the output).

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

[pfx] Re: any web.de staff here?

[Viktor Dukhovni via Postfix-users]

On Sun, Apr 16, 2023 at 09:15:24AM +0800, tom--- via Postfix-users wrote:

> one of web.de's sender IPs is listed into zen.spamhaus.org as the 
> following info.
> 
> 554 5.7.1 Service unavailable; Client host [82.165.159.35] blocked using
> zen.spamhaus.org; https://www.spamhaus.org/sbl/query/SBL175032

Intentionally at the request of web.de it seems.  Did you read:

https://www.spamhaus.org/sbl/query/SBL175032

If your message was blocked, and was not spam, contact:

https://postmaster.web.de/en/case?c=uar

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

[pfx] Re: Postfix refuses to accept email from video camera

[Viktor Dukhovni via Postfix-users]

On Sun, Apr 16, 2023 at 12:30:14AM +0300, Oleksandr wrote:

> Viktor, How you have analyzed everything perfectly! :-)
> 
> Of course, I cannot influence the camera firmware, it is old and there
> are no new firmware.
> 
> But maybe you can change the Postfix settings so that he makes friends
> with this camera and successfully receives mail from it?

Step 1, deploy a 2048-bit RSA certificate.  If you think that 2048-bit
RSA isn't strong enough for your security needs, you'll be sad to learn
that most of the software deployed on your system is subject to updates
protected by weaker keys, your bank's website uses weaker keys, most of
the "root CAs" in your browser use weaker keys, ...

Step 2.  If necessary, use RSA-SHA1 to create the certificate self-signature.

Step 3.  If necessary, instead get a certificate from a public CA
 trusted by your camera...

Step 4.  Give up and use cleartext.

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

[pfx] Re: Postfix refuses to accept email from video camera

[Viktor Dukhovni via Postfix-users]

On Sat, Apr 15, 2023 at 10:09:10PM +0300, Oleksandr wrote:
> Sorry, I temporarily changed the IP camera to 192.168.8.144, but it doesn't 
> affect anything.
> 
> So, I executed the command:
> 
> # tcpdump -s0 -w file.pcap tcp port 465 and host 192.168.8.144
> 
> The result is in the attachment.

The client supports TLS 1.0 with a limited set of ciphersuites:

Transport Layer Security
SSLv3 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: SSL 3.0 (0x0300)
Length: 55
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 51
Version: TLS 1.0 (0x0301)
Random: 
643aedd813189fd74ec0ef915094bebebebb74c09b93cc7b9d984b33c28fd008
GMT Unix Time: Apr 15, 2023 14:32:56.0 EDT
Random Bytes: 
13189fd74ec0ef915094bebebebb74c09b93cc7b9d984b33c28fd008
Session ID Length: 0
Cipher Suites Length: 12
Cipher Suites (6 suites)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)

The server is willing to play along:

Transport Layer Security
TLSv1 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 74
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 70  

   Version: TLS 1.0 (0x0301)
Random: 
0376d4184cd187ce744acee1fd1a08ff75d69a189ee42860444f574e47524400
GMT Unix Time: Nov  4, 1971 11:13:12.0 EST
Random Bytes: 
4cd187ce744acee1fd1a08ff75d69a189ee42860444f574e47524400
Session ID Length: 32
Session ID: 
37172fb3722f19f410f9820447f1f980e7809a69d0735e59e0ed86b43e8dc749
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Compression Method: null (0)

The server hello sent together with a self-signed certificate and
2048-bit DH key exchange message and the client hangs up (sends a TCP
RST).

The certificate issuer and subject names are:

RDNSequence item: 1 item (id-at-countryName=CN)
RDNSequence item: 1 item (id-at-stateOrProvinceName=GuangDong)
RDNSequence item: 1 item (id-at-localityName=ShenZhen)
RDNSequence item: 1 item (id-at-organizationName=mailserver.mail.lan)
RDNSequence item: 1 item (id-at-organizationalUnitName=IT)
RDNSequence item: 1 item (id-at-commonName=mailserver.mail.lan)
RDNSequence item: 1 item (pkcs-9-at-emailAddress=r...@mailserver.mail.lan)

Perhaps the camera actually wants to verify the certificate (WebPKI CA
issued)?

The validity dates are:

notBefore: utcTime (0)
utcTime: 2023-04-14 17:12:00 (UTC)
notAfter: utcTime (0)
utcTime: 2033-04-11 17:12:00 (UTC)

The public key modulus is:

e2356b12d6dfd18b4aae39cdbdef295d4a91d0b9d974543506377b1704c4145e
d555df8c38d07d9a8f08e59cd4ba9831344ec3da0abcde707102c18626717512
36dd38c6d34c7ef7763ffe36b036b0d89972156bf0ab8ec8e5dc2815765888cb
2f3203425bc53f8d38d045da6a6ff37d69814f0cf87e4f6893abe7e4234eb35a
2014688a644f15de8510b364b86e7c51d2f36d2a0a0e2b834241f2158f0ea9ec
7645d4f8d0a92213a0494a6b60e71d0ad62ae03db6fd10b634bdd63ad212e965
d25f31fc1c2cc2b4b3f28cedfc12007b4b4b4b6e53257db464373f8e53348064
d82e7fb440d8bbf5e4d8d14e435ce6030b43afc8e121f7b0f35551993029ba57
1245cce875eef43693bec5baa4ffb6d4b2d1575f95fdb6f136c98ef23510b1ba
0e09dedd811267836bf6049359fd0a8a8b68929ef8ebade5d9aab0aafc9a4f6f
81955b06b55f312106d46e589794ef941bc97fe728c16271fa1bb4dc38b7560a
eb56f53a34bc635b6765978e3ef57d74e95a190603037b708b3b7cec618a3180
6b166c303608a34bea95c2e3076690d4cdfddb3de9467eca902c12e8e4cba1d1
739efb07e1f2a14588272dceaa844231a6cf4ef3ce78c6817e8e3545a2ccfbf1
988ef459180e997933896e53d7d34c6bb64b175e3e4092a0106e50d1e599f166
5343976f0a45104cce83cac3649f209f5f3fd86ec118d8204732c8965e1afb01

which at 4096 bits is both silly and perhaps too large for the camera to
support.  If you need that level of security, you shouldn't be using
RSA.  The self-signature is: sha256WithRSAEncryption, perhaps the camera
only supports SHA1?

-- 
   

[pfx] Re: Postfix refuses to accept email from video camera

[Viktor Dukhovni via Postfix-users]

On Sat, Apr 15, 2023 at 08:09:58PM +0200, Benny Pedersen via Postfix-users 
wrote:

> > As stated above, there was no need.  What's needed now is a PCAP file
> > with a full recording of exactly one TCP connection between the camera
> > and Postfix on port 465.
> 
> first remove the 2nd port 465
> 
> imho postfix list this as error ?

You're not helping.  Please stop.

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

[pfx] Re: Postfix refuses to accept email from video camera

[Viktor Dukhovni via Postfix-users]

On Sat, Apr 15, 2023 at 08:37:14PM +0300, Oleksandr wrote:
> > > provide postconf -nf not just raw file, and postconf -Mf not just raw 
> > > file
> > 
> > No longer necessary.
> 
> Please, here are the results of executing this command in attachment:

As stated above, there was no need.  What's needed now is a PCAP file
with a full recording of exactly one TCP connection between the camera
and Postfix on port 465.

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

[pfx] Re: Postfix refuses to accept email from video camera

[Viktor Dukhovni via Postfix-users]

On Sat, Apr 15, 2023 at 05:57:51PM +0200, Benny Pedersen via Postfix-users 
wrote:

> add 192.168.1.44 to mynetwork in postfix main.cf, in master.cf allow 
> permit_mynetwork before permit

Irrelevant.  The TLS connection setup hadn't completed yet.

> but best is simply to make another master.cf entry listner for the 
> camera so this new entry does allow plain text submissions without 
> ssl/tls

Yes, cleartext submission could be an option.

> provide postconf -nf not just raw file, and postconf -Mf not just raw 
> file

No longer necessary.

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

[pfx] Re: Postfix refuses to accept email from video camera

[Viktor Dukhovni via Postfix-users]

On Sat, Apr 15, 2023 at 05:39:21PM +0300, Oleksandr via Postfix-users wrote:

> However, Postfix refuses to accept mail from the video camera and
> demonstrates these lines in the log:

That's not an accurate statement.  Postfix is happy to accept mail from
the camera, but the camera aborts the transmission.

> Apr 14 23:00:08 mailserver postfix/smtps/smtpd[1653]: connect from 
> unknown[192.168.1.44]
> Apr 14 23:00:08 mailserver postfix/smtps/smtpd[1653]: SSL_accept error from 
> unknown[192.168.1.44]: Connection reset by peer
> Apr 14 23:00:08 mailserver postfix/smtps/smtpd[1653]: lost connection after 
> CONNECT from unknown[192.168.1.44]
> Apr 14 23:00:08 mailserver postfix/smtps/smtpd[1653]: disconnect from 
> unknown[192.168.1.44] commands=0/0
> 
> Friends, please tell me how I can fix this problem?

Make available a "PCAP" file (binary data, not text decode) of a single
failed TCP connection between the camera and the server captured via (on
a multihomed host perhaps also "-i "):

# tcpdump -s0 -w /some/where/file.pcap tcp port 465 and host 192.168.1.44

>   465inet  n   -   n   -   -   smtpd
>   -o syslog_name=postfix/smtps
>   -o smtpd_tls_wrappermode=yes
>   -o smtpd_sasl_auth_enable=yes
>   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
>   -o content_filter=smtp-amavis:[127.0.0.1]:10026
>
>   smtpd_tls_CAfile = /etc/ssl/certs/iRedMail.crt
>   smtpd_tls_CApath = /etc/ssl/certs
>   smtpd_tls_cert_file = /etc/ssl/certs/iRedMail.crt
>   smtpd_tls_key_file = /etc/ssl/private/iRedMail.key

Post the server's full certificate chain, that is the output of:

$ (sleep 2; printf "QUIT\r\n") |
openssl s_client -connect 127.0.0.1:465 -showcerts 2>&1 |
openssl crl2pkcs7 -nocrl -certfile /dev/stdin |
openssl pkcs7 -print_certs -text -noout

>   smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH,
>   EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA

Just use the default ciphers with no exclusions, a random set of
exclusions does not do you much good (there's no such cipher class in
OpenSSL as aECDH, for example, the DES and EXPORT ciphers are long gone,
eNULL is already disabled by default, and there's no good reason to
disable aNULL ciphers, ...).

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

[pfx] Re: header_checks not work with regexp

[Viktor Dukhovni via Postfix-users]

On Fri, Apr 14, 2023 at 05:51:21PM -0300, SysAdmin EM via Postfix-users wrote:

> postmap -q "Subject: [KIS] ERROR (EXTERNAL IP): Invalid HTTP_HOST header: 
> '10.54.130.188:8020'. You may need to add u'10.54.130.188' to ALLOWED_HOSTS." 
> regexp:/etc/postfix/header_checks

Works here (bash syntax):

$ hdr="Subject: [KIS] ERROR (EXTERNAL IP): Invalid HTTP_HOST header: 
'10.54.130.188:8020'. You may need to add u'10.54.130.188' to ALLOWED_HOSTS."
$ rule='/^Subject:.*You may need to add.*/ DISCARD BLOCK_TEMPORAL'
$ postmap -q "$hdr" regexp:<(printf "%s\n" "$rule")
DISCARD BLOCK_TEMPORAL

> any ideas??

Your testing methodology is flawed or regexp rule file is malformed.
The file should contain:

/^Subject:.*You may need to add.*/  DISCARD BLOCK_TEMPORAL

on a single line with no leading whitespace, and not have any syntax
issues on any other lines.

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

[pfx] Re: header_checks not work with regexp

[Viktor Dukhovni via Postfix-users]

On Fri, Apr 14, 2023 at 03:31:17PM -0300, SysAdmin EM via Postfix-users wrote:

> Sorry for such a basic question but I couldn’t find a solution on my
> part.  I’m trying to block a Subject using header_checks but it’s not
> working.
> 
> This is my rule:
> 
> /^Subject:.*Invalid HTTP_HOST header.*/ DISCARD SUBJECTALERT

This looks OK, and expects a "Subject:" header.

> I used postmap to test the rule but not match.
> 
> postmap -q "[KIS] ERROR (EXTERNAL IP): Invalid HTTP_HOST header: 
> '10.54.130.188:8020'. You may need to add u'10.54.130.188' to ALLOWED_HOSTS." 
> regexp:/etc/postfix/header_checks

This is not a "Subject:" header.  Perhaps you meant to type:

postmap -q "Subject: [KIS] ERROR (EXTERNAL IP): Invalid HTTP_HOST header: 
'10.54.130.188:8020'. You may need to add u'10.54.130.188' to ALLOWED_HOSTS." 
regexp:/etc/postfix/header_checks

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

[pfx] Re: temporary lookup error with utf8mb4 characters

[Viktor Dukhovni via Postfix-users]

On Fri, Apr 14, 2023 at 01:06:16PM -0400, Wietse Venema via Postfix-users wrote:

> Wietse Venema via Postfix-users:
> > As for the temp error becoming persistent, the Postfix pgsql: client
> > code returns an error when it gets an error from all of the hosts
> > configured in the Postfix pgsql: client configuration file, or when
> > all hosts have been flagged as 'down'. If a host returns an error
> > then the Postfix pgsql: client code flags that host as 'down', and
> > resets that 'down' state after about 60 seconds.
> 
> As implemented, the Postfix pgsql: clien code treats all errors as
> a connection failure, and skips the connection for 60 seconds. That
> may not be optimal when an error is data dependent.

FWIW, the OP's issue was with MySQL, not Postgres...  The database
should be configured for client and server encoding of UTF8.

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

[pfx] Re: Debugging SSL_accept error Connection reset by peer

[Viktor Dukhovni via Postfix-users]

On Tue, Apr 11, 2023 at 08:32:19AM -0400, micah anderson via Postfix-users 
wrote:

> >> The certificate that the server sends (smtpd_tls_cert_file) is [...]
> >> is the client refusing my certificate at this stage?
> >
> > See above.  Your certificate details look fine:
> 
> Good.

Of course some clients may expect a different issuing CA, or some other
non-obvious content.

> >> smtpd_tls_ask_ccert = yes
> >
> > You should probably NOT request client certificates on port 25.
> > Some clients are likely to not be able to decline the request.
> >
> > This could well be the problem.
> 
> I removed that.

Good.

> Restarted postfix after these changes and triggered the remote client to
> try again, but unfortunately, the same error happens. Same thing in the
> pcap: I say Server Hello Done, and then the client sends a RST, ACK.
> 
> Any other ideas of things I could try?

No, the rest requires insight from the sending end.

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

[pfx] Re: Postfix as relay server let us send messages with anothyer domain than ours

[Viktor Dukhovni via Postfix-users]

On Tue, Apr 11, 2023 at 03:34:09PM -0300, Roberto Carna via Postfix-users wrote:

> But we have realized that if we send messages using another domains
> than ourdomain1.com, the messages reach the recipients in Gmail,
> Hotmail and other public mail platforms.

Perhaps as well considering how to address this, you might also consider
whether you're addressing the right problem...

When an authorised message is slated to leave your network, the
consequences are least signficant when it purports to originate from
somebody else's domain.

- Many receiving systems are liable to reject a message purporting
  to originate from an unexpected domain (based on DMARC, ...).

- There's little risk of reputational or financial damage if
  the message does not impersonate a sender in your domain.

On the other hand, if the message *is* from your domain, but
is an unauthorised message misleading your customers or business
partners, ... *then* you have a problem.

While Postfix can to some extent enforce envelope to sender mismatches,
the real concern is usually the "From:" header, ... whose content is not
the MSAs job to enforce.

Instead, if you really want to lock down email security on your network,
you'll need to:

- Accept outbound email only from authenticated *managed* systems.

- On each managed system restrict access to email submission to be
  only via managed MUAs, that ensure that header and envelope
  addresses are authorised to the user in question at the point
  of message submission.

These are complex goals, and often not worth pursuing, unless the risk
exposure is particularly high.

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

[pfx] Re: aliases for mailbox domain

[Viktor Dukhovni via Postfix-users]

On Tue, Apr 11, 2023 at 12:49:18AM +0800, tom--- via Postfix-users wrote:

> > You can create virtual(5) aliases for any address you want, with
> > any syntactically valid rewrite target(s) of your choice.
> > 
> > Neither the LHS nor the RHS addresses need be in domains under your
> > control.  The virtual(5) alias table rewrites **all** recipient
> > addresses.
> 
> Thank you. So what’s the usage of virtual alias domains?

Have you read:

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

The virtual alias domain class.

Purpose: hosted domains where each recipient address is aliased to an
address in a different domain, for example, a local UNIX system account
or a remote address. A virtual alias example is given in the
VIRTUAL_README file.

Domain names are listed in virtual_alias_domains. The default value is
$virtual_alias_maps for Postfix 1.1 compatibility.

Valid recipient addresses are listed with the virtual_alias_maps
parameter. The Postfix SMTP server rejects invalid recipients with "User
unknown in virtual alias table". The default value is $virtual_maps for
Postfix 1.1 compatibility.

There is no mail delivery transport parameter. Every address must be
aliased to an address in some other domain.

Which also links to:

https://www.postfix.org/VIRTUAL_README.html#canonical

Perhaps implicit in the above references is that Postfix accepts
incoming mail for (valid) recipients in virtual_alias_domains, even when
the client is not listed in mynetworks or SASL authenticated, ...

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

[pfx] Re: aliases for mailbox domain

[Viktor Dukhovni via Postfix-users]

On Mon, Apr 10, 2023 at 04:19:28PM +0800, tom--- via Postfix-users wrote:

> And a real user t...@myposts.ovh which exists in dovecot-users table.
> 
> After then, can I create aliases in virtual_alias_maps like follows?
> 
> al...@myposts.ovh  t...@myposts.ovh
> b...@myposts.ovh  t...@myposts.ovh

You can create virtual(5) aliases for any address you want, with
any syntactically valid rewrite target(s) of your choice.

Neither the LHS nor the RHS addresses need be in domains under your
control.  The virtual(5) alias table rewrites **all** recipient
addresses.

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

[pfx] Re: DNS resolvers difference for RBL checks

[Viktor Dukhovni via Postfix-users]

On Mon, Apr 10, 2023 at 10:22:24AM +0800, tom--- via Postfix-users wrote:

> > My comiserations...
> 
> Do you mean systemd-resolve is a bad choice for local resolver?

Wow, you read my mind! :-)

The only use-case I can think of for systemd-resolved is on mobile
devices, or home networks, where autoconfiguration or support for mdns
might be useful.  On a server, I'd like to recommend a real resolver.

-- 
Viktor.


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

[pfx] Re: REPOST: Envelope sender is not modified correctly

[Viktor Dukhovni via Postfix-users]

On Sun, Apr 09, 2023 at 10:29:46PM -0400, François wrote:

> I did post the relevant parts (I believe) of main.cf:

If you were fully equipped to know what's relevant, you'd not need to
look for help here.  When you do seek help here, you need to be willing
to let others judge what is relevant.

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

[pfx] Re: REPOST: Envelope sender is not modified correctly

[Viktor Dukhovni via Postfix-users]

On Sun, Apr 09, 2023 at 08:08:04PM -0400, François via Postfix-users wrote:

> The regexp:/etc/postfix/canonical just did not want to map reliably a
> domain name to a certain Return-Path, even though I tested successfully all
> regular expressions with (for example):
> 
> postmap -q "info[at]ghi.com" regexp:/etc/postfix/canonical
> 
> when used to test the file listing the following:
> 
> /@abc\.com/  address_1[at]whereto.com
> /@def\.com/   address_1[at]whereto.com
> /@ghi\.com/   address_2[at]whereto.com
> /@jkl\.com/ address_1[at]whereto.com

You had a mistake in "main.cf", which you never posted:

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

> Those are pretty vanilla regular expressions matching all email addresses
> of the listed domains.

They are (typically) sloppy.  The correct form is:

/@abc\.com$/  addres...@whereto.com
/@def\.com$/  addres...@whereto.com
/@jkl\.com$/  addres...@whereto.com
/@ghi\.com$/  addres...@whereto.com

Also, in case it is applicable, keep in mind that canonical mapping is
recursive, and will apply to the RHS forms, should those also match.

> Why "postmap -q" and the actual sending of a message from these
> domains behave differently I just don't understand.

No telepaths on this list:

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

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

[pfx] Re: DNS resolvers difference for RBL checks

[Viktor Dukhovni via Postfix-users]

On Mon, Apr 10, 2023 at 09:14:19AM +0800, tom--- via Postfix-users wrote:
> I have two debian boxes, one is running unbound for dns resolver, 

Congratulations on a sound choice.

> another is running systemd-resolve.

My comiserations...

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

[pfx] Re: confused about two options

[Viktor Dukhovni via Postfix-users]

On Sun, Apr 09, 2023 at 09:35:49AM +0800, tom--- via Postfix-users wrote:

> >> 2. Content-Transfer-Encoding: 7bit
> > 
> > The 2nd is more of a property assertion, than an encoding.  The
> > MIME-part content is transmitted as-is, but is asserted to consist
> > entirely of 7-bit octets (i.e. still 8-bit octets, but in the range
> > 0–127). Similarly, the "8bit" transfer encoding is also an "identity"
> > encoding, which makes no promise about the high bit of the content.
> 
> (1) With testing (sent from roundcube, read from gmail) I found that:
> 
> X-Sender: t...@myposts.ovh
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 8bit
> 
> 两鬓可怜青，只为相思老。
> 无情不似多情苦，一寸还成千万缕。
> 
> 
> As you see with chinese UTF8 characters the transfer-encoding has been 
> set to 8bit.

I am not sure what point you're trying to make...

> So my guess:
> 
> (1) in smtp session, both 7bit, 8bit are allowed. for example, UTF-8 use 
> 8bit for transfer.

No guessing, or even experiments are required, the MIME specification in
RFC 2045 is 26+ years old.

- When an SMTP server advertises the 8BITMIME ESMTP feature the sending
  SMTP client can send 8bit text content without applying a transfer
  encoding.  This is useful for *line-oriented* text content.  Such as
  this message, with a bit of gratuituous non-ASCII content thrown in:

Ой у лузі червона калина похилилася,
Чогось наша славна Україна зажурилася.
А ми тую червону калину підіймемо,
А ми нашу славну Україну, гей-гей, розвеселимо!

- However, 8bit transfer encoding is not suitable for raw binary data,
  such as image files, because:

o It is not line-oriented.  Use of  line-endings will corrupt
  binary data.
o Conversion to some local text encoding will corrupt binary data.
o ...

  For raw binary data SMTP generally uses base64.

> (2) If the content is binary, base64 or QP should be used. in transfer 
> process, base64 still uses 7bit.

Quoted printable is for textual content which contains long lines, and
is mostly ASCII.  It is not well suited for other binary data.

Read RFCs 2045–2047.

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

[pfx] Re: Headers and Forwarding

[Viktor Dukhovni via Postfix-users]

On Sat, Apr 08, 2023 at 12:16:30PM -0700, Doug Hardie via Postfix-users wrote:

> >> Are there any others and how close am I?
> > 
> >
> > https://www.iana.org/assignments/mail-parameters/mail-parameters.xhtml#mail-parameters-7
> 
> Wow, I never would have guessed there would be that many.  Thanks.

For SMTP (as opposed to LMTP), you were only off by a factor of ~2,
there's a second "base" value of "UTF8SMTP".  The full set for SMTP is:

SMTP Simple Mail Transfer Protocol [RFC5321]
ESMTP SMTP with Service Extensions [RFC5321]
ESMTPA ESMTP with AUTH [RFC3848]
ESMTPS ESMTP with STARTTLS [RFC3848]
ESMTPSA ESMTP with both STARTTLS and AUTH [RFC3848]
UTF8SMTP ESMTP with SMTPUTF8 [RFC6531]
UTF8SMTPA ESMTP with SMTPUTF8 and AUTH [RFC4954][RFC6531]
UTF8SMTPS ESMTP with SMTPUTF8 and STARTTLS [RFC3207][RFC6531]
UTF8SMTPSA ESMTP with SMTPUTF8 and both STARTTLS and AUTH 
[RFC3207][RFC4954][RFC6531]

These are correctly used in Postfix and a few other MTAs, and then
there's Microsoft, where even the basic atom syntax is violated:

with Microsoft SMTP Server

or MessageLabs:

with AES128-GCM-SHA256 encrypted SMTP

c.f.

https://www.rfc-editor.org/rfc/rfc5321#section-4.4

   Protocol   = "ESMTP" / "SMTP" / Attdl-Protocol
   Attdl-Protocol = Atom
  ; Additional standard names for protocols are
  ; registered with the Internet Assigned Numbers
  ; Authority (IANA) in the "mail parameters"
  ; registry [9].  SMTP servers SHOULD NOT
  ; use unregistered names.

other violations are less severe:

with HTTP
with mapi
with bizsmtp
with ngmta
...

Apparently, reading RFC5321 and RFC5322 is too tedious.

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

[pfx] Re: Headers and Forwarding

[Viktor Dukhovni via Postfix-users]

On Sat, Apr 08, 2023 at 11:51:06AM -0700, Doug Hardie via Postfix-users wrote:

> A couple of questions.  Looking in the postfix generated Received:
> header, the SMTP id often has a few other letters included:  ESMTPA
> etc.  I am guessing that the extra letters mean: 
> 
>   E - EHLO used rather the HELO
>   S - SSL was used in the connection
>   A - the originator was authenticated
> 
> Are there any others and how close am I?


https://www.iana.org/assignments/mail-parameters/mail-parameters.xhtml#mail-parameters-7

> When the alias file pipes an email to a program, does it expect any
> response from that program,

Only a 0 exit status code, in which case the program should not generate
any output.

> or would it do anything with a response?

If an error occurs some of the output might be included in the bounce.

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

[pfx] Re: invalid and non-fqdn hostname

[Viktor Dukhovni via Postfix-users]

On Sat, Apr 08, 2023 at 11:49:49AM +1000, Sean Gallagher via Postfix-users 
wrote:

> I think the outcome of the discussion in this thread was that 
> valid_utf8_hostname() really has no "official" use case.

Not all hostnames are HELO hostnames.  The domain part of an email
address is a "hostname" when not a domain-literal.  An SMTP nexthop name
in a transport table is a hostname, ...

> It allows RAW UTF8 in hostnames - which should never happen.

See above.

> Hostnames that contain Unicode (non ASCII) code-points should be
> encoded with punycode with the ACE prefix.  Any name encoded this way
> should pass the valid_hostname() check.

IDNA2008 and EAI define how to map unicode names into an ASCII DNS.
One now needs to know what sort of name to expect in a given context.

A further complication is that the Unicode Consortium produced a
competing specification UTS#46 that subsumes IDNA2003 and IDNA2008 and
conflicts with both.

The UTS#46 specification has a competitive advantage, it that it is
directly supported by running code (libicu, ...).  While the IETF
specifications are just words "on paper" (at some web site).

So Postfix in fact uses UTS#46 with legacy IDNA2003 compatibility
disabled (closer to IDNA2008).  This pragmatic choice is not uncommon,
so UTS#46 may be "winning" at present.

> In summary, all "normal" systems should be using 
> "reject_invalid_helo_hostname" and leave "reject_non_fqdn_helo_hostname" 
> to isolated systems whose names never appear on the internet.

No.  In summary, an oversight should (and will) be fixed in Postfix.

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