On 03/19/10 16:13, Victor Duchovni wrote:
Forward mail for this domain to a separate queue (Postfix instance)
that handles mail for this---and perhaps some other similar---domains.
The slow domain will no longer clog your primary queue.
You are right that this will solve the problem, but isn't more correct
to do this automatically? I mean, this seems to be so basic that I don't
understand why postfix doesn't include a mechanism to overcome it.
Currently the only sane thing seems to be to raise the active queue
limit to the size of (or near to) the incoming queue, which makes the
delivery for other domains scream.
But that's lame, and needs a lot of ram for a problem, which could be
easily solved in other ways.
No?
Happy spamming...
I'm not spamming, just relaying it from customers. :)
BTW, these are e-mails, which the recipients are asked for. And they
even complain if they don't get it, or it not arrives in time.
And this is one for citromail:
Mar 19 15:47:47 mail postfix/smtp[33147]: 28E47768F4: to=<@citromail.hu>,
relay=server03.citromail.hu[91.83.45.3]:25, conn_use=76, delay=9538,
delays=5062/4475/0/0.33, dsn=2.0.0, status=sent (250 ok 1269010067 qp
29585)
The latency of "0.33" seconds is not unreasonably high. Is this typical
for deliveries to this domain? With a concurrency of 20, you should be
able to deliver ~60 messages per second to this destination. Can you
compute a "smoothed" latency for this destination?
I've only written this, because I was sure that somebody would miss it.
This destination is not slow because of slow delivery times on the
already open connections, but because of connection timeouts (I can
observe this on other, mostly silent systems, which send only few
messages there) and artificial limits on the recipient side.
I'm aware of this, and we are always trying to make that better, but
what I would like to know is why does postfix behaves this way.
This is a built-in DoS feature, which could be easily solved, or I miss
something?
initialize: lavg := 0;
count := 0;
step: lavg := lavg * 0.95 + (c + d) * 0.05;
count := count + 1
if (count % 100 == 0)
println lavg;
egrep 'to.*citromail\.hu.*status=sent' maillog | egrep -o
'[0-9]+/[0-9]+/[0-9]+/[0-9]+' | awk -F '/' '{a=$1;b=$2;c=$3;d=$4;
lavg=lavg*0.95+(c+d)*0.05; count=count+1; if (count % 100 == 0) print lavg}'
[...]
0.0980931
1.02489
0.208484
0.107523
0.133513
0.0688768
0.113402
0.147406
0.00180754
0.00580981
3.43972e-05
0.258655
0.808811
0.0400146
0.265047
0.326359
0.206881
0.105975
0.0130569
0.187074
0.00519059
0.176418
0.65363
0.328516
0.272575
1.61656
0.0708661
0.522564
0.0504923
0.164537
1.28451
2.45355
0.629623
0.629201
1.16992
0.0219805
0.0325643
0.0172668
0.462079
0.0463653
0.195138
0.102266
0.0337765
0.505287
1.30806
0.522909
0.176148
0.00399868
0.654791
0.204687
0.24754
How many concurrent connections do you have for this destination?
What is the destination concurrency limit?
foreach i (`jot 8`)
foreach? netstat -a | egrep 'citroma.*ESTAB' | wc -l
foreach? sleep 1
foreach? end
17
15
13
19
19
20
15
17
50
I know where the problem is (so you do :), I just don't understand why
is it good to have this feature in postfix.