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 ---Hi, > You're already using a foreign event loop / IO notification mechanism, you > already have means to determine socket read readiness. Invoking a library > function that does it's own polling internally with arbitrary, uncontrollable > timeouts does not seem like a good design. Maybe, I don't get something right, but it seems like in my patch It does not do any internal polling when calling ubus_handle_events. It will call ubus_handle_data function, which is the command block ctx->sock.cb that will be executed with ctx->cancel_poll set to false. The ctx->cancel_poll could be redundant in the loop, because I don't see any way its state could be changed during the loop flow. > It would be better to implement a function that simply keeps calling > `get_next_msg(ctx, &recv_fd)` and `ubus_process_msg(ctx, &ctx->msgbuf, > recv_fd);` until `get_next_msg()` yields false. ubus_handle_data seems to do exactly what you've described, so is there any other reason to implement separate function? ________________________________________ From: openwrt-devel <[email protected]> on behalf of Jo-Philipp Wich <[email protected]> Sent: Monday, February 13, 2023 3:12 PM To: [email protected] Subject: Re: [PATCH] ubus: added ubus_handle_events function that "guaranties" execution of all polled events [EXTERNAL]-Real sender is: openwrt-devel-bounces+taras.i.boichuk-ext=sagemcom....@lists.openwrt.org ---------------------------------------------------------------------- Hi, > In case of previous setup or calling flow ctx->cancel_poll is set to true > function ubus_handle_event may process ONLY ONE request, though the comment > says it processes events: > > /* call this for read events on ctx->sock.fd when not using uloop */ static > inline void ubus_handle_event(struct ubus_context *ctx) { > ctx->sock.cb(&ctx->sock, ULOOP_READ); } > > In case if I would manually poll the ubus fd and do not use uloop to poll > it and after that it may process ONE event and the rest will be processed > on the next loop cycle. I would like to have a function that guarantees > that every request will be processed in a single call to > ubus_haubus_handle_eventndle_event. You're already using a foreign event loop / IO notification mechanism, you already have means to determine socket read readiness. Invoking a library function that does it's own polling internally with arbitrary, uncontrollable timeouts does not seem like a good design. It would be better to implement a function that simply keeps calling `get_next_msg(ctx, &recv_fd)` and `ubus_process_msg(ctx, &ctx->msgbuf, recv_fd);` until `get_next_msg()` yields false. ~ Jo ______________________________________________________________________ Ce courriel et les documents qui lui sont joints sont, sauf mention contraire, présumés de nature confidentielle et destinées à l'usage exclusif du ou des destinataire(s) mentionné(s). Si vous n'êtes pas le ou les destinataire(s), vous êtes informé(e) que toute divulgation, reproduction, distribution, toute autre diffusion ou utilisation de cette communication ou de tout ou partie de ces informations est strictement interdite, sauf accord préalable de l’expéditeur. Si ce message vous a été transmis par erreur, merci d’immédiatement en informer l'expéditeur et supprimer de votre système informatique ce courriel ainsi que tous les documents qui y sont attachés. En vous remerciant de votre coopération. This email and any attached documents are, unless otherwise stated, presumed to be confidential and intended for the exclusive use of the recipient(s) mentioned. If you are not the recipient(s), you are informed that any disclosure, reproduction, distribution, any other dissemination or use of this communication or all or part of this information is strictly prohibited, unless agreed beforehand by the sender. If you have received this e-mail in error, please immediately advise the sender and delete this e-mail and all the attached documents from your computer system. Thanking you for your cooperation.
--- End Message ---
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
