David MacQuigg wrote:
Seems to me RFC-5321 could have said: The client MUST pause every
1000KB (or 100 seconds, whichever is less) and look for a REJECT.
Clients who fail to do this risk being blocked by a firewall.
What would be the point of this? A 'bad' client won't do this, and even
if you do send a reject and it does honour it, it will just start
sending data again, so - what's the point. Just block them at the
firewall anyway - not that that would help against a botnet.
(A much better 'solution' in RFC 5321 would have been to enforce the
SIZE extension, and allow the server to drop the connection if the
client sends more than 10% over the advertised size of the email - it
still wouldn't help in the bigger picture, but it might close this
unexploited loophole)
As I see it, you could somehow work out a protocol for telling something
that is sending you 5000 TB of data to 'stop it please', but (a) it
could ignore you or (b) it could stop, but then start again straight
away, so it sends you 10MB, then another 10MB, then another 10MB ad
disk-blow-upeum.
This can happen with pretty much any protocol anywhere.
It has to be handled by heuristics of some sort, or not handled at all -
in my experience serious DoS attacks are relatively rare, and if they
happen there's not a lot you can do at any one level to stop them.
Baddies seem to be more interested in using their botnets to send spam
or phish attacks or whatever - something which has financial gain.