Dan Melomedman: > > why? this "issue" is highly overrated. > > Well, okay, I spoke too soon. I guess he (Gunninsky?) did a good > job of FUDding this particular issue. Still would like to see > (eventually) in-between releases patches on the web. > > I am sure many would appreciate. Hunting for them on the mailing > list sucks.
I have sent him a patch, but he didnt open on the web yet. I also sent it to Security Focus, where you can find it my patch. http://www.securityfocus.com/bid/9432 But it is perfectly same to the one I have sent to this ML a few days before. Now I am interested in the way qmail-ldap will fix this bug. There are three ways of fixing. This bug is caused by a crazy long header line. candidate A - handle the long header line in silent and normal. the crazy mail will be rejected by 'databytes' limit afterward. if 'databytes' limit is not set, the mail will be delivered normally. (and another problem will apeear, such like "heavy or slow") B - treat the long header as an error. judging 'long' is done by comparing to a fixed number. qmail-smtpd rejects the message in the smtp session, whatever the 'databytes' limit is set. this style is similar to the way of limiting the hop count by djb. (defining MAXHOPS macro as 100) B'(dash) - treat the long header as an error. judging 'long' is done by a customizable number, such like contol/single_header_length_limit. the behaviour of qmail-smtpd is same to above case. I wrote a patch in the way of B. and the fixed number is decided by compile flag -DMAXHEADERLENGTH=nnnn. the default value is 1000, as rfc2821 said roughly. B' is not implement-worthy. A is easy to implement/modify, but the effect is few. Junjiro Okajima
