Tor Slettnes wrote:
>
..[snip]...
>
> So I now do something a little different. For various reasons I no
> longer use SA-Exim; instead, I have ACLs with "delay = 20s" at various
> points in the SMTP transaction (see below). For instance,
>
> - If a host provides a suspicious HELO greeting, they are stalled
> for 20 seconds right there, again after the MAIL, RCPT, and DATA
> commands, after which the message is rejected.
>
> - If the sender/callout verfication fails, that's 20 seconds after
> MAIL, another 20 seconds after RCPT, and a third time after DATA
> (but in this case, I do eventually accept the mail, unless SA flags
> it as spam as well).
>
> - If the recipient address does not exist, then that's 20 seconds
> after RCPT TO:.
>
> - And so on, and so forth. I'll include the various ACLs below.
>
..[snip]...
I use similar tactics for giving 'prefered service' to properly configured
hosts, and thus 'delay' any host that does not 'look??' proper, it does
work pretty good as one of the anti-spam/anti-worm measures.
>
>
> This has worked great so far (a few days). However, I can see a couple
> of issues looming:
>
Other than the ones you listed, you have to keep in mind ESMTP and
PIPELINING. If you are familiar with this here is a very quick overview.
Pipelining allows more than on command in a single 'packet' at certain
stages in the SMTP dialog, so as an example of use:
(slightly modified from the rfc 1830 example)
R = your server / S = remote client
R: <wait for connection on TCP port 25>
S: <open connection to server> <-client must wait for banner
R: 220 cnri.reston.va.us SMTP service ready <-CONN is a stop (delay here)
S: EHLO ymir.claremont.edu
R: 250-cnri.reston.va.us says hello <-client must wait for EHLO OK
R: 250-PIPELINING <-EHLO is a stop (delay here)
S: MAIL FROM:<ned@???> <-ALL MAIL and RCPT commands
S: RCPT TO:<gvaudre@???> <-can be given at the same time
S: RCPT TO:<jstewart@???> <-(do not delay here) as your
<-20s/RCPT will break things
<-as it will not do as you
<-think in a PIPELINING
<-connection.
R: 250 <ned@???>... Sender ok
R: 250 <gvaudre@???>... Recipient ok
R: 250 <jstewart@???>... Recipient ok
S: DATA <-client must wait for DATA OK
R: 354 OK Send data ending with . <-DATA is a stop
S: <sends message>
R: 250 Message OK
S: QUIT
R: 221 Goodbye
So, as you can see, when PIPELINING is used, delays in the MAIL and RCPT
stages tend to be very bad form and will break or confuse most MTA software
by taking far too long to return the OK to the remote client/server.
This is why I personally do not use nor do I suggest that any 'delays'
should be used after the initial connection and HELO responses (delay not
deny/drop use those anytime :)
>
..[snip]...
>
> - Am I breaking any standards? (RFC2822, etc)
> (Yeah, I know, I'll RTFM one of these days).
>
Yes and no, you can/are breaking some very strongly suggested 'SHOULD'(s)
but when done selectivly, this is not normally a problem, and in my case,
I would only be breaking the rules on those that are already breaking the
rules to begin with.
>
> - My machine is not busy (perhaps the largest source of incoming
> mail is this very list), so I don't expect to be processing and
> stalling a whole slew of incoming SMTP connections at once - but is
> there a limit to how many fork()s the Exim daemon creates for
> processing incoming mails? Is that configurable?
>
>
yes... Here are some to look at:
change xxx to your needs, or in some cases 0 or 'null' for no limit.
#Set the maximum number of simultaneous inbound
# SMTP connections that are allowed
smtp_accept_max = xxx
#Set the maximum number of MAIL commands for a single
# SMTP connection
smtp_accept_max_per_connection = xxx
#Set the maximum number of simultaneous inbound
# SMTP connections allowed for a single host
smtp_accept_max_per_host = xxx
#Limit the number of delivery processess that
# are started when recieving via SMTP
smtp_accept_queue_per_connection = xxx
>
> Thanks for any replies!
>
You are welcome :)
>
..[snip]...
>
--
--EAL--
