Eric Rostetter wrote: > Quoting John Rudd <[EMAIL PROTECTED]>: > >> Tilman Schmidt wrote: >> >>> So why am I dissecting that list like this? Just to show that blocking >>> or not blocking certain unusal characters in mail addresses is indeed a >>> policy decision which should not be forced by a piece of software, >>> but at >>> most offered as a configurable option. >> >> Absolutely agree. > > I disagree in this case (read on). > >> It is not ClamAV's place to make policy decisions for >> me. > > And ClamAV does not. The milter is. And the milter is designed to > work with sendmail. And if leaving this enabled by default produces > an exploitable sendmail, then it is wrong.
It does not. What leaves an exploitable sendmail is a poorly configured sendmail. The problem is already fixed, and properly fixed, in sendmail's own configs. This makes it "the wrong tool for the job". Adding this to the milter is adding code to "fix something that isn't broken". It is never good to be "the wrong tool for the job", nor "fixing something that isn't broken". And, therefore, it is doubly bad to be both. Further, it imposes this fix upon mailers that don't have a vulnerability (keeping in mind that other MTAs can use milters now). That's three strikes*. (* yes, I know most of the readers here might not be in the US, nor familiar with baseball metaphors, but hopefully they'll get that three strikes is a threshold of disqualification) > I'm not saying it can't be configurable, but whether it is or not, it > must be disabled by default, IIF it is known to make sendmail or the > milter itself exploitable. That would be true if and only if the proper fix didn't already exist within sendmail itself. (and I don't recall if it's the default in sendmail, or not ... but that doesn't matter, because the PROPER FIX is to use the sendmail config which stops the exploit ... that proper fix might be as simple as "do nothing", if it IS the default) >> At most, it >> should offer me policy options, but only _options_. > > You would rather it allows you to become exploitable? I wouldn't... Nice strawman. No, I wouldn't like to be exploitable. And, without this feature, I wouldn't be (not even if I was running sendmail), because the fix already exists within its proper location (within sendmail itself). > IMHO, the proper thing to do is to document this in the milter docs. > Whether it becomes a configurable option or not, it should certainly > be documented that the default is to block such addresses. No, the proper thing to do is not fix things that aren't broken. This is already fixed in the proper place. At the most, the ClamAV team, and/or the clamav-milter team, should provide a STRONG recommendation that the sendmail config should use its existing technique for fixing the problem (which may be as simple as "do nothing except don't overide the default"). > BUT, the point of my email is ClamAV is an anti-virus program, its jobs > is to match patterns and report the match. clamav-milter is a separate > program, a milter for sendmail. A milter is by definition a filter. It's > job IS to filter (see: https://www.sendmail.org/milter/), even though many > people use them in a non-filtering way... Don't confuse the two programs, > or their functions. Close, but not correct. Milters in general exist to provide general filtering capability. The clamav-milter is not a "general milter". It's a specific milter, whose specific purpose is to provide ClamAV capability via the milter interface. Your argument here would be valid if the clamav-milter were a general purpose milter, such as MIME-Defang. Or if it were a special purpose milter whose special purpose wasn't specifically "providing ClamAV via the milter interface". Again, it is providing a fix in the wrong location, and fixing something that isn't broken. > It would be irresponsible for a milter to knowingly allow a security hole > by default. Incorrect. It is irresponsible for a milter to allow a security hole IN THE AREA THAT THE MILTER ADDRESSES. The clamav-milter isn't a general security tool, it is a _ClamAV_ milter. By your logic, EVERY milter on the planet should waste its time doing EVERY security check known in order to be sure that not only is sendmail not mis-configured, but neither is every other milter in use. That's wasteful, poorly conceived, and just a plain bad idea. Use the right tool for the job. Fix the problem where the problem exists. The right tool for the job is the existing sendmail fix for the problem. The proper location of the fix is within the sendmail configuration. Not in EVERY milter on the system. Not in ANY milter on the system. > Protecting against such a hole is the only reasonable thing > to do. How to best protect that hole is still a subject of debate. No, it is not. The best protection for that hole already exists within sendmail. Fixing it within the clamav-milter is _STUPID_. _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
