[quoted text, click to view] > I'm looking up information on 452+Too+many+recipients+
> received+this+hour error. Beyond adjusting the Delivery Setting
> timeouts, there seems to not be much else I can find. Anyone have
> other information on how to have these types of messages retried?
As you can well imagine, given that the 4.5.2->5.5.2 upleveling is
declared a feature of the SMTP module, there's no way I'm aware of to
turn it off.
That means you have to approach the problem defensively. In a sense,
this is appropriate given that in many circumstances, even if the 4xx
_were not_ upleveled and entered the retry queue, business-type 15m/8x
- 30m/16x retry cycles still might not get the message through. [Note
I am accepting that the rate throttling claim from the remote server
is the true reason for the deferral.]
The point, then, is that you have to implement defensive throttling at
your end without being unnecessarily user-impacting. You can't
reasonably refuse connections between your MUAs and the submission
server; rather, what I would recommend is that you implement your own
throttling _between VS instances_ and/or on your outbound VS
instances.
That said, your throttling limits are limited in a single-box, all-IIS
solution. Even with SMTP overhead, on-box communication between VSs is
way faster than remote domains' throttling limits. You can try smart
hosting all sensitive/problem domains through a dedicated VS that is
limited to very few inbound and outbound connections, and further
bandwidth-limit outbound connections to problem domains using
third-party s/w like Bandwidth Controller. Granted, blind TCP-level
bandwidth limiting is not actually the same as SMTP application-level
(message-based) rate limiting, but it will have an equivalent effect.
Also, a rather robust workaround -- a secondary spooling/despooling
processor based on envelope information -- could be written as a
transport event sink; similar add-ons have been built for other
products and their logic (if open) might be portable. I will look into
it.
[quoted text, click to view] > PS: I guess asking the remote client to white list your IP is
> another option eh?
It certainly is, and that's the most proactive you can get. :)
--Sandy
------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
