[pfx] Re: local_recipient_maps does not apply to local mail submission

[Étienne Miret via Postfix-users]

Cool! thank-you.

Regards,

--
Étienne Miret
https://etienne.miret.io/


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: local_recipient_maps does not apply to local mail submission

[Wietse Venema via Postfix-users]

I have added text that ``Other Postfix interfaces may still accept an
"unknown" recipient.'' in LOCAL_RECIPIENT_README.html and postconf.proto.

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

[pfx] Re: local_recipient_maps does not apply to local mail submission

[Étienne Miret via Postfix-users]

Hello!


The documentation patch seems to suggest that there are potential
futures in which the parameter also restricts non-SMTP message ingres,
or even delivery after alias expansion for addresses not listed in the
table.


Well, based on previous messages on this thread, I thought this was 
indeed a possibility. I’m not saying I think it should be done, but 
Wietse did say:



There is nothing that prevents local_recipient_maps from being used
elsewhere. The need to do so just hasn't come up.


which opens the possibility.

So I chose a wording that should make clear to users that they cannot 
rely on local_recipient_maps to be ignored by non-SMTP inputs, and 
therefore that they should make sure the lookups specified in this 
setting include all locally deliverable recipients. Essentially, I said:



Whether this setting applies to non-SMTP inputs is unspecified,
don’t rely on either way.


Of course, it can be decided that local_recipient_maps not applying to 
anything else than smtpd is now a documented feature. This would mean a 
configuration where some local users cannot receive mails from the 
Internet is now supported (although I guess this can already be done 
with filters) but also that changing this behavior would now be a 
breaking change, requiring a major version bump and proper warning.


I’m totally fine with that, and can even provide a new patch to document 
this. It’s just in my opinion, such a decision must be carefully 
weighted before it is taken.


Regards,

--
Étienne Miret
https://etienne.miret.io/


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: local_recipient_maps does not apply to local mail submission

[Viktor Dukhovni via Postfix-users]

On Mon, Aug 28, 2023 at 04:14:33PM -0400, Viktor Dukhovni via Postfix-users 
wrote:

> However, neither eventuality is at all likely.  My take is that it would
> not be an unwelcome breaking change to apply the table in any context
> other than SMTP ingres.

s/would not be/would be/

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

[pfx] Re: local_recipient_maps does not apply to local mail submission

[Viktor Dukhovni via Postfix-users]

On Mon, Aug 28, 2023 at 09:01:35PM +0200, Étienne Miret via Postfix-users wrote:

> Anyway, I promised a documentation patch that would make this more 
> explicit, here it is! Sorry it took me a little long to do it, as I have 
> been busy on other issues.

The documentation patch seems to suggest that there are potential
futures in which the parameter also restricts non-SMTP message ingres,
or even delivery after alias expansion for addresses not listed in the
table.

However, neither eventuality is at all likely.  My take is that it would
not be an unwelcome breaking change to apply the table in any context
other than SMTP ingres.

Therefore, if the documentation is to make to make the scope even more
explicit, it should hedge the language in "For now, ...".  Just say it
like it is: the table is used to reject unwanted local SMTP recipients.

One might, for example, reject mail to "root", "bin", "daemon", ... from
outside, but allow local cron jobs to notify appropriate mailboxes
(typically aliased), which means filtering out some accounts:

main.cf:
local_recipient_maps =
pipemap:{
pcre:{{/^"(.*)"(?:@[^@"\\]+)?$$/ $$1},
  {/^(.*?)(?:@[^@"\\]+)?$$/  $$1}},
pcre:{{/^(?:root|bin|daemon)$$/:},
  {/(.*)/$$1}},
unionmap:{proxy:unix:passwd.byname $alias_maps}
}

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

[pfx] Re: local_recipient_maps does not apply to local mail submission

[Étienne Miret via Postfix-users]

Hello,


There is nothing that prevents local_recipient_maps from being used elsewhere. 
The need to do so just hasn't come up.


To be fair, I don’t have any use for this either. It’s just I had a 
misconfiguration on my side, a user wouldn’t get their mails (well, 
myself actually, the postmaster), and /usr/sbin/sendmail -bv said all 
was fine. It don’t think it took me long to find out the issue, though.



As for local_recipient_maps not being checked elsewhere in Postfix:

[…]


Oh! Now I understand your first reply. I was wondering what you meant 
back then.



You had not mentioned LMTP.


I don’t think I mentioned anything else either 🙂.

mailbox_transport and _maps were originally used to deliver mail for UNIX and [1] non-UNIX accounts to a [2] Dovecot command-line tool. Both [1] and [2] were poor solutions. 


Hmm… I was using LMTP through mailbox_transport:

> mailbox_transport = lmtp:unix:private/dovecot-lmtp

Is this bad?


This is why the doc mmentions that local_recipient_maps is used by the SMTP 
daemon.


Indeed, it does. But it doesn’t say it is not used by other processes, 
or at least I didn’t understand that when reading it.


Anyway, I promised a documentation patch that would make this more 
explicit, here it is! Sorry it took me a little long to do it, as I have 
been busy on other issues.


I didn’t see any CONTRIBUTING file with guidelines or how to submit 
patches, so I hope the attachment on this mail will do it. Also, the 
"sources" we can download from  
include the built documentation, so I hope the files I edited under 
proto/ are the actual documentation sources rather than the result of a 
first build phase.


Regards,

--
Étienne Miret
https://etienne.miret.io/
diff -ruN -x README_FILES -x .idea -x html -x man 
/var/tmp/postfix-3.8.1/proto/LOCAL_RECIPIENT_README.html 
Documents/Development/postfix-3.8.1/proto/LOCAL_RECIPIENT_README.html
--- /var/tmp/postfix-3.8.1/proto/LOCAL_RECIPIENT_README.html2023-03-09 
00:35:26
+++ Documents/Development/postfix-3.8.1/proto/LOCAL_RECIPIENT_README.html   
2023-08-28 20:15:41
@@ -57,7 +57,9 @@
 local when its domain matches $mydestination, $inet_interfaces or
 $proxy_interfaces. If a local username or address is not listed in
 $local_recipient_maps, then the Postfix SMTP server will reject
-the address with "User unknown in local recipient table".  
+the address with "User unknown in local recipient table".
+Note that this username may still be able to receive mails from other
+sources (like sendmail(1)). 
 
  The default setting, shown below, assumes that you use the
 default Postfix local(8) delivery agent for local delivery, where
diff -ruN -x README_FILES -x .idea -x html -x man 
/var/tmp/postfix-3.8.1/proto/postconf.proto 
Documents/Development/postfix-3.8.1/proto/postconf.proto
--- /var/tmp/postfix-3.8.1/proto/postconf.proto 2023-06-05 21:12:17
+++ Documents/Development/postfix-3.8.1/proto/postconf.proto2023-08-28 
20:12:58
@@ -2425,6 +2425,9 @@
 
 If this parameter is non-empty (the default), then the Postfix SMTP
 server will reject mail for unknown local users.
+For now, this parameter is ignored by other processes, which means
+a misconfiguration here can lead to a local user receiving mails
+from sendmail(1) but not from SMTP clients.
 
 
 


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: local_recipient_maps does not apply to local mail submission

[Wietse Venema via Postfix-users]

Etienne Miret via Postfix-users:
> > If there is a DISCREPANCY between local_recipient_maps and your
> > local delivery agent, then you MUST UPDATE your local_recipient_maps
> > accordingly.
> 
> I wasn't complaining about that discrepancy. I was complaining that the 
> local_recipient_maps is only checked for mails submitted through SMTP.

There is nothing that prevents local_recipient_maps from being used
elsewhere. The need to do so just hasn't come up. This is why the
doc mmentions that local_recipient_maps is used by the SMTP daemon.

As for local_recipient_maps not being checked elsewhere in Postfix:

- When an alias map, virtual_alias map, or .forward file, specifies
  a non-existent recipient, then some delivery agent will generate
  a non-delivery notification (NDR). That is more useful than
  rejecting non-existent recipients in the program that expands the
  alias.

- When /usr/sbin/sendmail command-line submission specifies a
  non-existent recipient, then some delivery agent will generate
  an NDR. That is more useful than rejecting non-existent recipients
  in the program that that receives the command-line submission.

> > There are better ways now to integrate Dovecot: I suggest that you
> > use Dovecot LMTP integration instead.
> 
> Cool! Not sure what you mean here though, as I've been using LMTP to 
> deliver mails from Postfix to Dovecot for years. Mind giving some pointers?

You had not mentioned LMTP.

mailbox_transport and _maps were originally used to deliver mail
for UNIX and [1] non-UNIX accounts to a [2] Dovecot command-line
tool. Both [1] and [2] were poor solutions. 

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

[pfx] Re: local_recipient_maps does not apply to local mail submission

[Étienne Miret via Postfix-users]

Hello all,


[…] the queue manager just hands off the message to the relevant transport.

Whether the transport also uses the same table to decide whether or
where to deliver mail is up to the transport.


Obviously. The question is about who checks the local_recipient_maps. 
Looking at the at the architecture overview, this setting would apply 
regardless of the source if it was handled by cleanup(8), qmgr(8), 
trivial-rewrite(8) or local(8).


Reading the man pages for those components and some others, I now see 
that only smptd(8) is handling that setting. Sorry for saying that this 
wasn’t documented!


Also, I believe the whole point of introducing the local_recipient_maps 
setting was to avoid clogging mail queues, both with undeliverable 
incoming emails and the resulting MAILER-DAEMON replies. So it can’t be 
applied after the incoming queue.


Assuming synchronous communication between smtpd(8) and cleanup(8), the 
latter could still be the one responsible for that validation. And this 
would ensure it is always checked. But okay, the observed behavior is 
intentional, and that’s what I wanted to be sure of.


Now, I guess I should submit a patch to the documentation in order to 
explain what wasn’t clear to me at first 🙂. Essentially, reading 
local_recipient_maps again, I see it does mention SMTP, but it’s 
definitely not obvious to me this setting apply only here.



If there is a DISCREPANCY between local_recipient_maps and your
local delivery agent, then you MUST UPDATE your local_recipient_maps
accordingly.


I wasn’t complaining about that discrepancy. I was complaining that the 
local_recipient_maps is only checked for mails submitted through SMTP.



There are better ways now to integrate Dovecot: I suggest that you
use Dovecot LMTP integration instead.


Cool! Not sure what you mean here though, as I’ve been using LMTP to 
deliver mails from Postfix to Dovecot for years. Mind giving some pointers?


Regards,

--
Étienne Miret
https://etienne.miret.io/


OpenPGP_signature
Description: OpenPGP digital signature
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: local_recipient_maps does not apply to local mail submission

[Wietse Venema via Postfix-users]

Wietse Venema via Postfix-users:
> ?tienne Miret via Postfix-users:
> > I found this discrepancy surprising and am suggesting it is removed. In 
> > case others argue it is useful or that removing it will break some 
> > configurations, I am asking it is documented.
> 
> The default local_recipient_maps setting uses the UNIX password
> database abd the Postfix aliases table, because that is what the
> local(8) delivery agent uses.
> 
> If there is a DISCREPANCY between local_recipient_maps and your
> local delivery agent, then you MUST UPDATE your local_recipient_maps
> accordingly.

And I'd like to add that mailbox_transport (and _maps) will deliver
recipient that don't exist in the UNIX passwd fdatabase:

mailbox_transport (default: empty)
   Optional message delivery transport that the  local(8)  delivery  agent
   should use for mailbox delivery to all local recipients, whether or not
   they are found in the UNIX passwd database.

Similar text for mailbox_transport_maps.

These features pre-date local_recipient_maps, address classes, and
related improvements that were introduced in Postfix 2.0, 20 years ago.

There are better ways now to integrate Dovecot: I suggest that you
use Dovecot LMTP integration instead.

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

[pfx] Re: local_recipient_maps does not apply to local mail submission

[Wietse Venema via Postfix-users]

?tienne Miret via Postfix-users:
> I found this discrepancy surprising and am suggesting it is removed. In 
> case others argue it is useful or that removing it will break some 
> configurations, I am asking it is documented.

The default local_recipient_maps setting uses the UNIX password
database abd the Postfix aliases table, because that is what the
local(8) delivery agent uses.

If there is a DISCREPANCY between local_recipient_maps and your
local delivery agent, then you MUST UPDATE your local_recipient_maps
accordingly.

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

[pfx] Re: local_recipient_maps does not apply to local mail submission

[Viktor Dukhovni via Postfix-users]

On Wed, Aug 16, 2023 at 01:51:24AM +0200, Étienne Miret via Postfix-users wrote:

> I found this discrepancy surprising and am suggesting it is removed. In 
> case others argue it is useful or that removing it will break some 
> configurations, I am asking it is documented.

The discrepancy is intentional.  Aside from virtual(5) which is
definitive for the otherwise "fictional" virtual alias domains
(have no real recipients), for the remaining address classes the
queue manager just hands off the message to the relevant transport.

Whether the transport also uses the same table to decide whether or
where to deliver mail is up to the transport.

For the virtual mailbox address class, the built-in virtual(8) delivery
agent does sue virtual_mailbox_maps, but anoother VDA might not.

The relay transport will just deliver mail without regard to
relay_recipient_maps, and local(8) will use a variety of strategies to
try to deliver messages.

The various recipient tables are a moat to fend off hostile invaders,
but play no explicit rôle in delivery of messages that make it inside.

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

[pfx] Re: local_recipient_maps does not apply to local mail submission

[Étienne Miret via Postfix-users]

Hello,


Did you mean command-line submission with /usr/sbin/sendmail?


Yes, as well as internal submission by a Postfix process when using 
aliasing. Sorry, I thought I was explicit (albeit the typo in "command").



This will receive and then bounce the message.


Nope. My tests (using the Debian postfix package, version 
3.7.6-0+deb12u2) show that the mail is delivered to the recipient. I 
mean, in case the recipient actually exists, obviously.


I use mailbox_transport to deliver local mails to Dovecot and because of 
a mis-configuration on my side, Dovecot ended up having a different list 
of users than Postfix. Users (who Dovecot knew about but not Postfix) 
could still receive mails from /usr/sbin/sendmail as well as mails from 
the Internet, to other addresses, aliased to them in /etc/aliases. As 
expected, mails to their addresses submitted on port 25 was rejected.


I found this discrepancy surprising and am suggesting it is removed. In 
case others argue it is useful or that removing it will break some 
configurations, I am asking it is documented.



Did you mean the port 587 or 465 submission services? These will
enforce local_recipient_maps just like the port 25 MTA service.


I didn’t test that case.

Regards,

--
Étienne Miret
https://etienne.miret.io/


OpenPGP_signature
Description: OpenPGP digital signature
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: local_recipient_maps does not apply to local mail submission

[Wietse Venema via Postfix-users]

?tienne Miret via Postfix-users:

Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> Hello,
> 
> After troubleshooting an issue on my Postfix server, I found out that 
> the local_recipient_maps parameter is ignored for locally submitted 
> emails. That is, a recipient not listed there will:
>   - be rejected for mail received from the Internet,
>   - still get mails from the sendmail commnd and
>   - still get mails sent from Internet to some other address that is 
> aliased to them.
> 
> I found this behavior surprising.

Did you mean command-line submission with /usr/sbin/sendmail? This
will receive and then bounce the message. I consider that more
useful than rejecting and losing the message.

Did you mean the port 587 or 465 submission services? These will
enforce local_recipient_maps just like the port 25 MTA service.

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