On 25/12/04 03:08 +0000, gep2(_at_)terabites(_dot_)com wrote:
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.
I don't think I quite understand your point here.
A mail transaction typically goes like this:
<tcp connection> from high port to port 25 of the server
The server checks up the reverse DNS of the client.
S: 220 <server.hostname> [ESMTP]
C: HELO <client.hostname> (or EHLO for ESMTP)
S: 250 Ok
C: MAIL FROM:<sender(_at_)example(_dot_)com>
S: 250 Ok
C: RCPT TO:<recipient(_at_)example(_dot_)net>
S: 250 Ok
... (client adds more RCPT TOs here)
C: Data
S: 354 Send CRLF.CRLF to end
Message headers
Message Body
.
S: 250 Ok
quit
S: 221 Ok
<tcp connection teardown>
Now, you know the actual message size only after the data was sent. If
the client sends a ehlo, it may send a size value, but that cannot be
known to be correct. The message headers and body are part of the
message itself, as part as SMTP is concerned.
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.
This is more complex, but doable. A restrictions lookup table keys off
the recipient address, and
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).
Actually, this isn't known until delivery is attempted. No one needs to
have the mail storage system on the same server as the receiving MTA.
The complexity and fraility of trying to push quota overflow conditions
in realtime to external MTAs is bad enough that I would just allow for
bounces to be generated later.
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.
This requires a large amount of code to be pushed into MTAs. Parsing
text takes up CPU. Gobs of CPU. Just to show how much pre data filtering
can help (I wont quote names here, since I don't have permission to do
that yet):
A canadian ISP had 4 boxes handing 200K mails/day each on average, with
SpamAssassin filtering the content for suspicious mail. Note that this was
post recipient validation, with a few externsions filtered out
(exe/cpl/pif/.., the common viral vectors). SA was running on 9 boxes,
and those were barely able to keep up with the load (SA was daemonised).
By adding a single DNSBL (the cbl-sbl.spamhaus.org list), they reduced
the inflow to 80K mails/day per host on average, and need 6 SA boxes for
filtering comfortably.
I'll let you figure out the bandwidth and server savings, and the
administrative time saved on that (the admins had been trying for three
months at least to tune the SA boxes so that they would keep up).
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
When do you plan to show actual savings? There are no savings post DATA,
except the cost of putting that message in the temporary mailstore on
the server.
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
Have you considered that message may have more than one recipient, and
that enforcing different message sizes per recipient in the MTA is simply
not feasible (there is exactly one return value after data)?
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
It is? Not as fast as the spam volume is going up.
the added complexity of trying to be more clever, "too" early in the
process.
Devdas Bhagat
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg