Title: Message
MS Corporation Security Center
[EMAIL PROTECTED]
On Wed, Sep 24, 2003 at 10:05:54AM -0500, Gunnar Wolf [EMAIL PROTECTED] was
heard to say:
Wouter Verhelst dijo [Wed, Sep 24, 2003 at 09:03:39AM +0200]:
I don't think so - And if so, this could break many client MTAs.
According to the protocol definition [1],
[...]
[1]
On Wed, Sep 24, 2003 at 12:44:50PM -0500, Gunnar Wolf [EMAIL PROTECTED] was
heard to say:
Daniel Burrows dijo [Wed, Sep 24, 2003 at 01:10:57PM -0400]:
And I insist... Do you want to stop every mail which is (peeking at my
inbox) between 1887 and 2183 bytes long just because it might be a
Hello,
On Sat, Sep 20, 2003 at 03:41:36PM +0200, Paul Seelig wrote:
snip -
Package: popsneaker
Status: install ok installed
Priority: optional
Section: mail
Installed-Size: 159
Maintainer: Stefan Baehre [EMAIL PROTECTED]
Version: 0.6.2-1
Depends:
Hi,
Graham Wilson wrote:
On Mon, Sep 22, 2003 at 04:53:16PM +0200, Matthias Urlichs wrote:
A pure MTA solution would still need to scan the body and thus would
still eat your bandwidth.
i have postfix's body_checks setup to reject lines that match the
following regular expression (this is
Hi, Steve Lamb wrote:
What would help is to be able to block an IP once it's been hit.
That won't work for people who have a secondary MX record.
I've set up a second mailer which simply rejects everything (one that
speaks correct SMTP... :-/ ), and the source addresses which flood me
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 23 September 2003 01:48, Gunnar Wolf wrote:
Mike Hommey dijo [Tue, Sep 23, 2003 at 12:28:44AM +0200]:
Maybe I'm wrong, but I think an MTA rejecting a mail because of oversized
body doesn't have to get the whole body before rejecting
On Mon, Sep 22, 2003 at 04:53:16PM +0200, Matthias Urlichs wrote:
The list of hardware required to stop this spam unfortunately seems to
include a time machine.
Just because you can't afford one...
Another (cheaper) solution though would be to pull the plug ;-).
There! No more spam problems!
On Tue, 2003-09-23 at 03:44, Lars Wirzenius wrote:
I favor this approach over simple applications of violence, such as
using an axe on any computer infected by a virus.
Why punish the hardware for what is clearly a wetware problem?
signature.asc
Description: This is a digitally signed
Op di 23-09-2003, om 01:48 schreef Gunnar Wolf:
Mike Hommey dijo [Tue, Sep 23, 2003 at 12:28:44AM +0200]:
helps catching 95%... But the bandwidth is still used... I'm still
looking for a pure MTA solution...
A pure MTA solution would still need to scan the body and thus would still
On Tue, Sep 23, 2003 at 12:52:30PM -0700, Steve Lamb wrote:
Same here though I am sticking with SA-Exim because it saves the mail
in a certain range so I can throw it at the Bayesian classifier.
I usually don't have large enough partitions to hold all the spam (!)
Certain
On Wed, 24 Sep 2003 16:17:45 +0200
Josip Rodin [EMAIL PROTECTED] wrote:
Runs spamc twice. Usually it won't matter, but with higher traffic, the load
will increase for obvious reasons...
spamc isn't run twice. exiscan-acl *can* run the mail through SA as a
test. It doesn't /have/ to. So
Wouter Verhelst dijo [Wed, Sep 24, 2003 at 09:03:39AM +0200]:
I don't think so - And if so, this could break many client MTAs.
According to the protocol definition [1],
[...]
[1] http://www.ietf.org/rfc/rfc0821.txt
MTAs that still stick to nothing but RFC821 are horribly outdated
Op wo 24-09-2003, om 17:05 schreef Gunnar Wolf:
And I insist... Do you want to stop every mail which is (peeking at my
inbox) between 1887 and 2183 bytes long just because it might be a
virus?
Hm. I was under the impression that they were a lot larger.
OK, never mind...
--
Wouter Verhelst
Daniel Burrows dijo [Wed, Sep 24, 2003 at 01:10:57PM -0400]:
And I insist... Do you want to stop every mail which is (peeking at my
inbox) between 1887 and 2183 bytes long just because it might be a
virus?
Um, those are line counts, not byte counts. 1889 lines is about 140k
on the
On Wed, Sep 24, 2003 at 06:33:45PM +0200, Wouter Verhelst wrote:
Op wo 24-09-2003, om 17:05 schreef Gunnar Wolf:
And I insist... Do you want to stop every mail which is (peeking at my
inbox) between 1887 and 2183 bytes long just because it might be a
virus?
Hm. I was under the
On Wed, Sep 24, 2003 at 07:37:03AM -0700, Steve Lamb wrote:
Runs spamc twice. Usually it won't matter, but with higher traffic, the load
will increase for obvious reasons...
spamc isn't run twice. exiscan-acl *can* run the mail through SA as a
test. It doesn't /have/ to. So if one
On ma, 2003-09-22 at 17:53, Matthias Urlichs wrote:
The list of hardware required to stop this spam unfortunately seems to
include a time machine.
Oh, that's not required at all. A simple couch will do.
The couch will require a team of psychiatrists surrounding it, of
course. They will then
On Tuesday 23 September 2003 01:45, Bernd Eckenfels wrote:
On Tue, Sep 23, 2003 at 12:28:44AM +0200, Mike Hommey wrote:
Maybe I'm wrong, but I think an MTA rejecting a mail because of oversized
body doesn't have to get the whole body before rejecting the mail. Based
on this, it should be
On Tue, Sep 23, 2003 at 12:28:44AM +0200, Mike Hommey wrote:
Maybe I'm wrong, but I think an MTA rejecting a mail because of
oversized body doesn't have to get the whole body before rejecting the
mail.
You can issue a permanent error only after you have received the body.
Hi,
Is there something similar for exim (woody version)? I don't care too
much about the incoming bandwidth, but more about the resources that the
spam and virus checks consume, especially during these spam virus waves.
So I could add a (hopefully) cheap check at MTA level to reject these
mails
On Mon, Sep 22, 2003 at 07:34:58PM -0400, H. S. Teoh wrote:
I've resorted to blocking port 25 to subnets from which these spams
originate. Currently I have about 45 subnets (/24 and a few /16) on my
blacklist, and so far 409 connections have been dropped.
The sad thing about this is that there
On Mon, Sep 22, 2003 at 08:46:15PM -0700, Steve Lamb wrote:
On Mon, 22 Sep 2003 22:44:50 -0400
H. S. Teoh [EMAIL PROTECTED] wrote:
Another major source is rr.com, which not only gives me tons of Swen, but
also other spam in general. I've blacklisted rr.com in /etc/hosts.deny,
but obviously
On Tue, Sep 23, 2003 at 02:31:22PM +0200, Josip Rodin wrote:
On Mon, Sep 22, 2003 at 07:34:58PM -0400, H. S. Teoh wrote:
I've resorted to blocking port 25 to subnets from which these spams
originate. Currently I have about 45 subnets (/24 and a few /16) on my
blacklist, and so far 409
Lars Wirzenius writes:
I favor this approach over simple applications of violence, such as using
an axe on any computer infected by a virus.
Psychiatry just for sending viruses? I don't know. Seems pretty extreme
to me. Are you sure simple beatings would not suffice?
--
John Hasler
[EMAIL
On Tue, Sep 23, 2003 at 08:39:02AM -0400, H. S. Teoh wrote:
What are the exim rules you used to catch these things?
exiscan-acl calling clamav and dropping it with a 550. A full log
line would be:
2003-09-22 07:38:05 1A1RpB-0007Xd-Of H=(smtp21.singnet.com.sg)
[165.21.101.201]
Steve Lamb dijo [Mon, Sep 22, 2003 at 07:21:05PM -0700]:
Gunnar Wolf [EMAIL PROTECTED] wrote:
[1] http://www.ietf.org/rfc/rfc0821.txt
And what does RFC2821 have to say about it?
I would not trust every MTA to implement newer versions of the RFC -
However, it is up to you to decide ;-)
You are aware Mutt is perfectly capable of responding to the list. Learn
it, love it, USE IT!
On Tue, 23 Sep 2003 10:20:46 -0500
Gunnar Wolf [EMAIL PROTECTED] wrote:
Steve Lamb dijo [Mon, Sep 22, 2003 at 07:21:05PM -0700]:
Gunnar Wolf [EMAIL PROTECTED] wrote:
[1]
On Tue, 23 Sep 2003 08:39:02 -0400
H. S. Teoh [EMAIL PROTECTED] wrote:
On Mon, Sep 22, 2003 at 08:46:15PM -0700, Steve Lamb wrote:
Except it never hits SA nor do I even have procmail installed. Can't
stand the ugly beast.
It never hits SA? Almost all Swen mails I got were caught by my
On Tue, 23 Sep 2003 16:45:55 +0200
Josip Rodin [EMAIL PROTECTED] wrote:
For now I'm using the SA-Exim method because even though it's clumsy (needs
the .so file compiled from source so distribution isn't as trivial as an
apt-get invocation), I used it before the Exiscan patch was available and
Steve Lamb dijo [Tue, Sep 23, 2003 at 10:29:51AM -0700]:
Gunnar Wolf [EMAIL PROTECTED] wrote:
Steve Lamb dijo [Mon, Sep 22, 2003 at 07:21:05PM -0700]:
Gunnar Wolf [EMAIL PROTECTED] wrote:
[1] http://www.ietf.org/rfc/rfc0821.txt
And what does RFC2821 have to say about it?
I
On Tue, Sep 23, 2003 at 10:43:30AM -0700, Steve Lamb wrote:
For now I'm using the SA-Exim method because even though it's clumsy (needs
the .so file compiled from source so distribution isn't as trivial as an
apt-get invocation), I used it before the Exiscan patch was available and it
was
On Tue, 23 Sep 2003 21:07:46 +0200
Josip Rodin [EMAIL PROTECTED] wrote:
On Tue, Sep 23, 2003 at 10:43:30AM -0700, Steve Lamb wrote:
Same here though I am sticking with SA-Exim because it saves the mail
in a certain range so I can throw it at the Bayesian classifier.
I usually don't
Hi, Mike Hommey wrote:
helps catching 95%... But the bandwidth is still used... I'm still looking
for
a pure MTA solution...
A pure MTA solution would still need to scan the body and thus would still
eat your bandwidth.
The list of hardware required to stop this spam unfortunately seems to
Hi, Daniel Burrows wrote:
On Fri, Sep 19, 2003 at 10:45:57AM -0500, Luca - De Whiskey's - De Vitis
[EMAIL PROTECTED] was heard to say:
I'm getting one evry 30 minutes, more or less... but i've read on irc that
this is quite common now...
You mean seconds, not minutes, right? :-(
Sounds
On Monday 22 September 2003 16:53, Matthias Urlichs wrote:
Hi, Mike Hommey wrote:
helps catching 95%... But the bandwidth is still used... I'm still
looking for a pure MTA solution...
A pure MTA solution would still need to scan the body and thus would still
eat your bandwidth.
Maybe I'm
On Mon, Sep 22, 2003 at 04:53:16PM +0200, Matthias Urlichs wrote:
Hi, Mike Hommey wrote:
helps catching 95%... But the bandwidth is still used... I'm still looking
for
a pure MTA solution...
A pure MTA solution would still need to scan the body and thus would still
eat your
On Tue, Sep 23, 2003 at 12:28:44AM +0200, Mike Hommey wrote:
Maybe I'm wrong, but I think an MTA rejecting a mail because of oversized
body
doesn't have to get the whole body before rejecting the mail. Based on this,
it should be possible to reject the mail before it gets fully transfered
Mike Hommey dijo [Tue, Sep 23, 2003 at 12:28:44AM +0200]:
helps catching 95%... But the bandwidth is still used... I'm still
looking for a pure MTA solution...
A pure MTA solution would still need to scan the body and thus would still
eat your bandwidth.
Maybe I'm wrong, but I think
On Mon, 22 Sep 2003 19:34:58 -0400
H. S. Teoh [EMAIL PROTECTED] wrote:
I've resorted to blocking port 25 to subnets from which these spams
What would help is to be able to block an IP once it's been hit. Thing is
I cannot for the life of me figure out a way to do it. Here's the first 25
On Mon, 22 Sep 2003 18:48:58 -0500
Gunnar Wolf [EMAIL PROTECTED] wrote:
[1] http://www.ietf.org/rfc/rfc0821.txt
And what does RFC2821 have to say about it?
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the
On Mon, Sep 22, 2003 at 04:53:16PM +0200, Matthias Urlichs wrote:
Hi, Mike Hommey wrote:
helps catching 95%... But the bandwidth is still used... I'm still
looking for a pure MTA solution...
A pure MTA solution would still need to scan the body and thus would still
eat your bandwidth.
i
On Mon, Sep 22, 2003 at 07:18:56PM -0700, Steve Lamb wrote:
On Mon, 22 Sep 2003 19:34:58 -0400
H. S. Teoh [EMAIL PROTECTED] wrote:
I've resorted to blocking port 25 to subnets from which these spams
What would help is to be able to block an IP once it's been hit. Thing is
I cannot for
On Mon, 22 Sep 2003 22:44:50 -0400
H. S. Teoh [EMAIL PROTECTED] wrote:
Another major source is rr.com, which not only gives me tons of Swen, but
also other spam in general. I've blacklisted rr.com in /etc/hosts.deny,
but obviously I'm missing something obvious, 'cos rr.com spam still gets
44 matches
Mail list logo
