January 26, 2024 10:22 PM, [email protected] wrote:
> January 25, 2024 9:23 PM, "Chris Brannon" <[email protected]> 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
case.
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 [email protected] as user _mlmmj
#
action "vusers" deliver to maildir user _mlmmj
In this case, it is assumed that there's no local user "misc" backing
[email protected] 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 :-/
