I agree with Ken that the need for guidelines is well intended. Many legitimate senders want to avoid pushing too hard and wasting resources on both ends. But I think exchanging specific limits between receiver and sender via a new mechanism is infeasible, and may not even be needed.
Why not start with bringing some clarity to SMTP replies and sender guidelines? Enhanced status codes or clear messages can tell the sender to (temporarily) stop sending from an IP or domain. Professional MTAs can already handle this using adaptive delivery settings. I know that some are seeking the exact message rate that they are allowed to send, but reputation and throttling is not exact science. I don't see what's wrong with sending a burst of messages, stopping at the first reputation error, and resuming after some predefined delay. Maarten Oelering Postmastery > On 14 Nov 2017, at 10:05, David Hofstee <opentext.dhofs...@gmail.com> wrote: > > 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 > <mailto: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 <tel:%2B353%201%20254%209400> | w: www.wemonitoremail.com > <http://www.wemonitoremail.com/> > > Need to understand deliverability? Now there's a book: > www.wemonitoremail.com/book <http://www.wemonitoremail.com/book> > > > _______________________________________________ > mailop mailing list > mailop@mailop.org <mailto:mailop@mailop.org> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > <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
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
