Re: [Exim] acl_smtp_predata

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Tony Finch
Ημερομηνία:  
Προς: Kjetil Torgrim Homme
Υ/ο: Tony Finch, exim-users
Αντικείμενο: Re: [Exim] acl_smtp_predata
On Fri, 16 Jul 2004, Kjetil Torgrim Homme wrote:
> On Thu, 2004-07-15 at 11:52 +0100, Tony Finch wrote:
> >
> > (1) [DATA] is a synchronization point. If PIPELINING is in operation
> > delaying in a RCPT ACL only delays, but a delay in a predata ACL would
> > probably be an effective ratware detector.
>
> 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. 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.

> > 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.

> > (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.

Good questions, thanks :-)

Tony.
--
f.a.n.finch <dot@???> http://dotat.at/
SOUTHEAST ICELAND: EASTERLY BACKING NORTHEASTERLY 4 OR 5. RAIN OR SHOWERS.
MODERATE OR GOOD &NBSP;.