address verification, smtpd_mumble_error_limit,smtpd_client_event_limit_exceptions
in [Postfix]
|
Prev: proxymap(8), number of connections, detecting altered tables
Next: address verification, smtpd_mumble_error_limit, smtpd_client_event_limit_exceptions
From: Stefan Foerster on 20 Jun 2010 18:31 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". Stefan
From: Stefan Foerster on 21 Jun 2010 05:09 * 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. Other than that, I cannot think of any scenario where this might become a real problem (it might confuse postmasters/admins who are not used to seeing a large number of mails with $address_verify_sender in their queues). It would still be nice to know whether smtpd_client_event_limit_exceptions will prevent the additional delays. Stefan
From: Stefan Foerster on 21 Jun 2010 09:42 * Stefan Foerster <cite+postfix-users(a)incertum.net>: > It would still be nice to know whether smtpd_client_event_limit_exceptions > will prevent the additional delays. NVM. This code in smtpd_chat.c, within smtpd_chat_reply, is executed without making any reference to smtpd_client_event_limit_exceptions: ,----[ smtpd_chat.c, smtpd_chat_reply ] | if (state->error_count >= var_smtpd_soft_erlim) | sleep(delay = var_smtpd_err_sleep); `---- Stefan
From: Stefan Foerster on 21 Jun 2010 09:52
* Wietse Venema <wietse(a)porcupine.org>: > Stefan Foerster: > > * Wietse Venema <wietse(a)porcupine.org>: > > > 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. Yes it can: Note how I wrote "yet unverified", implicating that there is no cache entry for the given recipient yet. Granted, this is an unlikely situation which should never be a problem (and there are several ways to deal with the original, hypothetical scenario anyways). Stefan > This is really basic engineering. > > Wietse |