WebApp Sec mailing list archives
RE: Dropping connection instead of returning 400
From: christopher () baus net
Date: Thu, 3 Mar 2005 15:26:34 -0800 (PST)
Christopher, It seems like such a trivial measure that I don't think breaking the spec is worth it. You seem to be concerned about the information
returned... well just return less. Don't 'break the spec' for
something so trivial.
Doing this in accordance to the spec in a pipeline is a bit more complicated. I am working on a blog entry that explains some of the issues of proxying pipelines. The primarily problem is determining the number of requests you'll send to server before receiving a reply. Information needs to be buffered and queued in the proxy which is a potential area for overrun failures. This is not required by straight through proxies like stunnel. I'm going to implement this since everybody is so keen on this, but I'm going to continue make dropping connection optional. I talked this issue over with a friend of mine that works at an anti spam company, and they do exactly what I am proposing. If they determine the message is spam they drop connection immediately regardless of the SMTP spec. Also I see this as a similar to rejecting TCP/IP packets (ie dropping them) which is common in TCP/IP firewalls, but not as friendly as a denying them with a returned ICMP packet. Christopher Baus http://www.baus.net/
Current thread:
- Dropping connection instead of returning 400 christopher (Mar 03)
- Re: Dropping connection instead of returning 400 Mariusz Pękala (Mar 06)
- Re: Dropping connection instead of returning 400 Michel Arboi (Mar 06)
- <Possible follow-ups>
- RE: Dropping connection instead of returning 400 Michael Silk (Mar 06)
- RE: Dropping connection instead of returning 400 christopher (Mar 06)
- Re: Dropping connection instead of returning 400 Devdas Bhagat (Mar 09)
- Re: Dropping connection instead of returning 400 Garth Somerville (Mar 06)