Re: [exim] Rate Limiting?

Top Page
Delete this message
Reply to this message
Author: Richard Clayton
Date:  
To: Chris Edwards
CC: exim-users
Subject: Re: [exim] Rate Limiting?
In message <Pine.SOC.4.62.0505121512090.16101@???>,
Chris Edwards <chris@???> writes

>On Thu, 12 May 2005, Richard Clayton wrote:
>
>| Since I'm writing : I can perhaps say something useful about failure
>| rates, and that is that they're a bit subjective; in that you don't want
>| to count failures to connect (or those people who think that greylisting
>| is a cool thing to do)
>
>I was assuming you look for hard fails of outgoing mail
>
>(the ** lines in the exim main log)


yes (though of course in reality one is worrying about destinations and
not emails per se)

>I suppose this will miss mails that get soft failed at the receiving site
>( the == log lines ) and there are a few sites that respond to spam/virus
>with 4xx.


there are sites that do almost everything you can imagine... but yes,
very little is done with "==" (except to pick out the destination
because there may not be a final decision about whether the mail is
delivered before the log file is rolled over and the processing begins)

no score, positive or negative, attaches to a "==" event

>| At Demon there's a transfer onto a fallback system (so as to keep the
>| main machine queue sizes under control) and that gives a suitable
>| breakpoint for declaring a "failure" without a great deal of book-
>| keeping in the log processing programs
>
>Sorry - I'm lost now.


when email has been queued for too long it is delivered to a second
machine (which doesn't in fact run Exim) where it can sit in queues of
millions of items without screwing up the timeliness of normal delivery

this means that there is a resolution of the status of almost all email
within the lifetime of a single log file -- so you don't end up keeping
a database of information from "yesterday" (this is because log lines
tend not to be self-contained, you need to collate information from <=
and => in order to generate useful reports)

>Many outgoing spam/virus mails will fail
>immediately, wheras some legit mails are delayed for one reason or
>another. So I don't quite see how the fallback hosts system helps here.
>
>Surely you need to track each message-id submitted (<=) and wait to see
>which end up failing (**).


yes ... except to nit-pick again, one needs to concentrate on
destinations, not emails (and these are not necessarily in 1-1
correspondence)

- -- 
richard                                              Richard Clayton


They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin