Sorry, I forgot to answer the list, that's why that happened. It's not that they don't trust us. We've been sending this mail for 10 years, and we never get flagged as SPAM or unsolicited, since every mail is something the customer actively has requested. We're also a registered sender with outlook.com and Gmail, so we get reports etc about our mailings. We just notice that many, and I mean many, mailservers out there have started throttling all their incoming mail. And it would be nice if Exim could easily play along in that scheme, and skip those domains for a while, but still process the rest of the queue in an orderly manner. Our main client throttle everything themselves! Which actually is hilarious since their employees want our mail as fast as possible, but their own IT department refuses to make special rules for us - even though we are their sole supplier of these emails to them! :)
Maybe it would seem inefficient to look at an email in the queue, and then disregard it based on something, but I see it as inefficient to run 2 or more queues as well, and have one of the queues trying to squeeze in mail in the "delivery"-queue (as others have suggested). With the now suggested prearranged queue that would not need to happen, which is good. As it is now, a queue-runner opens a mail, tries to deliver it, gets a "back off!"-message from their server, opens another mail (to the same domain), gets the same "back off!"-message, opens another....etc... hardly efficient. But sure, naming different queues, spooling to them based on domain, and manually delivering from some of them is probably the clean "Exim-solution". I just have to figure out how to make Exim skip those queues when starting automatic queue-runners. It would be nice to have Exim automatically "back off" when it sees a lot of errors from a domain though. That way we can handle this dynamically, instead of having to manually identify all the domains who need throttling. I thought I had configured this some years ago, but it must have been for some other product. Again, sorry for mailing you two times. Hope it doesn't happen again. ons 18 okt. 2017 kl. 21:54 skrev Jeremy Harris <[email protected]>: > I don't need duplicate individual mail to those on the ML. > Please don't. > > On 18/10/17 17:51, Charlie Elgholm wrote: > > 2017-10-18 16:41 GMT+02:00 Jeremy Harris <[email protected]>: > >> On 18/10/17 11:42, Charlie Elgholm wrote: > >>> Is there some way to have Exim rate-limit the queue runners, so they > only > >>> process - let's say 10 messages per minute - for a domain (like > >>> outlook.com/live.com) - _regardless_ of how the message was put in the > >>> queue. > >> > >> No. The queue-runners just don't do that. > >> > >> You'd need to DIY; something like "take the first 10 id's from the > >> spooldir, once a minute, and run 'exim -M'". Possibly using > >> a named-spool for each class of such mails you wanted to keep separate. > > > > Ok, that's sad. > > > > The infrastructure for it all is already on the code base: > > 1. There's something returning true/false if a mail should be > > processed in the queue (since frozen-messages is skipped). > > 2. There's a rate-limit command already, highly configurable. > > 3. There's a "rule-system" (executed for the ACLs). > > You could certainly have a redirect router first in the > chain rigged to expand ::defer:: for anything after the > first few items. With current released Exim. > > But you'd still be pointlessly doing this for all of the > spool that you weren't going to deliver. Hardly efficient. > > > (And if the big providers don't trust you, it's likely > because you have not built up a good reputation with them yet) > -- > Jeremy > > -- > ## List details at https://lists.exim.org/mailman/listinfo/exim-users > ## Exim details at http://www.exim.org/ > ## Please use the Wiki with this list - http://wiki.exim.org/ > -- Regards Charlie Elgholm Brightly AB -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
