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,
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,
David.
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
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
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
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
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. And no,
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 as
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 between
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.
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
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
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
-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
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
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 to not
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
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.
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
* 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
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
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
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
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 and recompile?
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
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?
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
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
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
2.
-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
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
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
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
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 true,
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.
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
45 matches
Mail list logo
