> On Sep 5, 2019, at 4:31 PM, Brotman, Alexander via mailop <mailop@mailop.org>
> wrote:
>
> One of the interesting things I’ve learned while interacting with ESPs is
> that some of them will artificially restrict the number of messages per
> session, in lieu of opening more sessions. Some of them have told me the
> values are in the low single digits. I’ve kind of wondered the rationale for
> that might be. Is it the idea that you want to get your messages through as
> quickly as possible?
Limiting the number of messages sent over a connection is more something for
the benefit of the recipient MX, and it's something enforced by them.
While just opening one connection (per MX, perhaps) and sending all the mail
you have for that destination down that connections minimizes the connection
overhead and consumes less resources than opening lots of sessions concurrently
it removes some flexibility in the ways the recipient MX can shed load or share
resources fairly. You can't always cleanly tell a sender to go away and come
back later while they have a session open, so if you want to be able to
throttle the resources a particular sender uses (where an open socket is one of
those resources) you really want them to reconnect regularly, so you can tell
them to go away at connect time. Allowing them to just nail up a connection and
keep sending mail down it prevents you from doing that.
The recipient ISP generally wants bulk mail to be delivered, but doesn't want
it to cause delays in other mail (both other bulk mail, but more importantly
1:1 mail) so they also don't want an ESP to just open "many" parallel
connections and tie up a lot of MX resources so the MX will have to defer mail
it would prefer to be delivered first.
So many ISPs have multiple limits on what a sender is allowed to do, either
fixed values or ones that vary based on sender reputation or server load. Total
mails per hour, mails per session, recipients per session, number of concurrent
connections, new connections per hour, all either per-MX or per cluster are
some things that a recipient ISP might limit, in order to provide some weighted
fairness in whose mail gets delivered when.
As a sending ESP there's a concern that if you actually hit some of those
limits consistently, rather than keeping below them yourself, the recipient ISP
will consider that poor form and penalize you for it. It's a reasonable
concern, so ESPs go to some effort to stay somewhat inside the constraints an
ISP enforces.
("Why am I getting 4xx deferrals from Yahoo?", "Because it's a day with a Y in
it.")
Cheers,
Steve
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
>
> From: mailop <mailop-boun...@mailop.org> On Behalf Of Benjamin BILLON via
> mailop
> Sent: Thursday, September 5, 2019 10:08 AM
> To: mailop@mailop.org
> Subject: [EXTERNAL] Re: [mailop] Resolving issues for several yahoo domains?
>
> > Hate to imagine how much mail is currently trying to get into Yahoo and AOL
> Same. Hate also to imagine the day (and night?) of the folks working on
> fixing that.
>
> --
> Benjamin
>
>
> From: Dave Holmes <d...@instiller.co.uk>
> Sent: jeudi 5 septembre 2019 15:57
> To: Benjamin BILLON <bbil...@splio.com>
> Cc: mailop@mailop.org
> Subject: Re: [mailop] Resolving issues for several yahoo domains?
>
> Not the quickest or easiest to do as a lot of senders will have different
> limits on different IP pools depending on reputation / previous throughput.
>
> I've dropped in a platform wide rule to back off the mail queues when the
> response is encountered - should do the Job.
>
> Hate to imagine how much mail is currently trying to get into Yahoo and AOL
>
> On Thu, 5 Sep 2019 at 14:39, Benjamin BILLON via mailop <mailop@mailop.org>
> wrote:
> Yes, everyone.
> Some, very few, emails are accepted. I believe their servers are overloaded.
> I suggest everyone to back off a bit, for instance by limiting the number of
> concurrent connections per outbound IP to ... 1. Until it gets better.
> Forcing our way through is not gonna work, or help.
>
> The DNS issue seems solved now.
>
> --
> Benjamin
>
>
> From: mailop <mailop-boun...@mailop.org> On Behalf Of Dave Holmes via mailop
> Sent: jeudi 5 septembre 2019 15:21
> To: Ewald Kessler | Webpower <ewald.kess...@webpower.nl>
> Cc: mailop <mailop@mailop.org>
> Subject: Re: [mailop] Resolving issues for several yahoo domains?
>
> Were seeing large mail queues forming on our side but I think this extends
> beyond the DNS I've not come across this message from Yahoo before.
>
> Error: "421 Service not available, closing transmission channel tnmpmscs"
>
> So whilst we have the DNS resolution (possibly cached) they are dropping
> connections all over the place, same goes for all of their other domains.
>
> Anyone else with issues delivering after DNS resolves
>
>
> On Thu, 5 Sep 2019 at 10:31, Ewald Kessler | Webpower via mailop
> <mailop@mailop.org> wrote:
> Yes, Oath (a.o. Yahoo, AOL) is having serious issues. Their engineers are
> working to resolve the issues.
>
> Regards,
> Ewald
>
> On Thu, 5 Sep 2019 at 10:35, tobisworld--- via mailop <mailop@mailop.org>
> wrote:
> We're currently seeing several yahoo domains (ex yahoo.de) cannot be
> resolved any more in DNS. All the responsable nameservers for that
> domain do not reply anymore. Only ns4.yahoo.com replies from time to
> time for yahoo.de but according to glue record ns4.yahoo.com is not in
> charge for yahoo.de anymore.
>
> anyone else seeing such problems with yahoo?
>
> --
> Cheers
>
> tobi
>
> _______________________________________________
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
> --
> Deliverability & Abuse Management, www.webpower-group.com
> ewald.kess...@webpower.nl
> t: +31 342 423 262
> li: www.linkedin.com/in/ewaldkessler
> _______________________________________________
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
> --
>
> <image002.jpg>
>
> Dave Holmes
> Technical Director
>
> d...@instiller.co.uk
> T 0333 939 0013 | M 07966 013 309
> 1 Park Farm Barns | Packington Lane | Stonebridge | CV7 7TL
>
>
>
> Instiller is a trademark of Instiller Limited, registered in England 5053657.
>
> This email contains proprietary information, some of which may be legally
> privileged. It is for the intended recipient only.
> If an addressing or transmission in error has misdirected this email, please
> notify the author by replying to this email.
> If you are not the intended recipient, you must not use, disclose,
> distribute, copy, print or rely on this email.
>
> _______________________________________________
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
> --
>
> <image002.jpg>
>
> Dave Holmes
> Technical Director
>
> d...@instiller.co.uk
> T 0333 939 0013 | M 07966 013 309
> 1 Park Farm Barns | Packington Lane | Stonebridge | CV7 7TL
>
>
> Instiller is a trademark of Instiller Limited, registered in England 5053657.
>
> This email contains proprietary information, some of which may be legally
> privileged. It is for the intended recipient only.
> If an addressing or transmission in error has misdirected this email, please
> notify the author by replying to this email.
> If you are not the intended recipient, you must not use, disclose,
> distribute, copy, print or rely on this email.
>
> _______________________________________________
> 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
