Re: What are xxxterm users using today?

2020-02-01 Thread Gonzalo Rodriguez
https://marc.info/?l=openbsd-ports=148587723122194=2

— gonzalo

> On 31. Jan 2020, at 18:46, Allan Streib  wrote:
> 
> I used to use xxxterm, then xombrero, and really liked the minimal
> approach and keyboard driven navigation.
> 
> Any other former users of this browser, what are you using today to
> achieve any of this functionality in your browser?
> 
> Allan
> 


Re: Stuck on remote rsync with BackupPC and openrsync

2020-02-01 Thread Stuart Henderson
On 2020-02-01, Fabian  wrote:
> Hi,
>
> I have been trying to get BackupPC 3.3.2 running on a Debian 10/Buster
> server to back up my OpenBSD 6.6 router. It works fine with the GNU
> rsync port on the OpenBSD box but when I try to use the native
> openrsync instead, it just seems to not get started properly and hangs.

The solution is obvious here. It's early days for openrsync and it is
far from being fully compatible with rsync.




Re: updating calibre port

2020-02-01 Thread Stuart Henderson
On 2020-02-01, aisha  wrote:
> Hi all, 
>
>   I had a request for updating the calibre port to the newer versions as
> I am running a small calibre library server. 
>
> Thanks a lot!
>

It's not likely to happen anytime soon. Updating to new calibre,
including all the required dependencies (which includes updating Qt and
py-qt5 and porting qtwebengine) is probably several weeks worth of
full-time work for an experienced porter.




updating calibre port

2020-02-01 Thread aisha
Hi all, 


 I had a request for updating the calibre port to the newer versions as
I am running a small calibre library server. 


Thanks a lot!

--
Aisha
blog.aisha.cc


Stuck on remote rsync with BackupPC and openrsync

2020-02-01 Thread Fabian
Hi,

I have been trying to get BackupPC 3.3.2 running on a Debian 10/Buster
server to back up my OpenBSD 6.6 router. It works fine with the GNU
rsync port on the OpenBSD box but when I try to use the native
openrsync instead, it just seems to not get started properly and hangs.

On the Debian side, it looks like this until I kill it after a few
hours:


$ /usr/bin/perl /usr/share/backuppc/bin/BackupPC_dump -v milan 
cmdSystemOrEval: about to system /bin/ping -c 1 172.16.10.1
cmdSystemOrEval: finished: got output PING 172.16.10.1 (172.16.10.1)
56(84) bytes of data. 64 bytes from 172.16.10.1: icmp_seq=1 ttl=255
time=0.173 ms

--- 172.16.10.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.173/0.173/0.173/0.000 ms

cmdSystemOrEval: about to system /bin/ping -c 1 172.16.10.1
cmdSystemOrEval: finished: got output PING 172.16.10.1 (172.16.10.1)
56(84) bytes of data. 64 bytes from 172.16.10.1: icmp_seq=1 ttl=255
time=0.094 ms

--- 172.16.10.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.094/0.094/0.094/0.000 ms

CheckHostAlive: returning 0.094
full backup started for directory / (baseline backup #135)
started full dump, share=/
Running: /usr/bin/ssh -q -x -o
UserKnownHostsFile=/etc/backuppc/ssh/known_hosts
-i /etc/backuppc/ssh/id_ed25519 -l backup 172.16.10.1
doas /usr/local/bin/rsync --server --sender --numeric-ids --perms
--owner --group -D --links --times --recursive -x --ignore-times . /
Xfer PIDs are now 10093 
xferPids 10093 
Got remote protocol 27
Negotiated protocol version 27



milan/172.16.10.1 is the OpenBSD box to be backed up. BackupPC connects
via ssh and starts openrsync in server mode. /usr/local/bin/rsync is a
wrapper script that removes the "--ignore-times" parameter before it
invokes openrsync because openrsync does not understand that parameter
and BackupPC insists on adding that parameter.

On the OpenBSD box I see the following processes until I kill them
after a few hours:

USER   PID  PPID  PGID SESS JOBC STAT   TT   TIME
COMMAND

backup   22274 23311 23311 fd80731388500 I  ??0:00.12
sshd: backup@notty (sshd)

backup   98017 22274 98017 fd80731388c00 Ip ??0:00.05
sh -c doas /usr/local/bin/rsync --server --sender --numeric-ids --perms
--owner --group -D --links --times --recursive -x --ignore-times . /

root 95559 98017 98017 fd80731388c00 Ip ??0:00.01 
/bin/ksh /usr/local/bin/rsync --server --sender --numeric-ids
--perms --owner --group -D --links --times --recursive -x
--ignore-times . / 

root 15271 95559 98017 fd80731388c00 IpU??0:00.28
/usr/bin/openrsync --server --sender --numeric-ids --perms
--owner --group -D --links --times --recursive -x . /



A ktrace -dig 98017 just gives me an empty trace file (it starts to
have something when I kill the processes but that obviously does not
tell me what went wrong initially).

Any suggestions what might go wrong or how to debug this further?

Fabian



Re: Resource temporarily unavailable: have to recompile?

2020-02-01 Thread Strahil Nikolov
On February 1, 2020 12:27:40 AM GMT+02:00, "Luke A. Call" 
 wrote:
>Cancel the cancellation.
>I am still seeing this problem, even after logging out/in and ulimit -u
>shows 712.   Running "ps -U myusername|less" yields about 180 lines and
>the system becomes unable to start even another xterm, or in tmux on a
>console, unable to start another shell window (in both cases: "Resource
>temporarily unavailable").
>
>On 01-31 13:20, Luke A. Call wrote:
>> Hi misc.  
>> 
>> Am I running into a limit that will require recompiling the kernel
>> (or changing my work style I suppose)?  Which man pages should I read
>> next, or should I be thinking about this differently?
>> 
>> I am getting "Resource temporarily unavailable" in
>> /var/log/authlog when I try to open too many "ssh [-X]
>user@localhost"
>> connections, or even "fork: retry: Resource temporarily unavailable"
>when
>> running "$ cat > /tmp/somefile".  
>> 
>> In "man 3 __tfork" I see:
>> [EAGAIN]Resource temporarily unavailable.  The system-imposed
>>  limit on the total number of threads under execution
>>  would be exceeded.  This limit is configuration-
>>  dependent.
>> 
>> [EAGAIN]Resource temporarily unavailable.  The system-imposed
>>  limit MAXUPRC on the total number of threads under
>>  execution by a single user would be exceeded.  MAXUPRC
>>  is currently defined in  as CHILD_MAX,
>>  which is currently defined as 80 in .
>> 
>> (If multiple users could simultaneously run X, I might not ssh as
>much;
>> suggestions welcome there also, if you are in the mood.)
>> 
>> 
>> More details, not sure if needed:
>> 
>> When I open a large # of xterms which make ssh -X connections on
>> my laptop with obsd 6.5 (planning to upgrade, haven't quite yet),
>they at 
>> first pause saying
>>   -bash: fork: retry: Resource temporarily unavailable
>> ...then start failing with 
>>   shell request failed on channel 0
>> ...and in /var/log/authlog I see:
>>   sshd[52954]: error: do_exec_pty: fork: Resource temporarily
>unavailable
>> 
>> Also, until recently I would get error messages in ~/.xsession-errors
>like:
>>   xterm: Error 32, errno 6: Device not configured   Reason: 
>>   get_pty: not enough ptys
>> ...but, after creating more ptys by running (as root)
>>   cd /dev; sh MAKEDEV pty1  #then, um, with pty2, pty3, 4, and 5
>> 
>> ...I don't seem to get the "not enough ptys" anymore, and can open
>> all the xters I like, but I get the
>> above "xterm: Error 32, errno 6: Device not configured   Reason:
>> get_pty: not enough ptys" from authlog, and the "shell request failed
>> on channel 0" from the ssh client, all even when I do this not under
>X.  
>> 
>> It's like I can't get beyond about 20-23 "ssh user@localhost"
>connections
>> (depending on how they are counted).
>> 
>> I have expanded limits in /etc/login.conf and kern.maxfiles=3500 now,
>in
>> sysctl.conf, but that is just poking in the dark.
>> 
>> What am I missing? Thanks!
>> -Luke
>> 
>> dmesg:
>> ached
>> uhidev4 detached
>> uhid5 detached
>> uhid6 detached
>> uhid7 detached
>> uhid8 detached
>> uhidev5 detached
>> uhidev3 at uhub5 port 3 configuration 1 interface 0 "Logitech USB
>Receiver" rev 2.00/12.07 addr 3
>> uhidev3: iclass 3/1
>> ukbd1 at uhidev3: 8 variable keys, 6 key codes
>> wskbd2 at ukbd1 mux 1
>> wskbd2: connecting to wsdisplay0
>> uhidev4 at uhub5 port 3 configuration 1 interface 1 "Logitech USB
>Receiver" rev 2.00/12.07 addr 3
>> uhidev4: iclass 3/1, 8 report ids
>> ums1 at uhidev4 reportid 2: 16 buttons, Z and W dir
>> wsmouse1 at ums1 mux 0
>> uhid2 at uhidev4 reportid 3: input=4, output=0, feature=0
>> uhid3 at uhidev4 reportid 4: input=1, output=0, feature=0
>> uhid4 at uhidev4 reportid 8: input=1, output=0, feature=0
>> uhidev5 at uhub5 port 3 configuration 1 interface 2 "Logitech USB
>Receiver" rev 2.00/12.07 addr 3
>> uhidev5: iclass 3/0, 33 report ids
>> uhid5 at uhidev5 reportid 16: input=6, output=6, feature=0
>> uhid6 at uhidev5 reportid 17: input=19, output=19, feature=0
>> uhid7 at uhidev5 reportid 32: input=14, output=14, feature=0
>> uhid8 at uhidev5 reportid 33: input=31, output=31, feature=0
>> uhidev6 at uhub0 port 4 configuration 1 interface 0 "vendor 0x
>USB OPTICAL MOUSE" rev 1.10/1.00 addr 3
>> uhidev6: iclass 3/1, 1 report id
>> ums2 at uhidev6 reportid 1: 3 buttons, Z dir
>> wsmouse2 at ums2 mux 0
>> wsmouse2 detached
>> ums2 detached
>> uhidev6 detached
>> uhidev6 at uhub0 port 4 configuration 1 interface 0 "vendor 0x
>USB OPTICAL MOUSE" rev 1.10/1.00 addr 3
>> uhidev6: iclass 3/1, 1 report id
>> ums2 at uhidev6 reportid 1: 3 buttons, Z dir
>> wsmouse2 at ums2 mux 0
>> wsmouse2 detached
>> ums2 detached
>> uhidev6 detached
>> uhidev6 at uhub0 port 4 configuration 1 interface 0 "vendor 0x
>USB OPTICAL MOUSE" rev 1.10/1.00 addr 3
>> uhidev6: iclass 3/1, 1 report id
>> ums2 at uhidev6 reportid 1: 3 buttons, Z dir
>> wsmouse2 at ums2 mux 0
>> 

Re: Recovering corrupted encrypted partition

2020-02-01 Thread Strahil Nikolov
On February 1, 2020 2:20:12 AM GMT+02:00, Jan Stary  wrote:
>On Jan 31 18:25:45, int1...@airmail.cc wrote:
>> Hello,
>> Recently my 6.6-stable machine lost power while on, which aparently
>> corrupted a softraid crypto partition (not a boot partition) that was
>> mounted. Trying to decrypt it with the same bioctl command i usually
>> use fails with the error:
>> softraid0: invalid metadata format
>
>What bioctl command is that?
>
>> After searching all over the mailing list archives, I couldn't find a
>> solution that didn't destroy data. Some people suggested zeroing the
>> first megabyte and reconfiguring the disklabel, but I'm not sure if
>that
>> would overwrite my existing data.
>
>Recreate the softraid crypto partition
>and restore the data from backups.

No matter  you try - first  step is to create  a disk clone  via 'dd' and use  
that for your tries to recover -> even if the clone is dead  - it's just a copy.
Then you will have the freedom to test different stuff. 
The first question that comes to my mind is where bioctl stores data about the 
'crypto' (what offset) , so you can use a backup one in your command.
Yet, I've never done crypto on openBSD - just LUKS on Linux.

Best Regards,
Strahil Nikolov



Re: How did it happen?

2020-02-01 Thread gilles
February 1, 2020 2:01 PM, "Uwe Werler"  wrote:

> Thank you very much Gilles for the insights.
> 
> It's not really your fault because it's how our brain works. If we want to 
> get things working we
> are concentrating to get them working - not how to break them. It's amazing 
> that the code worked
> like "intended" - that means you are a very good dev. Logical fallacies hit 
> us every day - we are
> human.
> 

it is my fault but that's the way it is, error is human.

if more people wanted to contribute we could limit risks for logic mistakes,
but as of now there's very few people interested in diving into smtpd.
> I would give +1 to not to deliver mails directly to root.
> 

working on it


Re: How did it happen?

2020-02-01 Thread Uwe Werler



Am 31. Januar 2020 18:48:51 GMT+00:00 schrieb gil...@poolp.org:
>January 30, 2020 4:44 PM, gil...@poolp.org wrote:
>
>> It depends on your configuration, not all setups are vulnerable.
>> 
>> I think I recall your name from the comments on my tutorial and this
>is a
>> setup that would not be vulnerable for example. The bug still exists,
>but
>> it can't be used to exploit the same code path.
>> 
>> You should update, this is not something you want to rely on.
>> 
>> I'm writing a _very_ detailed post-mortem which will go into the
>details,
>> I just want to give it a few days to make sure it is as informative
>as it
>> should.
>> 
>
>
>As promised, I have written a (too much ?) detailed write-up about the
>recent event:
>
>https://poolp.org/posts/2020-01-30/opensmtpd-advisory-dissected/
>
>Hope it clarifies what happened and plans for the future.
>
>Gilles

Thank you very much Gilles for the insights.

It's not really your fault because it's how our brain works. If we want to get 
things working we are concentrating to get them working - not how to break 
them. It's amazing that the code worked like "intended" - that means you are a 
very good dev. Logical fallacies hit us every day - we are human. 

I would give +1 to not to deliver mails directly to root.


Re: .forward MDA fails, "mail.local: may only be run by the superuser"

2020-02-01 Thread Andreas Kusalananda Kähäri
On Sat, Feb 01, 2020 at 09:29:16AM +, gil...@poolp.org wrote:
> February 1, 2020 9:11 AM, "Andreas Kusalananda Kähäri" 
>  wrote:
> 
> > Hi,
> > 
> > With the latest snapshot on amd64 (6.6 GENERIC.MP#627), using a "|"-line
> > in one's ~/.forward makes delivery of mail fail with
> > 
> > Feb 1 08:53:53 pooh smtpd[72575]: d9abac6b3d904e13 smtp connected 
> > address=local
> > host=pooh.prefix.duckdns.org
> > Feb 1 08:53:54 pooh smtpd[72575]: d9abac6b3d904e13 smtp message 
> > msgid=8698cb82 size=1824 nrcpt=1
> > proto=ESMTP
> > Feb 1 08:53:54 pooh smtpd[72575]: d9abac6b3d904e13 smtp envelope 
> > evpid=8698cb8264606654 from=<>
> > to=
> > Feb 1 08:53:54 pooh smtpd[72575]: d9abac6b3d904e13 smtp disconnected 
> > reason=quit
> > Feb 1 08:53:54 pooh mail.local: may only be run by the superuser
> > Feb 1 08:53:54 pooh smtpd[72575]: d9abac6d77a45212 mda delivery 
> > evpid=8698cb8264606654 from=<>
> > to= rcpt= 
> > user=kk delay=0s result=PermFail
> > stat=Error ("mail.local: may only be run by the superuser")
> > Feb 1 08:53:54 pooh smtpd[19621]: warn: queue: no return path!
> > 
> > The mail is then lost.
> > 
> 
> It is rejected at session time because there's no other way to handle
> this case:
> 
> your user "kk" tries to execute "mail.local" from ~/.forward file but
> mail.local requires privileges and smtpd doesn't allow running things
> with privileges from ~/.forward.
> 
> it can't be handled as a temporary failure either.
> 
> 
> > I have
> > 
> > pooh % cat .forward
> > |/usr/local/bin/fdm -a stdin fetch
> > 
> > where "stdin" is a simple mail "account" in fdm(1) that takes messages
> > from standard input, filters it, and sorts it into the correct Maildir
> > inbox. For me, this only affects messages originating from the local
> > system (e.g. crontab output etc., but also messages for root as my root
> > user is aliased to my ordinary user through /etc/mail/aliases).
> > 
> 
> I'm not sure that's what's happening, maildir can't possibly use mail.local,
> and the error message is explicit, mail.local is being executed somehow.
> 
> 
> > I understand that this may well be by design rather than a bug. How
> > may one use a personal MDA from ~/.forward nowadays, or is that option
> > completely unsupported from now on?
> > 
> 
> That shouldn't be the case as I  use ~/.forward with fdm in it

Are you using the latest snapshot?  This started happening after
updating today, between the snapshots that advertise MP kernel build
number #626 and #627 on amd64.

> 
> It would help if you shared your config

The _only_ thing related to the "stdin" account in my ~/.fdm.conf is a
single line saying

account "stdin" disabled stdin

Mail is otherwise filtered and sorted _exactly_ like the messages that I
fetch from remote IMAPS accounts in the same configuration.

The smtpd configuration for local-to-local delivery looks like

action "local" mbox alias 
match from local for local action "local"

I did not send this to the bugs list because I wasn't sure it was a base
system bug, a bug in fdm, or the intended behaviour after the various
recent updates to smtpd, or just something that I'm doing wrong.  If it
is indeed a bug, then I'll write a proper report to the bugs list.

Regards,

-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden

.



Re: Support for ath10k QCA988x devices

2020-02-01 Thread Stefan Sperling
On Tue, Jan 28, 2020 at 03:33:00PM -0800, Alexander Merritt wrote:
> On 2017-04-12 Stefan Sperling wrote
> > ath10k devices are not supported. They need a new driver because Atheros
> > has changed the driver<->hardware interface with this generation of devices.
> 
> Is there any update? A brief look in the source code and manual did not show 
> anything.

No. I have been too busy with Intel drivers instead.
Currently I am working on a new driver based on iwm(4) for newer
Intel hardware (ax200).
I don't want to work on more than one driver at a time.

It would be great if the industry stopped putting out new chipsets
for a few years so we can manage to catch up.

> What effort is required to implement a new driver, as Stefan mentions? Port 
> something from another BSD? From Linux? Start from scratch?

In this case it can be ported from Linux. However, that is a lot more
involved than mere copy/paste; it essentially requires going through
the entire driver and port the neccessary parts of the code incrementally.
Check Patrick's talk from EuroBSDcon 2019 about bwfm; this is a similar
situation.

> My motivation is to build a wireless router supporting 802.11ac (with OpenBSD 
> if possible). Compex WLE600VX and WLE900VX support 867Mbps and 1300Mbps, 
> respectively, according to their data sheets.
> 
> I am not bound to this chipset, if there are alternatives which do work.

The 11n support net80211 and iwm/iwn needs to be completed before
working on 11ac makes any sense. What is lacking in particular on
the way towards 11ac is 40 MHz channel support. Also, Tx aggregation
support needs to be added to iwm(4), as was done in iwn(4) some time ago.



Re: .forward MDA fails, "mail.local: may only be run by the superuser"

2020-02-01 Thread Stuart Henderson
misc@ is really not the right place for bug reports. Use bugs@, or opensmtpd
has its own lists: https://opensmtpd.org/list.html

On 2020-02-01, Andreas Kusalananda Kähäri  wrote:
> Hi,
>
> With the latest snapshot on amd64 (6.6 GENERIC.MP#627), using a "|"-line
> in one's ~/.forward makes delivery of mail fail with
>
> Feb  1 08:53:53 pooh smtpd[72575]: d9abac6b3d904e13 smtp connected 
> address=local host=pooh.prefix.duckdns.org
> Feb  1 08:53:54 pooh smtpd[72575]: d9abac6b3d904e13 smtp message 
> msgid=8698cb82 size=1824 nrcpt=1 proto=ESMTP
> Feb  1 08:53:54 pooh smtpd[72575]: d9abac6b3d904e13 smtp envelope 
> evpid=8698cb8264606654 from=<> to=
> Feb  1 08:53:54 pooh smtpd[72575]: d9abac6b3d904e13 smtp disconnected 
> reason=quit
> Feb  1 08:53:54 pooh mail.local: may only be run by the superuser
> Feb  1 08:53:54 pooh smtpd[72575]: d9abac6d77a45212 mda delivery 
> evpid=8698cb8264606654 from=<> to= 
> rcpt= user=kk delay=0s result=PermFail 
> stat=Error ("mail.local: may only be run by the superuser")
> Feb  1 08:53:54 pooh smtpd[19621]: warn: queue: no return path!
>
> The mail is then lost.
>
> I have
>
> pooh % cat .forward
>|/usr/local/bin/fdm -a stdin fetch
>
> where "stdin" is a simple mail "account" in fdm(1) that takes messages
> from standard input, filters it, and sorts it into the correct Maildir
> inbox.  For me, this only affects messages originating from the local
> system (e.g. crontab output etc., but also messages for root as my root
> user is aliased to my ordinary user through /etc/mail/aliases).
>
> I understand that this may well be by design rather than a bug.  How
> may one use a personal MDA from ~/.forward nowadays, or is that option
> completely unsupported from now on?
>
> Regards,
>



Re: .forward MDA fails, "mail.local: may only be run by the superuser"

2020-02-01 Thread gilles
February 1, 2020 9:11 AM, "Andreas Kusalananda Kähäri"  
wrote:

> Hi,
> 
> With the latest snapshot on amd64 (6.6 GENERIC.MP#627), using a "|"-line
> in one's ~/.forward makes delivery of mail fail with
> 
> Feb 1 08:53:53 pooh smtpd[72575]: d9abac6b3d904e13 smtp connected 
> address=local
> host=pooh.prefix.duckdns.org
> Feb 1 08:53:54 pooh smtpd[72575]: d9abac6b3d904e13 smtp message 
> msgid=8698cb82 size=1824 nrcpt=1
> proto=ESMTP
> Feb 1 08:53:54 pooh smtpd[72575]: d9abac6b3d904e13 smtp envelope 
> evpid=8698cb8264606654 from=<>
> to=
> Feb 1 08:53:54 pooh smtpd[72575]: d9abac6b3d904e13 smtp disconnected 
> reason=quit
> Feb 1 08:53:54 pooh mail.local: may only be run by the superuser
> Feb 1 08:53:54 pooh smtpd[72575]: d9abac6d77a45212 mda delivery 
> evpid=8698cb8264606654 from=<>
> to= rcpt= user=kk 
> delay=0s result=PermFail
> stat=Error ("mail.local: may only be run by the superuser")
> Feb 1 08:53:54 pooh smtpd[19621]: warn: queue: no return path!
> 
> The mail is then lost.
> 

It is rejected at session time because there's no other way to handle
this case:

your user "kk" tries to execute "mail.local" from ~/.forward file but
mail.local requires privileges and smtpd doesn't allow running things
with privileges from ~/.forward.

it can't be handled as a temporary failure either.


> I have
> 
> pooh % cat .forward
> |/usr/local/bin/fdm -a stdin fetch
> 
> where "stdin" is a simple mail "account" in fdm(1) that takes messages
> from standard input, filters it, and sorts it into the correct Maildir
> inbox. For me, this only affects messages originating from the local
> system (e.g. crontab output etc., but also messages for root as my root
> user is aliased to my ordinary user through /etc/mail/aliases).
> 

I'm not sure that's what's happening, maildir can't possibly use mail.local,
and the error message is explicit, mail.local is being executed somehow.


> I understand that this may well be by design rather than a bug. How
> may one use a personal MDA from ~/.forward nowadays, or is that option
> completely unsupported from now on?
> 

That shouldn't be the case as I  use ~/.forward with fdm in it

It would help if you shared your config



.forward MDA fails, "mail.local: may only be run by the superuser"

2020-02-01 Thread Andreas Kusalananda Kähäri
Hi,

With the latest snapshot on amd64 (6.6 GENERIC.MP#627), using a "|"-line
in one's ~/.forward makes delivery of mail fail with

Feb  1 08:53:53 pooh smtpd[72575]: d9abac6b3d904e13 smtp connected 
address=local host=pooh.prefix.duckdns.org
Feb  1 08:53:54 pooh smtpd[72575]: d9abac6b3d904e13 smtp message msgid=8698cb82 
size=1824 nrcpt=1 proto=ESMTP
Feb  1 08:53:54 pooh smtpd[72575]: d9abac6b3d904e13 smtp envelope 
evpid=8698cb8264606654 from=<> to=
Feb  1 08:53:54 pooh smtpd[72575]: d9abac6b3d904e13 smtp disconnected 
reason=quit
Feb  1 08:53:54 pooh mail.local: may only be run by the superuser
Feb  1 08:53:54 pooh smtpd[72575]: d9abac6d77a45212 mda delivery 
evpid=8698cb8264606654 from=<> to= 
rcpt= user=kk delay=0s result=PermFail stat=Error 
("mail.local: may only be run by the superuser")
Feb  1 08:53:54 pooh smtpd[19621]: warn: queue: no return path!

The mail is then lost.

I have

pooh % cat .forward
|/usr/local/bin/fdm -a stdin fetch

where "stdin" is a simple mail "account" in fdm(1) that takes messages
from standard input, filters it, and sorts it into the correct Maildir
inbox.  For me, this only affects messages originating from the local
system (e.g. crontab output etc., but also messages for root as my root
user is aliased to my ordinary user through /etc/mail/aliases).

I understand that this may well be by design rather than a bug.  How
may one use a personal MDA from ~/.forward nowadays, or is that option
completely unsupported from now on?

Regards,

-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden

.