On Mon, Dec 31, 2012 at 08:46:03PM -0600, Stan Hoeppner wrote:
On 12/31/2012 3:06 PM, Marcin Owsiany wrote:
I imagine this might sound like a spam sending service, but it's not :-)
Hi Marcin,
Q1: Why is a Google Site Reliability Engineer and long time Debian
maintainer, with two
On 1/1/2013 7:33 AM, Marcin Owsiany wrote:
On Mon, Dec 31, 2012 at 08:46:03PM -0600, Stan Hoeppner wrote:
On 12/31/2012 3:06 PM, Marcin Owsiany wrote:
I imagine this might sound like a spam sending service, but it's not :-)
Hi Marcin,
Q1: Why is a Google Site Reliability Engineer and long
Wietse Venema wietse at porcupine.org writes:
It is not a major effort to give those cache entries a finite
time-to-live but this needs a better justification that what appears
to be an attempt to circumvent Yahoo rate limits.
I have a need similar to the original poster. In my case the use
Marcin Owsiany:
Wietse Venema wietse at porcupine.org writes:
It is not a major effort to give those cache entries a finite
time-to-live but this needs a better justification that what appears
to be an attempt to circumvent Yahoo rate limits.
I have a need similar to the original poster.
On Mon, Dec 31, 2012 at 02:05:38PM -0500, Wietse Venema wrote:
Marcin Owsiany:
Wietse Venema wietse at porcupine.org writes:
It is not a major effort to give those cache entries a finite
time-to-live but this needs a better justification that what appears
to be an attempt to circumvent
Marcin Owsiany:
Ideally the smtp daemon would be able to bind to a few addresses and
there would be an option to assign egress traffic split between them.
According to source code, the Postfix 2.5 and later resolver client
will reuse the trivial-rewrite daemon result for up to 30 seconds
when
On Mon, Dec 31, 2012 at 05:00:52PM -0500, Wietse Venema wrote:
Marcin Owsiany:
Ideally the smtp daemon would be able to bind to a few addresses and
there would be an option to assign egress traffic split between them.
According to source code, the Postfix 2.5 and later resolver client
Wietse:
20070414
Cleanup: expire cached results from addres rewriting, address
resolution, and from transport map lookups. Results expire
after 30 seconds; short enough that it doesn't freak out
people who run the same test repeatedly, and long enough
On Mon, Dec 31, 2012 at 05:45:57PM -0500, Wietse Venema wrote:
In that case, a burst of 1s would still be undesirable, so one would
have to be able to specify 0 (no caching) while the default would
remain at 30s.
Right.
I hope that disabling caching altogether would not affect performance
Marcin Owsiany:
On Mon, Dec 31, 2012 at 05:45:57PM -0500, Wietse Venema wrote:
In that case, a burst of 1s would still be undesirable, so one would
have to be able to specify 0 (no caching) while the default would
remain at 30s.
Right.
I hope that disabling caching altogether would
On 12/31/2012 3:06 PM, Marcin Owsiany wrote:
I imagine this might sound like a spam sending service, but it's not :-)
Hi Marcin,
Q1: Why is a Google Site Reliability Engineer and long time Debian
maintainer, with two Masters degrees, working on an email blasting
infrastructure?
Q2: Why are
B?ny?sz Botond:
I dont think that the problem cames from transport map 1-element
caching, because the destination is variable, we have millions of
email addresses.
The trivial-rewrite server has a 1-element cache for the wild-card
lookup result, and the trivial-rewrite client has a
I dont think that the problem cames from transport map 1-element caching,
because the destination is variable, we have millions of email addresses.
I made some tests with mysql general logging enabled and i found that when
mysql lookup table checks a transport for a destination it does a lookup
B?ny?sz Botond:
I dont think that the problem cames from transport map 1-element
caching, because the destination is variable, we have millions of
email addresses.
The trivial-rewrite server has a 1-element cache for the wild-card
lookup result, and the trivial-rewrite client has a 1-element
Hy,
I want to setup a system who warmes the sending ip`s, so i made a mysql
transport map where per domain i can add how much % to relay from main
ip pool to the warmup ip pool. The problem is that if manually I change in the
database for example yahoo.com domain
from 0 percent to 100
On 2/24/2012 2:04 AM, Bányász Botond wrote:
Hy,
I want to setup a system who warmes the sending ip`s, so i made a
mysql transport map where per domain i can add how much % to relay
from main ip pool to the warmup ip pool. The problem is that if
manually I change in the database for example
, February 24, 2012 3:41 PM
Subject: Re: postfix mysql lookup table has some kind of caching?
On 2/24/2012 2:04 AM, Bányász Botond wrote:
Hy,
I want to setup a system who warmes the sending ip`s, so i made a
mysql transport map where per domain i can add how much % to relay
from main ip pool
On 2/24/2012 8:04 AM, Bányász Botond wrote:
What means this 1-element cache? it caches the last lookup?
Right. The cache is not specific to mysql, but is a feature of the
trivial-rewrite transport lookup.
This is only likely to be noticed when you use mysql-based
transport_maps and a high
18 matches
Mail list logo
