Re: [Clamav-users] WARNING: Suspicious recipient address blocked
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
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Eric Rostetter schrieb: Quoting John Rudd [EMAIL PROTECTED]: It is not ClamAV's place to make policy decisions for me. And ClamAV does not. The milter is. That distinction is immaterial. The milter comes as part of the ClamAV package. s/ClamAV/clamav-milter/ throughout my posting if you want, it doesn't change my argument in any way. And the milter is designed to work with sendmail. And if leaving this enabled by default produces an exploitable sendmail, then it is wrong. The premise of this implication is false, therefore the conclusion doesn't follow. Passing E-mail addresses containing shell metacharacters does not produce an exploitable sendmail. It is ClamAV's place to match email messages to signatures. Yes, but this is _not_ the function of the milter, it is the function of ClamAV, and ClamAV is not the thing causing the issue, the milter is. Ok, since a simple s/ClamAV/clamav-milter/ probably won't cut it in this case, I'll rephrase that statement: It is clamav-milter's place to pass messages to clamd for matching them to signatures. At most, it should offer me policy options, but only _options_. You would rather it allows you to become exploitable? I wouldn't... Most programs allow you to become exploitable. It is always up to you to configure them so that this doesn't happen. Programs that *make* you exploitable are the problem, but a hypothetical clamav-milter that wouldn't block mail addresses containing vertical bar or semicolon characters does not fall into that category. 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. That would have been the minimum. But it is still wrong for a milter whose advertised purpose is to pass messages to a virus scanner, to start blocking messages based on unrelated criteria like allegedly illegal characters in addresses. 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. Ok, point taken. Consider them unconfused. Now please let us discuss the clamav-milter program, distributed with ClamAV but separate from it, and how it should behave with respect to the recipient addresses of the mails it processes. My position is still that checking the legality of those is not its job and it should leave them alone. It would be irresponsible for a milter to knowingly allow a security hole by default. Protecting against such a hole is the only reasonable thing to do. How to best protect that hole is still a subject of debate. Clamav-milter cannot protect my mail server against all possible security holes, and shouldn't even try. It has a precise job, which is to check mails for known viruses by passing them to ClamAV, and block their delivery if the check comes back positive. Other security risks must be covered by other means. Thanks, Tilman signature.asc Description: OpenPGP digital signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
John Rudd wrote: 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. In general: DO NOT HARDCODE POLICY Otherwise, your tool becomes irritating or possibly even harmful. Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Quoting John Rudd [EMAIL PROTECTED]: 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. I don't know the history of this expliot, etc. So I can't comment on whether the fix should stay or not. It would depend on the default settings for sendmail, how long the fix has been in sendmail, how widely available the patched sendmail is today, etc. Adding this to the milter is adding code to fix something that isn't broken. I would assume it was added at a time when it was broken (or was broken in the default install, etc). You might argue that it is no longer needed and should be removed, but that is a different argument, and as stated above it depends on knowledge of the history of the problems, history which I don't know so I can't make an informed decision on the matter. Further, it imposes this fix upon mailers that don't have a vulnerability (keeping in mind that other MTAs can use milters now). If the milter is designed for sendmail (this one was, as all older ones were) then their first duty is to sendmail, not to others who later decide to use them... Also, there may be other mailers who use milters who are also vulnerable besides sendmail, etc. So I see this point as moot. 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. But, is it widely deployed? If not, then the removal now might be premature (though making it configurable would certainly be within reason in that case). There is a reason I used IIF and it is because I don't know the history well enough to make absolute statements the way you do (without anything but your opinions to back them up). (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) I beg to differ. If it isn't secure by default in sendmail, then it is reasonable for the milter to enforce it. (It is also reasonable for the milter to make it conditional, and/or for the milter to simply document the problem and warn users to fix their sendmail configurations). What is done it up to the author, not a particular end-user. (Though the author may find he has more end-users if he listens to their advice...) 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. Why thanks! :) 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). But only if it is implemented in sendmail, etc... And while you may be the perfect admin, many admins are not, and might overlook the problem and be exploitable because it. Or the fix in the milter might even have pre-dated the fix in sendmail, or the documentation in the sendmail docs on how to properly secure it, which would leave people vulnerable. Again, I don't know the history, so... 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). I agree that the above is a suitable thing to do (document the issue). But that assumes that it was fixed in sendmail before the code was added, and that if it was fixed later the team knew this and had time to go back and remove it and fix the docs, etc. Again, I don't know the history, so... 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. Clamav-milter is a filter for sendmail(1) mail server. It uses a mail scanning engine built into clamd(8). Read into that what you like... Again, it is providing a fix in the wrong location, and fixing something that isn't broken. Again, I don't know the history, so I can't comment. 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. I disagree. The keyword of course is knowingly. Your opinion may vary. The
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Quoting Tilman Schmidt [EMAIL PROTECTED]: That distinction is immaterial. The milter comes as part of the ClamAV package. s/ClamAV/clamav-milter/ throughout my posting if you want, it doesn't change my argument in any way. I think it completely changes your argument. Had you done that in the first place, I never would have replied in fact. And the milter is designed to work with sendmail. And if leaving this enabled by default produces an exploitable sendmail, then it is wrong. The premise of this implication is false, therefore the conclusion doesn't follow. Passing E-mail addresses containing shell metacharacters does not produce an exploitable sendmail. Okay, so poor wording on my part. Sorry. It is clamav-milter's place to pass messages to clamd for matching them to signatures. How about: It is clamav-milter's place to pass messages to clamd for matching them to signatures in a safe and secure manor. Most programs allow you to become exploitable. It is always up to you to configure them so that this doesn't happen. And if it is not possible to configure it to do so? 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. That would have been the minimum. Yes, I can agree with that. But it is still wrong for a milter whose advertised purpose is to pass messages to a virus scanner, to start blocking messages based on unrelated criteria like allegedly illegal characters in addresses. In that case, most all of the milters I have used or considered for use are wrong. So clamav-milter is at least in good company. :) Ok, point taken. Consider them unconfused. Now please let us discuss the clamav-milter program, distributed with ClamAV but separate from it, and how it should behave with respect to the recipient addresses of the mails it processes. My position is still that checking the legality of those is not its job and it should leave them alone. My opionion is that if possible, without causing harm, it should do as you say. If doing so causes harm, then it must work to remedy that somehow. It would be irresponsible for a milter to knowingly allow a security hole by default. Protecting against such a hole is the only reasonable thing to do. How to best protect that hole is still a subject of debate. Clamav-milter cannot protect my mail server against all possible security holes, and shouldn't even try. I only think there is an obligation if the problem is a known problem, and there is no other known fix. It has a precise job, which is to check mails for known viruses by passing them to ClamAV, and block their delivery if the check comes back positive. Other security risks must be covered by other means. Well, we disagree on that point. It is a security tool, and as such has an even greater burden to try to be as secure as possible. Even without that, all programs should strive to be as safe as possible, and to avoid known security issues. That is all they were trying to do: avoid a known security issue. Did they do that the best way possible? Probably not. But should they not have done anything at all? Certainly not! Thanks, Tilman -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Quoting David F. Skoll [EMAIL PROTECTED]: In general: DO NOT HARDCODE POLICY Otherwise, your tool becomes irritating or possibly even harmful. In general, don't distribute code that allows remote root exploit of systems. Otherwise, your tool becomes irritating or possibly even harmful. Regards, David. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Eric Rostetter wrote: Quoting David F. Skoll [EMAIL PROTECTED]: In general: DO NOT HARDCODE POLICY Otherwise, your tool becomes irritating or possibly even harmful. In general, don't distribute code that allows remote root exploit of systems. Otherwise, your tool becomes irritating or possibly even harmful. Yikes! I guess that rules out shipping a c compiler! (and a lot of other general purpose tools as well) Joe ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
At 14:42 17-04-2008, Eric Rostetter wrote: I don't know the history of this expliot, etc. So I can't comment on whether the fix should stay or not. It would depend on the default settings for sendmail, how long the fix has been in sendmail, how widely available the patched sendmail is today, etc. Do you know which version of sendmail can be used with the milter? If the exploit is prior to that, then the fix may not be applicable. At 14:54 17-04-2008, Eric Rostetter wrote: Well, we disagree on that point. It is a security tool, and as such has an even greater burden to try to be as secure as possible. Even If you are using the milter as a security tool, you would have to do more filtering than what's currently implemented to prevent problems downstream. Regards, -sm ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Quoting SM [EMAIL PROTECTED]: At 14:42 17-04-2008, Eric Rostetter wrote: I don't know the history of this expliot, etc. Do you know which version of sendmail can be used with the milter? If the exploit is prior to that, then the fix may not be applicable. I never argued otherwise. And no, as I've said, I don't know the history, so no I don't know the versions involved. And yes, I've used poor wording twice now. For all I know, from what _little_ I know, the problem is in the popen() call in the milter, and not in the sendmail at the other end at all. How would I know? I have not, and probably will not, take the time to investigate this. For the record: I don't agree with the solution either. But I certainly don't agree that they should have done nothing! Don't paint me as a supporter for the way it was done. I'd have done it differently. But I sure wouldn't leave it exploitable just because I was afraid of forcing policy on someone. (Yes, I would have documented it, but I wouldn't have just ignored the problem...) -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Eric Rostetter wrote: In general, don't distribute code that allows remote root exploit of systems. Sendmail doesn't allow remote exploit due to recipient addresses with funny characters in them. It certainly hasn't since Milter has been around, so fixing the problem in a milter is dumb. Otherwise, your tool becomes irritating or possibly even harmful. Using one tool to fix the deficiencies in another tool is bad security... oh... wait a minute... that's the basis of the entire virus-scanning industry. :-( How sad. Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Eric Rostetter wrote: For all I know, from what _little_ I know, the problem is in the popen() call in the milter, Yikes popen() In a piece of SECURITY software??? I'm very glad I've never used Clam's milter. Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Eric Rostetter wrote: Well, we disagree on that point. It is a security tool, and as such has an even greater burden to try to be as secure as possible. In order for a security tool to be as secure as possible, it first of all needs to adhere to this basic principle: The tool behaves as advertised. Unless the behaviour with weird recipient addresses was prominently advertised, then it's surprising behaviour, and surprising behaviour is the enemy of security. Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Quoting David F. Skoll [EMAIL PROTECTED]: Unless the behaviour with weird recipient addresses was prominently advertised, then it's surprising behaviour, and surprising behaviour is the enemy of security. As I said in almost every message so far, yes, it should have been documented. Couldn't agree more... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Quoting David F. Skoll [EMAIL PROTECTED]: Sendmail doesn't allow remote exploit due to recipient addresses with funny characters in them. It certainly hasn't since Milter has been around, so fixing the problem in a milter is dumb. Not if the problem is in the milter, or in the shell between the milter and sendmail via popen(), or not fixable in some other way... But certainly if the milter is rejecting valid email addresses, that should be documented prominately at a minimum. I'd say no excuse for that... Otherwise, your tool becomes irritating or possibly even harmful. Using one tool to fix the deficiencies in another tool is bad security... oh... wait a minute... that's the basis of the entire virus-scanning industry. :-( Finally, a reply to my messages that I can appreciate. :) -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
On Thu, Apr 17, 2008 at 09:10:45PM -0400, David F. Skoll wrote: Eric Rostetter wrote: For all I know, from what _little_ I know, the problem is in the popen() call in the milter, Yikes popen() In a piece of SECURITY software??? I'm very glad I've never used Clam's milter. Not directly meant at David, but could you all please stop this crap and open a bug. Continue there please. Thank you. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Dave Warren wrote: In message [EMAIL PROTECTED] Stephen Gran [EMAIL PROTECTED] wrote: On Mon, Apr 14, 2008 at 05:22:56PM +0200, Bas van Rooijen said: postfix would accept all three forms even and why not ?? I assume you haven't looked at sendmail's security record. I, for one, have made it a point to not care. This has been a pretty standard thing to do for a long time, and with even more characters than the milter currently uses. Can we get any email address banned in clamav just because at least one software package has an associated exploit? Especially when that exploit is easily, and MORE APPROPRIATELY, plugged in the software package itself, instead of acting as a potential bloating-agent in ClamAV? ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
On 4/15/08 5:09 PM, John Rudd [EMAIL PROTECTED] wrote: 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. It is not ClamAV's place to make policy decisions for me. It is ClamAV's place to match email messages to signatures. It is up to me what to do with messages that match signatures. At most, it should offer me policy options, but only _options_. Also agree. It seems to me that this sort of policy is better placed outside the virus scanner (unless the scanner is protecting itself). Just as another data point, Exim (as of 4.69) ships with these rules in the default configuration. There is considerably more discussion of the reasons, including noting that most of the characters are indeed legal in addresses. Oddly, the sequence .. Is not allowed per RFC although Exim allows it because Philip encountered it, but he did then do extra work to block /../ 1. For incoming mail (addressed to an address local to the installation) # The rule blocks # local parts that begin with a dot or contain @ % ! / or |. If you have # local accounts that include these characters, you will have to modify # this rule. (And indeed when the listed characters except leading dot were blocked for all messages in an earlier Exim version, we had to remove the % for submissions as one of our users needed to send to such an address.) 2. For outgoing mail # This rule allows your own users to send outgoing # messages to sites that use slashes and vertical bars in their local # parts. It blocks local parts that begin with a dot, slash, or vertical # bar, but allows these characters within the local part. However, the # sequence /../ is barred. The use of @ % and ! is blocked, as before. # The motivation here is to prevent your users (or your users' viruses) # from mounting certain kinds of attack on remote sites. --John ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
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. 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. It is ClamAV's place to match email messages to signatures. Yes, but this is _not_ the function of the milter, it is the function of ClamAV, and ClamAV is not the thing causing the issue, the milter is. It is up to me what to do with messages that match signatures. Correct, and not of any concern to the actual discussion, despite the fact that some people believe it is. At most, it should offer me policy options, but only _options_. You would rather it allows you to become exploitable? I wouldn't... 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. 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. It would be irresponsible for a milter to knowingly allow a security hole by default. Protecting against such a hole is the only reasonable thing to do. How to best protect that hole is still a subject of debate. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 14.04.2008 16:30 schrieb Michael Brown: The | character is not allowed in any e-mail address because it's a Unix shell reserved character. RFC 2822 disagrees with you. To begin with, there's no reason reserved characters of any Unix shell or other program should be disallowed in E-mail addresses. Here's a list right off the top of my head that are usually blocked/disabled by just about every MTA out there. 1. Control Characters 23. DEL Ok. These are indeed illegal by the RFCs. 2. Space Not true. Valid E-mail addresses containing spaces do exist, although their owners may have a hard time getting mails from some parts of the 'net. 3. ! 16. 17. 18. @ (when used more than once) 19. [ 20. \ 21. ] Ok in a way. These are special characters for the mail transport itself (as opposed to some application program or shell) - though only historically in the case of the exclamation mark - and are therefore better avoided. Mail addresses containing one of these in the local part (ie. before the last @) will indeed rarely go through. 4. Not true. In fact, any mail server I know of accepts mail addresses whose local part is enclosed in double quotes just fine. 5. # 6. $ 7. % 8. 12. , 13. / 14. : 15. ; Not true. I have already seen every one of these characters in valid E-mail addresses in the wild, and blocking them does generate complaints. (btdt) 9. ( 10. ) 11. * 22. | Not true either. While these are indeed rare, and may cause problems with buggy and/or misconfigured mail software, they are legal by RFC 2822, and blocking them is a policy decision which is far from unanimity. There are many mailservers which will indeed accept these. 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. HTH T. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3rc1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIBTZlQ3+did9BuFsRAghXAKCYhBT45TH06hR8DWrB46WnzjDLpACglrgK MF3dKKZBUSnc+AmkDSg78z0= =BX/w -END PGP SIGNATURE- ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Your dissecting my personal experience which makes all your points, while valid, moot for my experience. :-) Tilman Schmidt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 14.04.2008 16:30 schrieb Michael Brown: The | character is not allowed in any e-mail address because it's a Unix shell reserved character. RFC 2822 disagrees with you. To begin with, there's no reason reserved characters of any Unix shell or other program should be disallowed in E-mail addresses. Here's a list right off the top of my head that are usually blocked/disabled by just about every MTA out there. 1. Control Characters 23. DEL Ok. These are indeed illegal by the RFCs. 2. Space Not true. Valid E-mail addresses containing spaces do exist, although their owners may have a hard time getting mails from some parts of the 'net. 3. ! 16. 17. 18. @ (when used more than once) 19. [ 20. \ 21. ] Ok in a way. These are special characters for the mail transport itself (as opposed to some application program or shell) - though only historically in the case of the exclamation mark - and are therefore better avoided. Mail addresses containing one of these in the local part (ie. before the last @) will indeed rarely go through. 4. Not true. In fact, any mail server I know of accepts mail addresses whose local part is enclosed in double quotes just fine. 5. # 6. $ 7. % 8. 12. , 13. / 14. : 15. ; Not true. I have already seen every one of these characters in valid E-mail addresses in the wild, and blocking them does generate complaints. (btdt) 9. ( 10. ) 11. * 22. | Not true either. While these are indeed rare, and may cause problems with buggy and/or misconfigured mail software, they are legal by RFC 2822, and blocking them is a policy decision which is far from unanimity. There are many mailservers which will indeed accept these. 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. HTH T. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3rc1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIBTZlQ3+did9BuFsRAghXAKCYhBT45TH06hR8DWrB46WnzjDLpACglrgK MF3dKKZBUSnc+AmkDSg78z0= =BX/w -END PGP SIGNATURE- ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
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. It is not ClamAV's place to make policy decisions for me. It is ClamAV's place to match email messages to signatures. It is up to me what to do with messages that match signatures. At most, it should offer me policy options, but only _options_. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
In message [EMAIL PROTECTED] Stephen Gran [EMAIL PROTECTED] wrote: On Mon, Apr 14, 2008 at 05:22:56PM +0200, Bas van Rooijen said: postfix would accept all three forms even and why not ?? I assume you haven't looked at sendmail's security record. I, for one, have made it a point to not care. This has been a pretty standard thing to do for a long time, and with even more characters than the milter currently uses. Can we get any email address banned in clamav just because at least one software package has an associated exploit? -- Dave Warren, [EMAIL PROTECTED] Office: (403) 775-1700 / (888) 300-3480 ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
On Mon, Apr 14, 2008 at 11:09 AM, Bas van Rooijen [EMAIL PROTECTED] wrote: ClamAV is rejecting messages where the recipient address contains a | (pipe character).. Why is this? Is | a virus now? Can this behaviour be disabled? Are you planning on blocking other random characters from appearing in the recipient adres? Are you certain that clamav is behind this? What other software are you using with your mailserver and exactly what is the error message? -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] WARNING: Suspicious recipient address blocked
ClamAV is rejecting messages where the recipient address contains a | (pipe character).. Why is this? Is | a virus now? Can this behaviour be disabled? Are you planning on blocking other random characters from appearing in the recipient adres? thanks, bvr. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Rob MacGregor wrote: On Mon, Apr 14, 2008 at 11:09 AM, Bas van Rooijen [EMAIL PROTECTED] wrote: ClamAV is rejecting messages where the recipient address contains a | (pipe character).. Why is this? Is | a virus now? Can this behaviour be disabled? Are you planning on blocking other random characters from appearing in the recipient adres? Are you certain that clamav is behind this? What other software are you using with your mailserver and exactly what is the error message? Yes. I'm certain ClamAV is behind it; we're using postfix with ClamAV-milter, - the message immediately rejected with the same error message, - the message is also written to the clamav.log, - if you google for the error a short discussion will come up from this lists' archive - you can check it easily by trying to send a message with a recipient containing | through a clamav server of choice the error message is exactly 'WARNING: Suspicious recipient address blocked: ' followed by the address in question, i've tried a number of addresses manually but anything containing | has the same problem. PS. this behaviour didn't occur with the debian-stable version (0.90.1dfsg-3etch10) which has other problems, this problem started appearing when we upgraded to the debian-volatile version (0.92.1~dfsg-1volatile1) ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
* Bas van Rooijen [EMAIL PROTECTED]: Yes. I'm certain ClamAV is behind it; we're using postfix with ClamAV-milter, - the message immediately rejected with the same error message, - the message is also written to the clamav.log, - if you google for the error a short discussion will come up from this lists' archive - you can check it easily by trying to send a message with a recipient containing | through a clamav server of choice the error message is exactly 'WARNING: Suspicious recipient address blocked: ' followed by the address in question, i've tried a number of addresses manually but anything containing | has the same problem. Please do show the logs. -- Ralf Hildebrandt (i.A. des IT-Zentrums) [EMAIL PROTECTED] Charite - Universitätsmedizin BerlinTel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-BerlinFax. +49 (0)30-450 570-962 IT-Zentrum Standort CBF send no mail to [EMAIL PROTECTED] ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
On Mon, Apr 14, 2008 at 11:55:08AM +0100, Rob MacGregor wrote:
On Mon, Apr 14, 2008 at 11:09 AM, Bas van Rooijen
[EMAIL PROTECTED] wrote:
ClamAV is rejecting messages where the recipient address contains a |
(pipe character)..
Why is this? Is | a virus now?
Can this behaviour be disabled?
Are you planning on blocking other random characters from appearing in the
recipient adres?
Are you certain that clamav is behind this? What other software are
you using with your mailserver and exactly what is the error message?
It took 2 seconds to grep ClamAV sources..
clamav-milter.c
if(strchr(|;, *ptr) != NULL) {
smfi_setreply(ctx, 554, 5.7.1, _(Suspicious recipient address blocked));
Yes it seems | and ; are blocked.
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Mon Apr 14 13:07:57 2008 - WARNING: Suspicious recipient address blocked: 'test|[EMAIL PROTECTED]' Ralf Hildebrandt wrote: * Bas van Rooijen [EMAIL PROTECTED]: Yes. I'm certain ClamAV is behind it; we're using postfix with ClamAV-milter, - the message immediately rejected with the same error message, - the message is also written to the clamav.log, - if you google for the error a short discussion will come up from this lists' archive - you can check it easily by trying to send a message with a recipient containing | through a clamav server of choice the error message is exactly 'WARNING: Suspicious recipient address blocked: ' followed by the address in question, i've tried a number of addresses manually but anything containing | has the same problem. Please do show the logs. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
On Mon, Apr 14, 2008 at 11:09 AM, Bas van Rooijen [EMAIL PROTECTED] wrote: ClamAV is rejecting messages where the recipient address contains a | (pipe character).. Why is this? Is | a virus now? Can this behaviour be disabled? Are you planning on blocking other random characters from appearing in the recipient adres? Thanks for the replies so far; however please note I already know the problem is ClamAV (hence i'm writing to this list..) Is there anyone who can answer my actual questions? greets, bvr. Are you certain that clamav is behind this? What other software are you using with your mailserver and exactly what is the error message? Please do show the logs. Yes it seems | and ; are blocked. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Bas van Rooijen wrote: Thanks for the replies so far; however please note I already know the problem is ClamAV (hence i'm writing to this list..) Is there anyone who can answer my actual questions? Comment out the check in the source and recompile? ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
[EMAIL PROTECTED] wrote: Bas van Rooijen wrote: Thanks for the replies so far; however please note I already know the problem is ClamAV (hence i'm writing to this list..) Is there anyone who can answer my actual questions? Comment out the check in the source and recompile? That check was added to prevent an exploit when run in black-hole mode. Best regards, --Edwin ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Török Edwin wrote: [EMAIL PROTECTED] wrote: Bas van Rooijen wrote: Thanks for the replies so far; however please note I already know the problem is ClamAV (hence i'm writing to this list..) Is there anyone who can answer my actual questions? Comment out the check in the source and recompile? That check was added to prevent an exploit when run in black-hole mode. Then maybe it should only be active when run in black-hole mode? (maybe it is, I don't know if that applies to the OP). At the very least, shouldn't it have a config switch? ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
John Rudd wrote: Török Edwin wrote: [EMAIL PROTECTED] wrote: Bas van Rooijen wrote: Thanks for the replies so far; however please note I already know the problem is ClamAV (hence i'm writing to this list..) Is there anyone who can answer my actual questions? Comment out the check in the source and recompile? That check was added to prevent an exploit when run in black-hole mode. Then maybe it should only be active when run in black-hole mode? (maybe it is, I don't know if that applies to the OP). At the very least, shouldn't it have a config switch? Please open a bugreport if you need to accept email with |. --Edwin ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
John Rudd wrote: Török Edwin wrote: [EMAIL PROTECTED] wrote: Bas van Rooijen wrote: Thanks for the replies so far; however please note I already know the problem is ClamAV (hence i'm writing to this list..) Is there anyone who can answer my actual questions? Comment out the check in the source and recompile? That check was added to prevent an exploit when run in black-hole mode. does this mean you can still exploit these by using other meta characters? like and ? wouldn't it make more sense to properly escape the recipient where it is actually passed to sendmail? Then maybe it should only be active when run in black-hole mode? (maybe it is, I don't know if that applies to the OP). At the very least, shouldn't it have a config switch? ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
It took 2 seconds to grep ClamAV sources..
clamav-milter.c
if(strchr(|;, *ptr) != NULL) {
smfi_setreply(ctx, 554, 5.7.1, _(Suspicious recipient address blocked));
Yes it seems | and ; are blocked.
The | character might be used to expolit SMTP servers. It has no valid place
in an email address.
It is not a virus, probably spam, and/or an attempt to compromise the SMTP
server.
At your service,
-bryan bradsby
Postmaster
Texas State Government Net
NOC: 512-475-2432 877-472-4848
If user education worked, it would have worked by now
- Peter Gutmann, the Psychology of Insecurity
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
The | character is not allowed in any e-mail address because it's a Unix shell reserved character. Here's a list right off the top of my head that are usually blocked/disabled by just about every MTA out there. 1. Control Characters 2. Space 3. ! 4. 5. # 6. $ 7. % 8. 9. ( 10. ) 11. * 12. , 13. / 14. : 15. ; 16. 17. 18. @ (when used more than once) 19. [ 20. \ 21. ] 22. | 23. DEL Bas van Rooijen wrote: ClamAV is rejecting messages where the recipient address contains a | (pipe character).. Why is this? Is | a virus now? Can this behaviour be disabled? Are you planning on blocking other random characters from appearing in the recipient adres? thanks, bvr. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
On Mon, 14 Apr 2008, Michael Brown wrote:
The | character is not allowed in any e-mail address because it's a Unix
shell reserved character.
Here's a list right off the top of my head that are usually
blocked/disabled by just about every MTA out there.
1. Control Characters
2. Space
3. !
4.
5. #
6. $
7. %
8.
9. (
10. )
11. *
12. ,
13. /
14. :
15. ;
16.
17.
18. @ (when used more than once)
19. [
20. \
21. ]
22. |
23. DEL
There's certainly something wrong here. The open and close bracket
characters ('[' and ']', items 19 and 21) can indeed be part of a valid
email address. For example: [EMAIL PROTECTED]
Alan Stern
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 14, 2008, at 10:30 AM, Michael Brown wrote: The | character is not allowed in any e-mail address because it's a Unix shell reserved character. Here's a list right off the top of my head that are usually blocked/disabled by just about every MTA out there. 1. Control Characters 2. Space 3. ! 4. 5. # 6. $ 7. % 8. 9. ( 10. ) 11. * 12. , 13. / 14. : 15. ; 16. 17. 18. @ (when used more than once) 19. [ 20. \ 21. ] 22. | 23. DEL That explains why my emails to slashdot go unanswered -- everytime I go to their website I see that they have hacked my box and displaying my files for everone to see... just kiddin' Randal -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkgDckIACgkQHXnD0tz+/vw35wCfatMgrMFEcfRXc0QVZwTD1fmr b7kAoIq5OcR8V+AvFxuDUOKDcZHV4G14 =4SfP -END PGP SIGNATURE- ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Alan Stern wrote:
There's certainly something wrong here. The open and close bracket
characters ('[' and ']', items 19 and 21) can indeed be part of a valid
email address. For example: [EMAIL PROTECTED]
There's a difference between [EMAIL PROTECTED] which would
be invalid and [EMAIL PROTECTED] which should be translated via DNS.
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Bit Fuzzy wrote:
Alan Stern wrote:
There's certainly something wrong here. The open and close bracket
characters ('[' and ']', items 19 and 21) can indeed be part of a valid
email address. For example: [EMAIL PROTECTED]
There's a difference between [EMAIL PROTECTED] which would
be invalid and [EMAIL PROTECTED] which should be translated via DNS.
[EMAIL PROTECTED] may be invalid
but user[bogart]@somedomain.com isn't,
and neither is user|bogarrt@somedomain.com
postfix would accept all three forms even
and why not ??
http://www.ietf.org/rfc/rfc2822.txt
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
On Mon, Apr 14, 2008 at 05:22:56PM +0200, Bas van Rooijen said: postfix would accept all three forms even and why not ?? I assume you haven't looked at sendmail's security record. This has been a pretty standard thing to do for a long time, and with even more characters than the milter currently uses. -- -- | Stephen Gran | The most hopelessly stupid man is he| | [EMAIL PROTECTED] | who is not aware that he is wise. | | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Stephen Gran wrote: I assume you haven't looked at sendmail's security record. This has been a pretty standard thing to do for a long time, and with even more characters than the milter currently uses. That may be true, but filtering suspicious recipient addresses is beyond the scope of a virus-scanner, IMO. Much like my complaints about the PhishingScanURLs setting, I believe ClamAV should stick to the basics and leave other policy decisions alone. Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
On Mon, Apr 14, 2008 at 12:05:05PM -0400, David F. Skoll said: Stephen Gran wrote: I assume you haven't looked at sendmail's security record. This has been a pretty standard thing to do for a long time, and with even more characters than the milter currently uses. That may be true, but filtering suspicious recipient addresses is beyond the scope of a virus-scanner, IMO. Much like my complaints about the PhishingScanURLs setting, I believe ClamAV should stick to the basics and leave other policy decisions alone. I actually tend to agree with you on that, but the milter went far beyond that quite a long time ago. -- -- | Stephen Gran | He played the king as if afraid someone | | [EMAIL PROTECTED] | else would play the ace. -- John | | http://www.lobefin.net/~steve | Mason Brown, drama critic | -- signature.asc Description: Digital signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Michael Brown wrote: The | character is not allowed in any e-mail address because it's a Unix shell reserved character. Here's a list right off the top of my head that are usually blocked/disabled by just about every MTA out there. 1. Control Characters 2. Space 3. ! 4. 5. # 6. $ 7. % 8. 9. ( 10. ) 11. * 12. , 13. / 14. : 15. ; 16. 17. 18. @ (when used more than once) 19. [ 20. \ 21. ] 22. | 23. DEL The characters was passed to apopen call, thus to be escaped for a shell. The application shall quote the following characters if they are to represent themselves: |; ( ) $ ` \' space tab newline and the following may need to be quoted under certain circumstances. * ? [ # ˜ = % It's then up to $SENDMAIL_BIN to reject the address for having an embedded newline :) ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
David F. Skoll wrote: Stephen Gran wrote: I assume you haven't looked at sendmail's security record. This has been a pretty standard thing to do for a long time, and with even more characters than the milter currently uses. That may be true, but filtering suspicious recipient addresses is beyond the scope of a virus-scanner, IMO. Much like my complaints about the PhishingScanURLs setting, I believe ClamAV should stick to the basics and leave other policy decisions alone. Or at least leave them off by default, and make them things you can easily switch on and off. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
