Re: Reject before DNS resolution

7 msg	Alternative SMTP port
4 msg	regexp sender_bcc map not working
14 msg	rDNS checks cause delays
4 msg	Question regarding parallelism in smtpd_recipie...

Reject before DNS resolution
\ Robert Felber (31 Aug 2007)
. \ (Wietse Venema) (31 Aug 2007)
. . \ Robert Felber (31 Aug 2007)
. . . \ (Wietse Venema) (31 Aug 2007)
. \ Erwan David (31 Aug 2007)
. . \ Justin Piszcz (31 Aug 2007)
. . \ Robert Felber (31 Aug 2007)

5 msg	postfix/pick: warning maildrop/foo: permission ...
4 msg	unknown or not unknown? canonical name-resolution
3 msg	Authenticating users from specific group in LDAP
15 msg	is zen.spamhaus.org down ?
2 msg	postfix relay mantainig the domain
4 msg	transport_maps and mailbox
10 msg	inet_interfaces: no local interface found for
3 msg	Per user relaying rules
2 msg	postfix blocking relay
2 msg	Relay host question
4 msg	SMTP Diagnostics
3 msg	how to get pickup/cleanup messages into policy ...
4 msg	Need to relay some, deliver others
5 msg	SASL and postfix problem: no applicable SASL me...
5 msg	Closing SMTP connection immediately on blacklis...

Subject:	Re: Reject before DNS resolution
Group:	Postfix-users
From:	(Wietse Venema)
Date:	31 Aug 2007

Robert Felber:
> On Fri, Aug 31, 2007 at 10:25:00AM -0400, Wietse Venema wrote:
> > Robert Felber:
> > > Hello,
> > >
> > > I'm not certain, but is it possible to reject (5xx) and close()
> > > a client without postfix doing DNS lookups (reverse/forward) etc.
> > >
> > > Something like smtpd_ip_restrictions comes to mind.
> > > Currently I assume that at smtpd_client_restrictions still a PTR/A
> > > lookup is done.
> >
> > That gets too messy.
>
> How about
>
> a) smtpd threading (not really a solution) or
> b) smtpd multiplexing (SMTP/DNS/other protos)

Sorry, not going to overhaul Postfix for every spam problem. By
the time people get to deploy the result on their L*nux box, the
code would be two years behind anyway.

> Both would mean deep changes and opening a can of worms, though.
> After all the current design is a vector for a process DDoS (i.e. smtpd
> tarpitting via slow/unresponsive authoritive DNS servers).

The solution IMHO is to implement a front end daemon that accepts
connections, and that pass the good ones to Postfix smtpd processes.

There is already almost finished code in the Postfix master that
can be used to pass open connections from a front-end daemon into
Postfix smtpd processes.

> (I face this problem myself and see the challenge to implement
> smtpd(policy proto)/DNS multiplexing for policyd-weight).

If the front-end daemon were to support a Postfix policy protocol,
then the available information would almost certainly be limited
to the client name and IP address. To collect more information,
the front-end would have to proxy connections, and that is much
more expensive than merely passing an open connection from front-end
to smtpd.

Wietse