Here are some further comments on Georg's message:
On Fri, 23 Oct 1998, Georg v.Zezschwitz wrote:
> - A very silly Firewall SMTP-Implementation that tries to limit
> the incoming mail size by "interrupting" the connection.
> (Yes, it just drops the connection at x MB. This is really
> good for ISPs having a volumne-based charge)
> Beneath the traffic, other messages get stuck behind the
> big one.
I don't think my new scheme helps with this case. Dropping the
connection is always treated as a host error, delaying any further mail
to that host. Some messages may eventually get through, because Exim
tries them in 'random' order.
> I think this policy is acceptable, but this might be possible:
>
> MAIL FROM: <mailing@???> SIZE=<the size is BIIIG>
> 250 You are welcome
> RCPT TO: <gvz@???>
> 250 O.k., Georg love's to get big mails
> RCPT TO: <poorboy@???>
> 420-Sorry, this user just has a 10 MB-POP3-box, your mail does not
> 420-fit in at the moment...
>
> poorboy will get no further messages from us, till his retry time
> is reached...
I have changed the code so that new messages addressed to
poorboy@??? will try that address once before taking note of the
retry data, as I suggested in my previous message. However, this has the
effect of clearing the retry data if a message does actually get
through. Thus the large message would start getting tried again as soon
as a short one got delivered. If you have a steady supply of short
messages going through, the large one won't ever build up a long retry
time.
On the other hand, it is probably better than the current situation,
where a single failing message is tried at every queue run, especially
if the error is not specific to the message, but is given to all
occurrences of
RCPT TO: <poorboy@???>
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
--
*** Exim information can be found at
http://www.exim.org/ ***
