Hi Ken, I agree that it is a problem. I do think this could be done at connection time only. Of of the tricky parts is that all mail servers I know have trouble with throttling. They can throttle on a (set of) recipient domain(s), but not on a cluster of MXs from e.g. Microsoft. E.g. they put hotmail, outlook, msn in one queue but forget to put email from businesses that use Office365 in the same queue. In order to fix that more easily, the mail server should disclose an identifyer where the volume should be counted under. In that way a server could know when a new connection/domain is part of that throttling (and shut that connection down if necessary).
e.g. 250-THROTTLING-IDENTIFIER hotmail-scoijwesoifjwhps [QUIT here if you realize it would violate the throttling quota] 250-THROTTLING-CONNECTIONS 10 250-THROTTLING-EMAILS-CONNECTION 20 250-THROTTLING-RATE-MINUTE 20 250-THROTTLING-RATE-HOUR 200 250-THROTTLING-RATE-DAY 500 250-THROTTLING-DATASIZE-CONNECTION 100MB or 250-THROTTLING-IDENTIFIER hotmail-scoijwesoifjwhps 250-THROTTLING-GRAYLISTING-MINUTE 120 It would then be up to the MTA to group all these domains under that identifier and abide to the throttling requirements. One thing is that these throttling parameters must be adjustable in the same connection (so they can react to emails you send). Yours, David On 13 November 2017 at 20:41, Ken O'Driscoll <k...@wemonitoremail.com> wrote: > On Mon, 2017-11-13 at 09:58 -0800, Steve Atkins wrote: > > (If this proposal were coming out of a group of major ISPs or a few of > > the larger inbound mail appliance or service providers as "this is > > something we want to do" I'd consider it differently than it coming from > > the high volume email deployer side of things. There's a long history of > > bulk mail senders going "just tell us exactly what we need to do so > > you'll deliver our email, and we'll do it!" and it's not something that > > ever really leads anywhere.) > > I understand this sentiment but I believe these days the only reason that > most of them want to know "what the rules are" is because they want to > comply but it's often not evident how. > > The quality (and existence) of postmaster portals and knowledge bases > varies greatly. The informative value of SMTP error messages varies > greatly. The ability to communicate with a postmaster varies greatly. > > You can't really blame them (particularly the smaller ones) for sometimes > being confused about what's needed to get their transactional or opt-in > email into inboxes. > > Ken. > > -- > Ken O'Driscoll / We Monitor Email > t: +353 1 254 9400 | w: www.wemonitoremail.com > > Need to understand deliverability? Now there's a book: > www.wemonitoremail.com/book > > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > -- -- My opinion is mine.
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
