On Mon, Jan 07, 2013 at 03:06:42PM -0200, Rafael Azevedo - IAGENTE wrote:
> Anyway, I'll search how to use this "next hoop" feature and see
The term is "nexthop", this specifies the next system or systems
to which the message will be forwarded en-route to its destination
mailbox. With SMTP the nexthop is a domain (subject to MX lookups)
or [gateway] (not subject to MX lookups).
The syntax of transport entries for each delivery agent is specified
in the man page for that delivery agent, see the "SMTP DESTINATION SYNTAX"
section of:
http://www.postfix.org/smtp.8.html
> Although I'm still having to respect the amount of message per
> time frame so the question persists: how can I low down delivery
> to these destinations without opening too many connections to them?
You can reduce the connection rate by caching connections, which
works when you consolidate all the domains that use that provider
to a single transport/nexthop.
You can only reduce the message delivery rate by sending less mail.
To reduce the peak message delivery rate, you need to insert
artifiical delays between message deliveries, but this defeats
connection reuse. You can't have both if the limits are sufficiently
aggressive. You should probably ignore the message rate limit.
By capping both message rates and connection rates the receiving
system is hostile to legitimate bulk email. If the the hosted
users actually want your email, ask them to talk to the provider
on your behalf.
Otherwise, you can spread the load over multiple servers each
of which falls under the rate limits (snow-shoe).
> Having them all in one only transport/nexthop will not fix the
> problem if I don't control the throughput, right?
This will cause connection reuse, which combined with a destination
concurrency limit of 1, will minimize the number of connections
made.
--
Viktor.
