On Sun, 7 Jan 2001, Vadim Vygonets wrote:
> And here it is, as promised. I'm kinda late, and most things
> seem to be discussed to death.
Nevertheless, some useful comments. Thanks.
> Nice. I would also like to propose multiple router lists for
> different sets of domains, ending with "break" (to stop router
> processing and reject message if all routers failed) or
> "continue" or "fallthrough" (to continue router processing).
I'm wary of this simply because of the increase complexity of parsing
the configuration file. But I'll think about it.
> In redirect router, match_directory from today's forwardfile
> director should probably be eliminated and replaced with a test
> like "condition = ${if{matches{$home}{/group}}{yeah}}" when
> needed. But there will be lots of coments like this, I'm afraid.
Valid point. It's a fairly minority condition.
> forbid_special should be extended to affect all of redirect
> router (including today's smartuser).
Yes, it will.
> "authenticated" should probably take a parameter specifying valid
> IDs to allow different people do different things based on the ID
> they authenticated with.
Another good point. Actually, perhaps we need a more general "condition"
setting that can expand a string, and thereby test any of the variables
that are set up at this stage.
> === Feature request
>
> Spammers these days use programs that just send all of the SMTP
> dialogue in one big write(), without waiting for the server to
> respond. Maybe Exim should have an option (defaulting to true)
> to check whether any input on SMTP connection is available (using
> select(2) with zero timeout) before sending each response, and
> drop the connection IMMEDIATELY if there are bytes to read.
> After all, RFC 821 says:
>
> # The dialog is purposely
> # lock-step, one-at-a-time.
But subsequent RFCs defined the PIPELINING extension to SMTP, and Exim
supports this. However, there are still points where the client is
supposed to wait before sending more data. This is an interesting idea
which could perhaps be applied at those points.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
