Catalin Constantin wrote:
> On Tue, Apr 21, 2009 at 2:50 PM, W B Hacker <wbh@???> wrote:
>> You have to tune for that.
>>
>> Nice thing about Exim is that you *can do*.
>>
>> But you will need to wake up, smell the coffee, and *RTFM* before
>> claiming Exim has a 'design flaw'.
>
> Thanks a lot. Will do (RTFM), again !
>
> I still have the impression that nobody read the scenario i posted a
> couple of mails ago.
I am comfortable that a good many very expert folk DID read it.
.. and also that we/they went *beyond* the symptom you were ranting
about to the underlying fix needed to 'JFDI'. AND NOT just by 'BFBI'.
I've been running Exim for 'a while' now. And other smtp, X.400, IRC.
private-leased international networks, and military comms even longer
(since 1965). I've even been in the position of having a decent chunk of
just-laid transpacific private fiber cable to do alpha testing with...
... yet I can easily name a good dozen Exim experts who know one or two
*orders of magnitude* more about *Exim* than I do.
Several of them have tried to help you.
Hard to do that if you have a 'fixation' on a mechanism detail in one
corner while the 'fix is in a different part of the arena.
> Exim can't handle that kind of situations in NORMAL ways. Either you
> brute force it (retry every 1s in the conf and runner) or leave it.
That is 'normal' for the decidedly stupid greylisting scenario.
Mind - it owrks - but 'too costly' given that other means get the job
done better, cheaper, faster.
Fortunately, MailAdmins soon learn that and it is on the wane.
Meanwhile - what you call 'brute force' (Google BFBI) is simply the only
tactic that makes economic sense.
Oh - one could precisely measure Yahoo's time-out and code a dynamic
adaptation that made the second attempt *exactly* on schedule and *only*
with sender/message deemed to be 'ripe' for acceptance.
But the resource load would be far higher than just kicking-off a
queue-runner more often. smtp ain't gaming or cryanalysis.
> Even if queue run is 55 seconds and retry is 2 min, etc. because it
> can't, because it's not implemented :)
>
With those settings one *doesn't have to care* about specific
$local_part for senders.
Surely you have a statistically significant number of recipients in
those 1,000 per-whack messages? How badly do you want to look, and how
closely when a decent setup will JFDI about as fast as Yahoo will allow
anyway?
Have you seen this:
http://hnsg.net/tutorials/exim_cpanel.html
Specifically:
=============
Multiple E-mail queues
If your mail queues for your server reach more than several hundred
messages, creating multiple e-mail queues will also create a significant
increase in e-mail performance. To do this, place the following options
in the main configuration section of /etc/exim/exim.conf:
split_spool_directory
queue_run_max = 5
remote_max_parallel = 5
These options split the spool directory so that Exim can handle the
larger spool files better, as well as create multiple spool threads (in
this case, 5 threads will simultaneously deliver mail at the same time
to 5 different hosts).
==============
Mind - that is old info, and just a starting point for your own research.
But *without* that sort of tuning, the settings I gave you produce
99.7%+ message transit in ONE SECOND or less.
> So my question resumes to:
> Why is retry_use_local_part not implemented for remote transports ?
>
Perhaps 'coz no one has really *needed* it yet?
I for one am yet to be convinced it would make any significant
difference, given that *many* greylisting schemes do not use the full
triplet available in any case. Too costly in terms of DB handling = more
load on *their* systems than the 'at point' spam reduction pays back.
> retry_use_local_part Use: transports Type: boolean Default: see below
> "For remote transports, the default value is false for
> tidiness, but changing the value has no effect on a remote transport
> in the current implementation."
>
> Anyway i don't want to insist too much and argue about it or upset
> anybody. This is just my private opinion.
>
> BTW: We ran out of coffee this morning :)
ROFL!
Nearly out here as well .. and another month to go befoe the Social
Security cheque hits the bank...
Thank you, Bernie Ebbers....
:-(
Anyway ... I've plenty of decent tea...
Bill
