January 26, 2024 10:22 PM, gil...@poolp.org wrote:

> January 25, 2024 9:23 PM, "Chris Brannon" <ch...@the-brannons.com> wrote:
>> Well, maybe the thing I thought would be very stupid isn't so stupid
>> after all. In doas.conf:
>> permit nopass smtpd as mlmmj cmd /usr/bin/mlmmj-receive
>> permit nopass smtpd as inboxen cmd /usr/bin/public-inbox-mda
>> And then in the ~/.forward file for those two users,
>> "| /usr/bin/doas -u USERNAME COMMAND"
> I haven't followed the discussion that led to this change upstream,
> but I think the change that happened in OpenBSD which leads to this
> situation is not correct :-/

Sorry, I should elaborate.

Upon delivery, a process is forked and drops its privileges to that of the 
end-user, allowing both
forward file parsing and delivery to happen without smtpd permissions. The only 
exception is mbox,
which requires forcing delivery user to root, and it is handled as a special 

In all other cases, either you deliver as the end-user, or if you want a 
specific user you have to
force it with the "user" keyword, as is done for virtual users setups:

    # delivers misc@opensmtpd.org as user _mlmmj
    action "vusers" deliver to maildir user _mlmmj

In this case, it is assumed that there's no local user "misc" backing 
m...@opensmtd.org so we tell
smtpd to use _mlmmj to represent it, kind of as a system account aliasing, and 
so the forward file
that's used is that of _mlmmj.

Now my understanding is that LMTP deliveries need to be done as the _smtpd user 
for some reason...
but not because the end-user doesn't exist, so the .forward parsing should be 
done as the user and
the delivery as _smtpd, otherwise the .forward parsing happens with the wrong 
user, as is the case
here :-/

Reply via email to