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 "d
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
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 being
> 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] ref
> Rafael Azevedo - IAGENTE:
>> I agree with Reindl, I guess Witsie is now better understanding
>> the problem here.
>
> Please take the effort to spell my name correctly.
Sorry about that Wietse. It was a typo mistake. I didn't intend to offend you.
> When a site sends a small volume of mail, t
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 ta
>> 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
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 escreveu:
> On We
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 se
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
>
On Wed, 9 Jan 2013 13:37:00 -0200
Rafael Azevedo - IAGENTE wrote:
>
> >> 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) ?
I forget exactly what needs doing, but you defi
>> 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, 9 Jan 2013 13:29:06 -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
> mta5.am
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]
Message
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
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 th
> 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 disa
> 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'
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 escreveu:
>
>
>
> 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.
Em 08/01/2013, às 17:16, Wietse Venema 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 suspend del
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 indefini
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 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
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 le
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 Postfi
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
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" err
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
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
>
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
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 di
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 ma
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 fo
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.
>
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
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 C
> 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
>
> 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
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 inte
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
>> escreveu:
>>
>>> Rafael Azevedo - IAGENTE:
Why keep trying when we have a clear signal of a temporary
error?
>>>
>>> As Victor noted Postfix doe
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.
Configu
On 08/01/2013 16:38, Rafael Azevedo - IAGENTE wrote:
Em 08/01/2013, às 14:21, Wietse Venema
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 tha
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 escreveu:
> 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 ge
Em 08/01/2013, às 14:21, Wietse Venema 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 recipients in
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
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
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 st
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 sit
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 ar
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
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
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 conf
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 fa
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 t
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
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
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 de
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 e
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 escreveu:
> On Mon, Jan 07, 2013 at 03:29:53PM -0200, Rafael Azevedo - IAGENTE
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.
> default_destination_concurrenc
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
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 ne
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.tldslow:criticald
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 destination_concurrency
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
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 t
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 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 mo
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 escreveu:
> Rafael Azevedo - IAGENTE:
>> Hi Wietse,
>>
>> I don't really get. I'm also sure postfix has a way
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
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 timef
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 Po
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
won
74 matches
Mail list logo
