There is clearly NO (local) solution for DDOS attacks, because by
the time they arrive at your entrance portal the damage has already
been done.
Available information before that point is limited. You can refuse to
accept the connection based on IP address, or you can accept the
connection tentatively and do some cheap lookups. Before the message
DATA arrives, you have three pieces of information: a HELO (or EHLO)
identification string, the MAIL and RCPT strings (There's also VRFY or
EXPN but keep it simple). Once the DATA command is used, the
connection is no longer cheap, because the data can be arbitrarily
long, and doing any sort of analysis on it will cost unpredictable
resources anyway. So discussing body analysis is irrelevant for this
problem.
Maybe, but HEADER analysis might be helpful.
After the receiving mail server has gotten the complete full header, then it
knows not only who the intended recipient is but also who the stated sender is,
and that could permit it to establish what that recipient's permissions are for
that sender... and SOME of those, at least, could perhaps be enforced during
the
time the incoming mail arrival is being done.
The easiest one to enforce is maximum allowed message size for that sender (or
default 'unknown' sender) since that one already has to be done anyhow if the
user's maximum inbox size is exceeded (and that isn't known, either, until too
much data comes in).
It's a little more complicated (but not HUGELY difficult) to have the receiving
server recognize message divisions and enforce (at least on a preliminary,
tentative basis) recipient permissions for attachments, HTML-burdened
attachments, and such.
But (although there is a potential cost savings from truncating such mails
earlier in the process, before they have been fully transferred) there is a
downside which may override the potential savings... and that is the
recipient's
desire to be able to change their mind upon considering the "spam" filtering
decision... it's harder to do that, and go ahead and approve the message for
delivery (and possibly revising the filtering rules for that sender), if in
fact
it was blocked or the server connection was dropped during transfer. It may be
that the bandwidth cost (and that's ultimately getting cheaper and cheaper) is
simply less costly than the added complexity of trying to be more clever, "too"
early in the process.
Gordon Peterson http://personal.terabites.com/
1977-2002 Twenty-fifth anniversary year of Local Area Networking!
Support free and fair US elections! http://stickers.defend-democracy.org
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg