Petr Novotny wrote:
>The only way for this attack to work is to talk to qmail on a
>secondary MX (and have primary MX generate 26 distinct
>bounces), but then the effect of the mailbomb is probably
>diminished by the (allegedly) poor line between secondary and
>primary (why would you care about secondary, otherwise?).
It's common practice for a non-primary mail server to be networkographically
close to a primary mail server. Often, a primary and one of its backups are
physically right next to each other. In other cases, a backup mail server
is provided by an upstream provider, hopefully, the link between a customer
and its upstream wouldn't be of low quality.
qmail-send's behavior for remote deliveries (which includes how it deals
with qmail-rspawn and qmail-remote) is something that's bothered me for a
while. The system really should manage remote deliveries better. At
present, we have one SMTP connection per remote address. This should at
least be modified to give one SMTP connection for each remote mail server
that needs to be contacted for any given message. The ideal case would
allow for a limited number of SMTP connections (to allow for parallel
delivery) to any remote host at any given time, and the capability to
transfer multiple messages in a single SMTP session.
I understand that qmail's structure makes this difficult, but I don't think
that it should be impossible.
>Yeah, sure. I mean, there is lot of other DoSes possible. Why
>would you care about too-many-emails? Is your computer really
>secured against any DoS possible (including DDoS), except
>mailbombing?
There's a difference between being the target of a denial-of-service attack
and being involved in one as a tool used by an attacker. As participants on
the public Internet, we have to be willing to acknowledge our own
susceptibility to being targets, and take measures to handle them as our
personal or organizational requirements dictate. We must not be willing to
promote abusive activities by knowingly supporting, directly or indirectly,
bad practices.
Mark
--
Do not reply directly to this e-mail address
--
Mark Mentovai
UNIX Engineer
Gillette Global Network
