* Paul Vixie: > hell, as long as we're making a list of the things sender-side network admins > should filter on their end since they're innappropriate for the wide area,
Technically, HTTP is inappropriate for wide-area networks. A lot of HTTP applications still do not support persistent connections (resulting in lots of unnecessary round trip delays). HTTP does not perform any checksums, and the TCP checksum alone is insufficient across the Internet (failures are rare, but when they happen, they are reproducible across the affected router). HTTP does not provide confidentiality. The frameworks usually used to build HTTP applications do not offer adequate security, and often encourage risky programming styles. Implementation quality is as poor as it can get. And so on. DNS is even worse, and thanks to DNSSEC, we will never see fixes for the most pressing issues. So "inappropriate" is the wrong word here, "you can filter it and you can get away with it" is closer to reality IMHO. > senders and sender-isp's have a long list of things they have to do in order > to not be compared to toxic polluters (a term i believe michael rathbun coined > for use in this context, and for which i am thankful.) But detection and response are more important than prevention. You cannot block 80/TCP bidirectionally, so there will always be a malware problem. At the moment, 25/TCP &c blocks are sufficient to outrun the competition, but this will change as such filters become more and more common. Blocks might be cheaper at this point, but I hope it's economically viable to skip this stage (because it's so disruptive and will only result in more SOAP lookalikes) and invest into the next one.