Em 08/01/2013, às 17:16, Wietse Venema wie...@porcupine.org escreveu:
Reindl Harald:
Big deal. Now I can block all mail for gmail.com by getting 100
email messages into your queue
how comes?
how do you get gmail.com answer to any delivery from you with 4xx?
He wants to temporarily
Barring a clean slow down signal, and a stable feedback mechanism,
the only strategy is manually tuned rate delays, and spreading the
load over multiple sending IPs (Postfix instances don't help if
they share a single IP).
I have multiple instances of Postfix running on multiple IPs. The
I agree with Reindl, I guess Witsie is now better understanding the problem
here.
I'd see this as a additional feature, not default configuration.
It would be even better if that could be parametrized on named transport basis.
- Rafael
Em 08/01/2013, às 19:02, Reindl Harald
When faced with a destination that imposes tight rate limits you
must pre-configure your MTA to always stay under the limits. Nothing
good happens when the Postfix output rate under load exceeds the
remote limit whether you throttle the queue repeatedly or not.
But many times we just don't
That's not what happens when a destination is throttled, all mail
there is deferred, and is retried some indefinite time later that
is at least 5 minutes but perhaps a lot longer, and at great I/O
cost, with expontial backoff for each message based on time in the
queue, …
I totally disagree
On Wed, Jan 09, 2013 at 10:02:02AM -0200, Rafael Azevedo - IAGENTE wrote:
[ ... ]
To understand what one is asking for, one needs to understand the
scheduler (qmgr) architecture. Otherwise, one is just babbling
nonsense (no offense intended).
Where can I read more about this?
I think
On Wed, Jan 09, 2013 at 10:02:02AM -0200, Rafael Azevedo - IAGENTE wrote:
That's not what happens when a destination is throttled, all mail
there is deferred, and is retried some indefinite time later that
is at least 5 minutes but perhaps a lot longer, and at great I/O
cost, with
I was watching my log files now looking for deferred errors, and for my
surprise, we got temporary blocked by Yahoo on some SMTPs (ips), as shown:
Jan 9 13:20:52 mxcluster yahoo/smtp[8593]: 6731A13A2D956: host
mta5.am0.yahoodns.net[98.136.216.25] refused to talk to me: 421 4.7.0 [TS02]
On Wed, 9 Jan 2013 13:29:06 -0200
Rafael Azevedo - IAGENTE raf...@iagente.com.br wrote:
I was watching my log files now looking for deferred errors, and for
my surprise, we got temporary blocked by Yahoo on some SMTPs (ips),
as shown:
Jan 9 13:20:52 mxcluster yahoo/smtp[8593]:
There's gotta be a solution for this.
There is - you need to register your mailserver(s) with yahoo
You mean Yahoo's Feedback Program (feedbackloop.yahoo.net) ?
- Rafael
On Wed, Jan 09, 2013 at 01:29:06PM -0200, Rafael Azevedo - IAGENTE wrote:
I was watching my log files now looking for deferred errors, and
for my surprise, we got temporary blocked by Yahoo on some SMTPs
(ips), as shown:
Jan 9 13:20:52 mxcluster yahoo/smtp[8593]: 6731A13A2D956: host
Wietse:
My conclusion is that Postfix can continue to provide basic policies
that avoid worst-case failure modes, but the choice of the settings
that control those policies is better left to the operator. If the
receiver slams on the brakes, then Postfix can suspend deliveries,
but the sender
John,
We've already done that.
We do sign ALL messages with DKIM and are also subscribed for Yahoo Feedback
Loop Program.
Still there are few messages being blocked based on users complaints or
unusual traffic from the IP xxx…
- Rafael
Em 09/01/2013, às 13:45, John Peach
I was watching my log files now looking for deferred errors, and
for my surprise, we got temporary blocked by Yahoo on some SMTPs
(ips), as shown:
Jan 9 13:20:52 mxcluster yahoo/smtp[8593]: 6731A13A2D956: host
mta5.am0.yahoodns.net[98.136.216.25] refused to talk to me: 421 4.7.0 [TS02]
Rafael Azevedo - IAGENTE:
I was watching my log files now looking for deferred errors, and
for my surprise, we got temporary blocked by Yahoo on some SMTPs
(ips), as shown:
Jan 9 13:20:52 mxcluster yahoo/smtp[8593]: 6731A13A2D956: host
mta5.am0.yahoodns.net[98.136.216.25] refused to talk to
Rafael Azevedo - IAGENTE:
I was watching my log files now looking for deferred errors, and
for my surprise, we got temporary blocked by Yahoo on some SMTPs
(ips), as shown:
Jan 9 13:20:52 mxcluster yahoo/smtp[8593]: 6731A13A2D956: host
mta5.am0.yahoodns.net[98.136.216.25] refused to talk
Now Yahoo is giving another response:
said: 451 Message temporarily deferred - [160] (in reply to end of DATA command)
See, this is very hard to solve. I'm really truing to better understand the
problem in order to find out the best solution. I'd like to thank in advance
for the help, its
Rafael Azevedo - IAGENTE:
Why does this difference matter? Once the sending rate drops under
rate at which mail enters the mail queue, all strategies become
equivalent to throwing away mail.
I'm trying to understand what you said but it doesn't make any sense to me.
When you can send N
Rafael Azevedo - IAGENTE:
When all greetings fail with 4xx or whatever then Postfix will
suspend deliveries.
I have no idea about what I'm doing wrong, this really doesn't
happen in my servers.
No it doesn't. Postfix logs delivery temporarily suspended and
skips Yahoo until the dead host
Hi Viktor,
I've added this into my main.cf:
slow_destination_concurrency_failed_cohort_limit = 5
But I noticed that even after a failure, postfix keeps trying to deliver to the
destination.
Question: how can I stop postfix from trying to deliver emails after few
failures?
I mean, if it is
Rafael Azevedo - IAGENTE:
[ Charset ISO-8859-1 unsupported, converting... ]
Hi Viktor,
I've added this into my main.cf:
slow_destination_concurrency_failed_cohort_limit = 5
This stops deliveries after 5 COHORT failures.
I mean, if it is trying to deliver to xyz.com and it fails 5
Wietse Venema:
Rafael Azevedo - IAGENTE:
I've added this into my main.cf:
slow_destination_concurrency_failed_cohort_limit = 5
This stops deliveries after 5 COHORT failures.
I mean, if it is trying to deliver to xyz.com and it fails 5 times,
Yes, but you configured
Rafael Azevedo - IAGENTE:
Hi Witsie,
Is there anyway we can adjust Postfix to stop delivering after a
4XX reply?
Postfix will stop delivering after TCP or SMTP handshake failure.
Postfix WILL NOT stop delivering due to 4xx reply AFTER the SMTP
protocol handshake.
Postfix is not a tool to
On Tue, Jan 08, 2013 at 10:47:08AM -0200, Rafael Azevedo - IAGENTE wrote:
I've added this into my main.cf:
slow_destination_concurrency_failed_cohort_limit = 5
This is fine, since you set the concurrency limit to 1, it is
intended to avoid shutting down deliveries after a single connection
Thank you Witsie.
We have a huge mail volume thats why I'm trying to figure out a better way to
deal with it.
Many providers have their own restrictions. We do work in compliance with most
of them, but there are a few that just won't help at all, so its easy to tell
me to make the necessary
Rafael Azevedo - IAGENTE:
I truly believe that postfix is the best MTA ever, but you might
agree with me that when the receiver start blocking the sender,
its worthless to keep trying to deliver.
1) Postfix will back off when the TCP or SMTP handshake fails. This
is a clear signal that a site
But Witsei, would you agree with me that error 4XX is (in general cases) a
temporary error?
Why keep trying when we have a clear signal of a temporary error?
Also, if we had a temporary error control (number of deferred messages by
recipient), it would be easy to identify when postfix should
On Tue, Jan 08, 2013 at 01:59:14PM -0200, Rafael Azevedo - IAGENTE wrote:
But Witse, would you agree with me that error 4XX is (in general
cases) a temporary error?
It is a temporary error for *that* recipient. It is not a global
indication that the site is temporary unreachable. Nor is there
Rafael Azevedo - IAGENTE:
Why keep trying when we have a clear signal of a temporary error?
As Victor noted Postfix does not keep trying the SAME delivery.
Instead, Postfix tries to deliver a DIFFERENT message. It would be
incorrect IN THE GENERAL CASE to postpone ALL deliveries to a site
just
Em 08/01/2013, às 14:21, Wietse Venema wie...@porcupine.org escreveu:
Rafael Azevedo - IAGENTE:
Why keep trying when we have a clear signal of a temporary error?
As Victor noted Postfix does not keep trying the SAME delivery.
Yes you're right and I know that. But it keeps trying for another
Att.
--
Rafael Azevedo | IAGENTE
Fone: 51 3086.0262
MSN: raf...@hotmail.com
Visite: www.iagente.com.br
Em 08/01/2013, às 14:07, Viktor Dukhovni postfix-us...@dukhovni.org escreveu:
On Tue, Jan 08, 2013 at 01:59:14PM -0200, Rafael Azevedo - IAGENTE wrote:
But Witse, would you agree with me
On 08/01/2013 16:38, Rafael Azevedo - IAGENTE wrote:
Em 08/01/2013, às 14:21, Wietse Venema wie...@porcupine.org
escreveu:
Rafael Azevedo - IAGENTE:
Why keep trying when we have a clear signal of a temporary
error?
As Victor noted Postfix does not keep trying the SAME delivery.
Yes you're
Rafael Azevedo - IAGENTE:
Instead, Postfix tries to deliver a DIFFERENT message. It would be
incorrect IN THE GENERAL CASE to postpone ALL deliveries to a site
just because FIVE recipients were unavailable.
Thats why it would be interesting to have a way to configure that.
Configurable,
Am 08.01.2013 17:44, schrieb Mark Goodge:
On 08/01/2013 16:38, Rafael Azevedo - IAGENTE wrote:
Em 08/01/2013, às 14:21, Wietse Venema wie...@porcupine.org
escreveu:
Rafael Azevedo - IAGENTE:
Why keep trying when we have a clear signal of a temporary
error?
As Victor noted Postfix does
Am 08.01.2013 17:48, schrieb Wietse Venema:
Rafael Azevedo - IAGENTE:
Instead, Postfix tries to deliver a DIFFERENT message. It would be
incorrect IN THE GENERAL CASE to postpone ALL deliveries to a site
just because FIVE recipients were unavailable.
Thats why it would be interesting to
One of the most common reasons for a temporary delivery failure is a full
mailbox. Or, where the remote server is acting as a store-and-forward, a
temporary inability to verify the validity of the destination address.
I dont agree with that. Connection time out is the most common reason
Configurable, perhaps. But it would a mistake to make this the
default strategy.
That would make Postfix vulnerable to a trivial denial of service
attack where one bad recipient can block all mail for all other
recipients at that same site.
Not if it could me parametrized. As I said,
Yes Reindl, you got the point. I just want to wait for a while before retrying
to send email to the same destination.
Am 08.01.2013 17:48, schrieb Wietse Venema:
Rafael Azevedo - IAGENTE:
Instead, Postfix tries to deliver a DIFFERENT message. It would be
incorrect IN THE GENERAL CASE to
On Tue, Jan 08, 2013 at 03:04:37PM -0200, Rafael Azevedo - IAGENTE wrote:
Configurable, perhaps. But it would a mistake to make this the
default strategy.
That would make Postfix vulnerable to a trivial denial of service
attack where one bad recipient can block all mail for all other
Rafael Azevedo - IAGENTE:
Configurable, perhaps. But it would a mistake to make this the
default strategy.
That would make Postfix vulnerable to a trivial denial of service
attack where one bad recipient can block all mail for all other
recipients at that same site.
Not if it
Am 08.01.2013 19:08, schrieb Wietse Venema:
Rafael Azevedo - IAGENTE:
Configurable, perhaps. But it would a mistake to make this the
default strategy.
That would make Postfix vulnerable to a trivial denial of service
attack where one bad recipient can block all mail for all other
On Tue, Jan 08, 2013 at 01:08:21PM -0500, Wietse Venema wrote:
I could add an option to treat this in the same manner as failure
to connect errors (i.e. temporarily skip all further delivery to
this site). However, this must not be the default strategy, because
this would hurt the far
Reindl Harald:
Big deal. Now I can block all mail for gmail.com by getting 100
email messages into your queue
how comes?
how do you get gmail.com answer to any delivery from you with 4xx?
He wants to temporarily suspend delivery when site has 5 consecutive
delivery errors without
Am 08.01.2013 20:16, schrieb Wietse Venema:
Reindl Harald:
Big deal. Now I can block all mail for gmail.com by getting 100
email messages into your queue
how comes?
how do you get gmail.com answer to any delivery from you with 4xx?
He wants to temporarily suspend delivery when site has
Viktor Dukhovni:
On Tue, Jan 08, 2013 at 01:08:21PM -0500, Wietse Venema wrote:
I could add an option to treat this in the same manner as failure
to connect errors (i.e. temporarily skip all further delivery to
this site). However, this must not be the default strategy, because
this
On Tue, Jan 08, 2013 at 02:39:17PM -0500, Wietse Venema wrote:
Viktor Dukhovni:
On Tue, Jan 08, 2013 at 01:08:21PM -0500, Wietse Venema wrote:
I could add an option to treat this in the same manner as failure
to connect errors (i.e. temporarily skip all further delivery to
this
Am 08.01.2013 20:51, schrieb Viktor Dukhovni:
On Tue, Jan 08, 2013 at 02:39:17PM -0500, Wietse Venema wrote:
Viktor Dukhovni:
On Tue, Jan 08, 2013 at 01:08:21PM -0500, Wietse Venema wrote:
I could add an option to treat this in the same manner as failure
to connect errors (i.e.
Viktor Dukhovni:
On Tue, Jan 08, 2013 at 02:39:17PM -0500, Wietse Venema wrote:
Viktor Dukhovni:
On Tue, Jan 08, 2013 at 01:08:21PM -0500, Wietse Venema wrote:
I could add an option to treat this in the same manner as failure
to connect errors (i.e. temporarily skip all further
Am 08.01.2013 21:40, schrieb Wietse Venema:
My conclusion is that Postfix can continue to provide basic policies
that avoid worst-case failure modes, but the choice of the settings
that control those policies is better left to the operator. If the
receiver slams on the brakes, then Postfix
On Tue, Jan 08, 2013 at 10:02:31PM +0100, Reindl Harald wrote:
Am 08.01.2013 21:40, schrieb Wietse Venema:
My conclusion is that Postfix can continue to provide basic policies
that avoid worst-case failure modes, but the choice of the settings
that control those policies is better left to
Am 09.01.2013 02:57, schrieb Viktor Dukhovni:
On Tue, Jan 08, 2013 at 10:02:31PM +0100, Reindl Harald wrote:
Am 08.01.2013 21:40, schrieb Wietse Venema:
My conclusion is that Postfix can continue to provide basic policies
that avoid worst-case failure modes, but the choice of the settings
On Wed, Jan 09, 2013 at 03:06:58AM +0100, Reindl Harald wrote:
Suspending delivery and punting all messages from the active queue
for the designated nexthop is not a winning strategy. In this state
mail delivery to the destination is in most cases unlikely to
recover without manual
Am 09.01.2013 03:17, schrieb Viktor Dukhovni:
the request was after 20 temp fails to the same destination
retry the next delivers to THIS destination FIVE MINUTES later
That's not what happens when a destination is throttled, all mail
there is deferred, and is retried some indefinite time
Guys,
I've identified a missbehavior on postfix.
I do use destination_rate_delay for specific transport queue, and I found out
that connection cache is not working when I have
transport_destination_rate_delay 1s.
If I change the destination_rate_delay to higher than 1s, connection cache
Rafael Azevedo - IAGENTE:
I do use destination_rate_delay for specific transport queue, and
I found out that connection cache is not working when I have
transport_destination_rate_delay 1s.
The default time limit is 2s, and it is enforced in multiple places.
You have found only one.
As
Hi Wietse,
I don't really get. I'm also sure postfix has a way to solve this issue.
This is what I'm trying to do:
- I need to have only one process to this transport's queue.
- This queue must respect the destination's policy, so I can't have more than
20 opened connections in 10 minutes
Rafael Azevedo - IAGENTE:
Hi Wietse,
I don't really get. I'm also sure postfix has a way to solve this issue.
I told you that there are two parameters that enforce the time limit.
Wietse
Could you please refresh my mind?
Thanks.
Att.
--
Rafael Azevedo | IAGENTE
Fone: 51 3086.0262
MSN: raf...@hotmail.com
Visite: www.iagente.com.br
Em 07/01/2013, às 12:17, Wietse Venema wie...@porcupine.org escreveu:
Rafael Azevedo - IAGENTE:
Hi Wietse,
I don't really get. I'm also sure
On Mon, Jan 07, 2013 at 11:34:45AM -0200, Rafael Azevedo - IAGENTE wrote:
This is what I'm trying to do:
- I need to have only one process to this transport's queue.
mumble_destination_concurrency_limit = 1
- This queue must respect the destination's policy, so I can't
have more
Hi Viktor, thanks for helping.
I've done something very similar.
I created different named transports for specific domains and have all domains
I need a special treatment to use this named transport.
So since I'm using Postfix + MySQL, I have a transport table with all domains
and destination
On Mon, Jan 07, 2013 at 02:37:03PM -0200, Rafael Azevedo - IAGENTE wrote:
I've done something very similar.
If you want help, please take some time to read and follow the
advice you receive completely and accurately. Similar is another
way of saying incorrect.
I created different named
Hi Viktor,
Thanks once again for helping me on this.
Please understand that I'm very open and thankful for any help. I'm also
trying to understand what you meant.
Getting whitelisted is always the best solution, but believe me, there are some
providers that just don't answer any email, they
Hi Viktor,
I was reading the documentation and found out something very interesting.
If I use mumble_destination_concurrency_limit = 1, the destination is a
recipient not a domain.
Since I'm trying to control the throughput per destination domain, it is
necessary to use
Hi Viktor,
Thanks for the help.
I believe I've activated the next hop feature in my transport table.
If I understood it right, all I had to do is tell postfix that these domains
belongs to my named transport specifying the domain.
So this is how it is now:
criticaldomain.tld
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
On Mon, Jan 07, 2013 at 03:29:53PM -0200, Rafael Azevedo - IAGENTE wrote:
I believe I've activated the next hop feature in my transport table.
If I understood it right, all I had to do is tell postfix that
these domains belongs to my named transport specifying the domain.
So this is how
On Mon, Jan 07, 2013 at 03:19:39PM -0200, Rafael Azevedo - IAGENTE wrote:
If I use mumble_destination_concurrency_limit = 1, the destination
is a recipient not a domain.
This is wrong. The setting in question is the recipient_limit, not
the concurrency limit.
Thank you so much Viktor, now I fully understand what you said.
Cheers.
Att.
--
Rafael Azevedo | IAGENTE
Fone: 51 3086.0262
MSN: raf...@hotmail.com
Visite: www.iagente.com.br
Em 07/01/2013, às 15:57, Viktor Dukhovni postfix-us...@dukhovni.org escreveu:
On Mon, Jan 07, 2013 at 03:29:53PM
Hi Viktor,
I've done exactally what you said and notice that the connection cache is not
being used anymore.
I ran a script with loop sending email to few recipients, and the cache seems
not be working (after commenting slow_destination_rate_delay).
Changing slow_destination_rate_delay to 1s
On Mon, Jan 07, 2013 at 04:24:20PM -0200, Rafael Azevedo - IAGENTE wrote:
I've done exactally what you said and notice that the connection
cache is not being used anymore.
You have enabled cache-on-demand behaviour. This happens when the active
queue contains a backlog of messages to the
Viktor Dukhovni:
On Mon, Jan 07, 2013 at 04:24:20PM -0200, Rafael Azevedo - IAGENTE wrote:
I've done exactally what you said and notice that the connection
cache is not being used anymore.
You have enabled cache-on-demand behaviour. This happens when the active
queue contains a backlog
On Mon, Jan 07, 2013 at 04:02:36PM -0500, Wietse Venema wrote:
On Mon, Jan 07, 2013 at 04:24:20PM -0200, Rafael Azevedo - IAGENTE wrote:
I've done exactally what you said and notice that the connection
cache is not being used anymore.
You have enabled cache-on-demand behaviour.
72 matches
Mail list logo
