The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped automatically by the mailing list software.
--- Begin Message ---> Op 17 mei 2021, om 17:47 heeft Rafał Miłecki <zaj...@gmail.com> het volgende > geschreven: > > On 17.05.2021 17:32, Paul Oranje wrote: >> Op 17 mei 2021, om 16:49 heeft Rafał Miłecki <zaj...@gmail.com> het volgende >> geschreven: >>> >>> From: Rafał Miłecki <ra...@milecki.pl> >>> >>> Interfaces need to be assigned to devices. For that purpose a "device" >>> option should be more accurate than "ifname" one. >>> >>> For backward compatibility add a temporary config translation. >>> >>> Config example: >>> >>> config device >>> option name 'lan' >>> option type 'bridge' >>> list ports 'lan1' >>> list ports 'lan2' >>> >>> config interface 'home' >>> option device 'lan' >>> option proto 'static' >> A bit off-topic: the disparency between config section names and an option >> named name is not always clear. > > What do you mean by "not always"? I think it should be consistent: > "interface" UCI section should always use "device" for referencing > "device" UCI section (by its "name"). Indeed. > As for "name" option in the "device" UCI section I thought we could make > it section name instead, but it can't be done due to UCI limitations for > section names: > > [2021-05-14] [16:59:17 CEST] <rmilecki> jow: nbd: quick question - could we > have "config device <foo>" and drop "option name <foo>" ? i see two > advantages: > [2021-05-14] [16:59:21 CEST] <rmilecki> 1. it would not allow duplicated names > [2021-05-14] [16:59:21 CEST] <rmilecki> 2. referencing devices from "config > interface" would be more natural > [2021-05-14] [17:06:32 CEST] <nbd> rmilecki: uci section names have > restrictions on what characters are allowed > [2021-05-14] [17:09:40 CEST] <rmilecki> nbd: right, thanks > [2021-05-14] [17:10:15 CEST] <zorun> ah yes, the babeld uci integration > used to do this (interface name in section name), but we had to drop it Ah, that explains. Your reasoning why using section names would be better stands. Assuming the uci limitation in this case concerns not having dashes in section names: Maybe, as long as uci has these restrictions on section naming and the dash cannot be used therein, one could still use an (allowed) device section name and use that for reference from interface sections and using an device option name to override (the name defaults to the section name), or, change how netifd names devices that it (implicitly) creates. Good luck with your endeavour. That proces itself helps understanding the currently implemented model.
--- End Message ---
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
