On Fri, 2004-07-16 at 11:49 +0100, Tony Finch wrote:
> On Fri, 16 Jul 2004, Kjetil Torgrim Homme wrote:
> > hmm? the delays in RCPT ACLs are cumulative, you won't get a response
> > to DATA until they're all passed.
>
> Yes. However I don't see much point in teergrubing because the attackers
> have many more resources to play with than I do so I'll inevitably lose
> that battle.
alone, yes, but this is becoming more widespread.
> Just a brief delay at an appropriate point to ensure that
> they are using a competent implementation of the protocol is enough.
> I also believe in code saying what I mean, and it would be an ugly hack to
> ensure only one RCPT ACL delay happened for each message.
ugliness is in the eye of the beholder, I guess. in RCPT ACL:
warn condition = ${if eq {$rcpt_count}{1}{yes}{no}}
delay = 5s
this does assume that receiving the complete set of recipients takes
less than 5 seconds. you could do it unconditionally in the MAIL ACL,
too, with the same caveat. (rules out using callouts, for sure...)
> > > Another example is Exim's header_sender callouts, which are FROM:<> but
> > > the address may not be a valid bounce recipient address.
> >
> > I don't get it, isn't that the point? why would you accept these
> > addresses in RCPT TO and reject the DATA?
>
> This is a counterpart to the Postfix problem. Say I use signed envelope
> sender addresses, but my Sender: header is not signed -- according to RFC
> 822 the address in the Sender: header must be a valid recipient address.
> So valid bounces must have a signed address in the RCPT command, but if I
> send a message to a site that's using verify=header_sender/callout it'll
> look to me like a forged bounce. Therefore a workaround is needed, which
> is to accept the RCPT command and reject pre-data.
ouch, I didn't realise what header_sender/callout did, I read it as
simply sender/callout. TBH, I think it sounds quite broken :-)
you could accept any kind of e-mail to signed addresses, though. in
this mode it is more important to accept both the current and the
previous timestamp.
> > > (3) One of the tests we do in the RCPT ACL is to check if MailScanner is
> > > keeping up with the load and defer if it isn't. It'd be better to do this
> > > once at predata time.
> >
> > wouldn't the MAIL ACL work almost as well? sure, under load you'll
> > defer lots of spam in MAIL FROM rather than rejecting it in RCPT TO, but
> > I don't think that's a problem.
>
> The aim of doing this check very late is to reduce the disk load on the
> machine, which is the most scarce resource. Most spam rejections only
> require network resources.
I haven't checked the code, but I thought Exim started writing to the
queue file as soon as the transaction started. in any case, I don't see
how delaying the defer will reduce disk load, particularily considering
that most spammers won't bother to retry. if nothing else, recipient
verification will usually involve I/O, the exception being when you're
using an external database for all mailer tables.
--
Kjetil T.
