From: Wietse Venema on
Stefan Foerster:
> This is - again - not a problem report but a mere theoretical
> question. Given two Postfix servers, one (called "gate") accepting
> connections from the internet, with example.com in $relay_domains and
> address verification enabled forwarding mails for verified recipients
> to the second server (called "hub").
>
> If "gate" is hit by a dicitionary attack, enumerating a few hundre
> thousands of localparts within the example.com domain, it will
> dutifully try to verify each of those against "hub". With connection
> caching enabled, multiple of those probes will be done using the same
> connection from "gate" to "hub".
>
> What happens after "gate" has tried to validate more than
> "$smtpd_soft_error_limit" invalid recipients? Will it be slowed down?
> Is it possible to exclude "gate" from that artificial slowdown on
> "hub" using smtpd_client_event_limit_exceptions?
>
> Disclaimer/for the archive: In cases like that, it's probably much
> better to provide a list of valid recipients to "gate".

Tarpit delays by the hub will slow down the dictionary attack.
Is that a problem?

Wietse

From: Wietse Venema on
Stefan Foerster:
> * Wietse Venema <wietse(a)porcupine.org>:
> > Stefan Foerster:
> > > What happens after "gate" has tried to validate more than
> > > "$smtpd_soft_error_limit" invalid recipients? Will it be slowed down?
> > > Is it possible to exclude "gate" from that artificial slowdown on
> > > "hub" using smtpd_client_event_limit_exceptions?
> > >
> > > Disclaimer/for the archive: In cases like that, it's probably much
> > > better to provide a list of valid recipients to "gate".
> >
> > Tarpit delays by the hub will slow down the dictionary attack.
> > Is that a problem?
>
> It can delay legitimate mail with yet unverified recipients, but
> that's pretty much what one would suspect during a dictionary attack.

No, it does not. The documentation recommends that address verify
lookup results are cached, so they are not delayed. Postfix will
refresh these cache entries well before they expire to avoid loss
of service when the back-end host is down or slow.

This is really basic engineering.

Wietse