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.
__
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 chara
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
* 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 co
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
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 t
> 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 ra
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?
___
[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
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?
>>>
>>>
>> Comme
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 c
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 ques
> 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 plac
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. &
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
>
-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 ab
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 [E
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]" whi
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 curren
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
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
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. !
>
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 ad
-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 o
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
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
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 t
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
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 sof
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
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 pi
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
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,
Davi
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
>
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
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 poss
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.
>
>
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,
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.
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.
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
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
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.
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
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'
Interestingly enough, since that discussion started I see a significant
increase in incoming mails for recipient addresses starting with a pipe
character. This was very rare in the past: looking back through the logs
I found just a small series on 2007-07-13 and three isolated attempts
in Septembe
46 matches
Mail list logo
