[pfx] masquerade_domains does not work for relayed domain

[Aleksandar Ivanisevic via Postfix-users]

Is it true that masquerade_domains does not work for header From: in relayed 
emails? I have a fairly generic setup:

masquerade_classes = envelope_sender, header_sender, header_recipient
masquerade_domains = mydomain.com

that does indeed rewrite envelope from, but not header from, and subsequently 
DKIM signer (opendkim) in my relay does not match and does not sign the email.

if this is true, how do i properly masquerade header from in relayed emails?

header_checks? Does not seem to have regexp groups replace so

/From: (.*)@.*?mydomain.com/  REPLACE From: 
$1...@mydomain.com 

does not seem to work and it does not really cover all cases like From: “some 
name “ , etc.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

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

[Jakob Cornell via Postfix-users]

The logging code lives outside the individual table drivers and with "_maps" 
parameters that support multiple tables, above any individual table lookup.


Oh I see. Well without rearchitecting the logging it seems this could be made 
more intuitive for the case where all of the maps in a sequence are skipped 
(e.g. my case with a single regexp table).

If I understand right the non-indexed skip is implemented by the 'continue' at 
global/maps.c:199, so a flag could be added to track whether execution has 
passed line 199 and if not, the log statement at 221 could be skipped.

Whether this would actually be a net benefit I'm not sure, but it seemed worth 
mentioning.


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


Ah, didn't see this before in the man page.

Thoughts on updating the documentation for check_recipient_access to mention 
the indexed/non-indexed distinction? Thoughts on more fully documenting which 
table types do partial key lookups?

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

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

[Viktor Dukhovni via Postfix-users]

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

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

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

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

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

My notices to these domains include the below advice:

[ Perhaps consider: ?

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

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

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

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

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

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

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

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

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

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

[Viktor Dukhovni via Postfix-users]

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

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

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

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

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

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

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

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

[Akshay Pushparaj via Postfix-users]

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


That is possible (with static: mapping) but not a good idea.

May i know why it's not a good idea?


Users are split between LDAP in my server and a remote server for
example.com. So if u...@example.com is not present in LDAP it must
forward to remote server.


How would Postfix know that the address is valid? If your answer
is: return the message to the sender if ther recipient is not valid,
then that is the wrong reply.
I would have to use a static map of valid addresses, otherwise the mail 
would loop between 2 servers.


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

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

[Akshay Pushparaj via Postfix-users]

On 06/02/24 23:18, Viktor Dukhovni via Postfix-users wrote:

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

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

Will frame questions better next time.


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

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

Thanks.


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

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

[Jakob Cornell via Postfix-users]

Thanks Viktor. I found what I believe you're referencing in the access(5) man 
page:


With lookups from indexed files such as DB or DBM,  or  from  networked
tables  such  as  NIS,  LDAP or SQL, patterns are tried in the order as
listed below:


Is this the only documentation explaining this distinction? It doesn't state 
which table types are indexed, and in the database readme only a few types are 
called out as indexed. (My testing indicates the 'inline' type is indexed, but 
I can't find mention of this in the documentation.)

While the documentation for 'check_recipient_access' in postconf(5) links to 
access(5), it doesn't mention the indexed table type distinction, implying the 
lookup sequence for indexed files is used regardless of the table type:


check_recipient_access type:table
Search the specified access(5) database for the resolved RCPT TO address, 
domain, parent domains, or localpart@, and execute the corresponding action.


And then there's the confusing logs from my original email which appear to show 
the full lookup sequence being done on a regexp table. My assumption is that 
the full lookup sequence is actually being processed, but individual lookups 
beyond the first one are being skipped without skipping the corresponding 
logging code.

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

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

[pfx] Re: ARC or DKIM or SRS?

[Alex via Postfix-users]

Hi,

On Mon, Feb 12, 2024 at 5:39 AM Jaroslaw Rafa via Postfix-users <
postfix-users@postfix.org> wrote:

> Dnia 11.02.2024 o godz. 17:47:05 Alex via Postfix-users pisze:
> > My concern would be with multiple MX records for the same domain - is it
> > possible it would come back to try again with another MX and be delayed
> yet
> > again?
>
> MX are the addresses that *receive* mail for a given domain, not the
> addresses from which mail is sent. These would be specified in SPF record
> (if present).
>

Yes, of course. I'm sorry I gave you another impression of what I was
asking.

I'll check out postscreen_cache_map in case it can do most of what I need,
but my interest is from the server side, which is where postscreen is also
run, of course.

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

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

[Wietse Venema via Postfix-users]

Aleksandar Ivanisevic via Postfix-users:
> 
> Is it true that masquerade_domains does not work for header From: in relayed 
> emails? I have a fairly generic setup:
> 
> masquerade_classes = envelope_sender, header_sender, header_recipient
> masquerade_domains = mydomain.com
> 
> that does indeed rewrite envelope from, but not header from, and
> subsequently DKIM signer (opendkim) in my relay does not match and
> does not sign the email.

Can I see some evidence before I sink a bunch of time into answering
a question?

The From: address should be rewritten by cleanup_rewrite_sender(),
assuming that (receive_override_options = no_address_mappings) is not
in effect:

if (state->flags & CLEANUP_FLAG_MAP_OK) {
...
if (cleanup_masq_domains
&& (cleanup_masq_flags & CLEANUP_MASQ_FLAG_HDR_FROM))
did_rewrite |=
cleanup_masquerade_tree(state, *tpp, cleanup_masq_domains);

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

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

[Viktor Dukhovni via Postfix-users]

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

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

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

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

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

[Aleksandar Ivanisevic via Postfix-users]

> On 27. Jan 2024, at 14:23, Wietse Venema via Postfix-users 
>  wrote:
> 
> Aleksandar Ivanisevic via Postfix-users:
>> i would like to have maximal_queue_lifetime (and possibly some
>> other parameters) based on the sender address. So I did the following
> 
> This request is unlikely to be implemented. It is one of those
> features that benefit a very small fraction of the pupulation at a
> dispropertionate cost for implementation and maintenance.
> 
>> in main.cf
>> sender_dependent_default_transport_maps = hash:/etc/postfix/relay_by_sender
>> 
>> in /etc/postfix/relay_by_sender
>> mysender.com smtp:[localhost]:588
>> 
>> in master cf
>> 588   inet n   -   n   -   -   smtpd -o 
>> maximal_queue_lifetime=1d -o sender_dependent_default_transport_maps=
> 
> maximal_queue_lifetime and sender_dependent_default_transport_maps
> are implemented in different programs. Postfix programs cannot send
> main.cf settings into other Postfix programs. That is not a bug but
> a safety feature.


thanks, thats what I thought. For posterity, I’ve solved it by setting 
max_queue_time to whatever my maximum is, and then periodically running custom 
script(s) that dequeue early, something like this:

#!bin/bash

export PATH=/usr/sbin:$PATH

find $(postconf -h queue_directory)/deferred -type f | while read qf; do
  qid=${qf##*/}
  if postcat -h $qf 2>/dev/null | fgrep something
  echo "$qid contains something, deleting" 
  postsuper -d $qid &> /dev/null
  fi
done___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: postfix alternating between mail.example.com and real hostname?

[Joachim Lindenberg via Postfix-users]

Thanks to Bill and Benny for the pointer to 
https://www.postfix.org/DEBUG_README.html#mail.
Using tcpdump I figured out that a monitoring task using OpenSsl (with 
hardcoded mail.example.org) was reusing the same ip (via NAT). You´d call it 
gremlins 
Joachim


-Ursprüngliche Nachricht-
Von: Bill Cole via Postfix-users  
Gesendet: Montag, 12. Februar 2024 16:18
An: Joachim Lindenberg via Postfix-users 
Betreff: [pfx] Re: postfix alternating between mail.example.com and real 
hostname?

On 2024-02-12 at 07:07:03 UTC-0500 (Mon, 12 Feb 2024 13:07:03 +0100) Joachim 
Lindenberg via Postfix-users  is rumored to have 
said:

> I haven´t seen this before, but at present my mail server is kind of 
> alternating between mail.example.com and the real hostname (or someone 
> is spoofing my IP-address which I doubt).

It is not at all clear what you actually mean by that. Any MTA has a 
potentially complicated collection of different "identities" used in different 
context. E.g. in Postfix you've got origin domain names, destination domain 
names,  hostnames used in MX records, and a hostname used in HELO/EHLO 
greetings.

Or is the 'alternating' happening in DNS? We cannot know...

> All configuration files I checked indicate the correct setting and 
> postconf myhostname returns the correct name. Thus I am wondering 
> whether this might be caused by a recent change of postfix, which 
> happens tob e 3.5.23 – the mail server is a mailcow-dockerized 
> instance which still uses images based on debian-bullseye.
>
> Any idea for the cause and a fix?

My guess: Gremlins.

You might get more useful answers by including the illuminating information 
described at https://www.postfix.org/DEBUG_README.html#mail
in the section titled "Reporting problems to postfix-users@postfix.org"




--
Bill Cole
b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many 
*@billmail.scconsult.com addresses) Not Currently Available For Hire 
___
Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an 
email to postfix-users-le...@postfix.org

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

[pfx] masquerade_domains does not work for relayed domain

[Aleksandar Ivanisevic via Postfix-users]

Is it true that masquerade_domains does not work for header From: in relayed 
emails? I have a fairly generic setup:

masquerade_classes = envelope_sender, header_sender, header_recipient
masquerade_domains = mydomain.com

that does indeed rewrite envelope from, but not header from, and subsequently 
DKIM signer (opendkim) in my relay does not match and does not sign the email.

if this is true, how do i properly masquerade header from in relayed emails?

header_checks? Does not seem to have regexp groups replace so

/From: (.*)@.*?mydomain.com/  REPLACE From: 
$1...@mydomain.com 

does not seem to work and it does not really cover all cases like From: “some 
name “ , etc.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: postfix alternating between mail.example.com and real hostname?

[Bill Cole via Postfix-users]

On 2024-02-12 at 07:07:03 UTC-0500 (Mon, 12 Feb 2024 13:07:03 +0100)
Joachim Lindenberg via Postfix-users 
is rumored to have said:

I haven´t seen this before, but at present my mail server is kind of 
alternating between mail.example.com and the real hostname (or someone 
is spoofing my IP-address which I doubt).


It is not at all clear what you actually mean by that. Any MTA has a 
potentially complicated collection of different "identities" used in  
different context. E.g. in Postfix you've got origin domain names, 
destination domain names,  hostnames used in MX records, and a hostname 
used in HELO/EHLO greetings.


Or is the 'alternating' happening in DNS? We cannot know...

All configuration files I checked indicate the correct setting and 
postconf myhostname returns the correct name. Thus I am wondering 
whether this might be caused by a recent change of postfix, which 
happens tob e 3.5.23 – the mail server is a mailcow-dockerized 
instance which still uses images based on debian-bullseye.


Any idea for the cause and a fix?


My guess: Gremlins.

You might get more useful answers by including the illuminating 
information described at https://www.postfix.org/DEBUG_README.html#mail 
in the section titled "Reporting problems to postfix-users@postfix.org"





--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: postfix alternating between mail.example.com and real hostname?

[Benny Pedersen via Postfix-users]

Joachim Lindenberg via Postfix-users skrev den 2024-02-12 13:07:


Any idea for the cause and a fix?


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


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

[pfx] postfix alternating between mail.example.com and real hostname?

[Joachim Lindenberg via Postfix-users]

I haven´t seen this before, but at present my mail server is kind of 
alternating between mail.example.com and the real hostname (or someone is 
spoofing my IP-address which I doubt).

All configuration files I checked indicate the correct setting and postconf 
myhostname returns the correct name. Thus I am wondering whether this might be 
caused by a recent change of postfix, which happens tob e 3.5.23 – the mail 
server is a mailcow-dockerized instance which still uses images based on 
debian-bullseye.

Any idea for the cause and a fix?

Thanks,

Joachim

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

[pfx] Re: ARC or DKIM or SRS?

[Jaroslaw Rafa via Postfix-users]

Dnia 11.02.2024 o godz. 17:47:05 Alex via Postfix-users pisze:
> My concern would be with multiple MX records for the same domain - is it
> possible it would come back to try again with another MX and be delayed yet
> again?

MX are the addresses that *receive* mail for a given domain, not the
addresses from which mail is sent. These would be specified in SPF record
(if present).
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org