On Tue, 20 Jun 2006, jdow wrote:
A one time one hour delay for a given source is no big deal.
That's a value judgement. Not universally true for everyone.
Probably true for lots of people, in which case ideas on how
to minimize the negatives of greylisting will be worthless.
For others,
Logan Shaw wrote:
Basically, greylisting has an achilles heel: legit messages
from unknown senders are delayed a long time. This is fine for
Only if you use a long delay.
In my experience a grey period of 3 minutes is enough to stop most spam and
viruses. Especially if you combine it with
Jonas Eckerman wrote:
Logan Shaw wrote:
Basically, greylisting has an achilles heel: legit messages
from unknown senders are delayed a long time. This is fine for
Only if you use a long delay.
Or if the sender has a long retry period. Yeah, you can expect them to
retry in 10-15
From: Jonas Eckerman [EMAIL PROTECTED]
Logan Shaw wrote:
Basically, greylisting has an achilles heel: legit messages
from unknown senders are delayed a long time. This is fine for
Only if you use a long delay.
In my experience a grey period of 3 minutes is enough to stop most spam and
From: Kelson [EMAIL PROTECTED]
Jonas Eckerman wrote:
Logan Shaw wrote:
Basically, greylisting has an achilles heel: legit messages
from unknown senders are delayed a long time. This is fine for
Only if you use a long delay.
Or if the sender has a long retry period. Yeah, you can
jdow wrote:
From: Jonas Eckerman [EMAIL PROTECTED]
Logan Shaw wrote:
Basically, greylisting has an achilles heel: legit messages
from unknown senders are delayed a long time. This is fine for
Only if you use a long delay.
In my experience a grey period of 3 minutes is enough to stop most
From: Rick Macdougall [EMAIL PROTECTED]
jdow wrote:
From: Jonas Eckerman [EMAIL PROTECTED]
Logan Shaw wrote:
Basically, greylisting has an achilles heel: legit messages
from unknown senders are delayed a long time. This is fine for
Only if you use a long delay.
In my experience a grey
I'm running sendmail here on a home server. I've been looking for a good
greylist package and I frankly have not found one. There are a couple out
there but they work in memory and don't maintain their tables in a
database.
I'm also running spamass-milter which is set to reject mail ifd SA
Title: RE: Can SA be used to implement greylisting?
-Original Message-
From: Steven W. Orr [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 19, 2006 9:08 AM
To: spamassassin-users
Subject: Can SA be used to implement greylisting?
I'm running sendmail here on a home server
On Monday, Jun 19th 2006 at 11:40 -0400, quoth Chris Santerre:
=
=
= -Original Message-
= From: Steven W. Orr [mailto:[EMAIL PROTECTED]
= Sent: Monday, June 19, 2006 9:08 AM
= To: spamassassin-users
= Subject: Can SA be used to implement greylisting?
=
=
= I'm running sendmail here
be used to implement greylisting?
=
=
= I'm running sendmail here on a home server. I've been looking
= for a good
= greylist package and I frankly have not found one. There are
= a couple out
= there but they work in memory and don't maintain their tables in a
= database.
=
=grey.uribl.com
: Monday, June 19, 2006 9:08 AM
= = To: spamassassin-users
= = Subject: Can SA be used to implement greylisting?
= =
= =
= = I'm running sendmail here on a home server. I've been looking
= = for a good
= = greylist package and I frankly have not found one. There are
= = a couple out
Steven W. Orr writes:
And this is my point. SA *DOESN'T* work on messages after they have been
received. Since I use spamass-milter, SA sees the messages before
reception is completed. (You're free to do otherwise.) Then when SA
decides that the message doesn't conform to its high
On Mon, 19 Jun 2006, Steven W. Orr wrote:
= Is it worthwhile to try to convince the SA dev
= crowd to add greylist functionality?
Neither. What I'm looking for is a rubust way to say: I haven't
seen mail from this guy before so I'm going to reject his email
with a 450 error code. If email
[snip]
And this is my point. SA *DOESN'T* work on messages
after they have been
received. Since I use spamass-milter, SA sees the messages before
reception is completed. (You're free to do otherwise.) Then when SA
decides that the message doesn't conform to its high standards, the
report
John D. Hardin writes:
On Mon, 19 Jun 2006, Steven W. Orr wrote:
= Is it worthwhile to try to convince the SA dev
= crowd to add greylist functionality?
Neither. What I'm looking for is a rubust way to say: I haven't
seen mail from this guy before so I'm going to reject his email
On Mon, 19 Jun 2006, Steven W. Orr wrote:
And this is my point. SA *DOESN'T* work on messages after they have been
received. Since I use spamass-milter, SA sees the messages before
reception is completed. (You're free to do otherwise.) Then when SA
decides that the message doesn't conform to
Steven W. Orr wrote:
I'm running sendmail here on a home server. I've been looking for a good
greylist package and I frankly have not found one. There are a couple out
there but they work in memory and don't maintain their tables in a
database.
My greylist code
On Mon, 19 Jun 2006, Justin Mason wrote:
Yep -- that's the key point -- as far as I know it's illegal (in
SMTP terms) to offer a 421 after DATA.
--j.
RFC-2821 section 3.9:
An SMTP server MUST NOT intentionally close the connection except:
- After receiving a QUIT command and
On Mon, 19 Jun 2006, David B Funk wrote:
On Mon, 19 Jun 2006, Justin Mason wrote:
Yep -- that's the key point -- as far as I know it's illegal (in
SMTP terms) to offer a 421 after DATA.
RFC-2821 section 3.9:
An SMTP server MUST NOT intentionally close the connection except:
- After
On Mon, 19 Jun 2006, Steven W. Orr wrote:
And this is my point. SA *DOESN'T* work on messages after they
have been received. Since I use spamass-milter, SA sees the
messages before reception is completed.
So, you're passing just the message headers through SA?
Using a milter doesn't
On Mon, 19 Jun 2006, Logan Shaw wrote:
If it comes up with a very high score (almost definitely spam),
drop it right away. If it comes up with an indeterminate score,
apply the greylisting approach and delay it until later.
What's the point? You've already *got* the entire message, at that
JamesDR wrote:
Logan Shaw wrote:
On Mon, 19 Jun 2006, David B Funk wrote:
On Mon, 19 Jun 2006, Justin Mason wrote:
[snip]
1) Message comes in, check against AWL, if sender/ip pair do not exist,
send the tempfail, if sender/ip pair do exist:
2) Check the average score against some
On Mon, 19 Jun 2006, John D. Hardin wrote:
On Mon, 19 Jun 2006, Logan Shaw wrote:
If it comes up with a very high score (almost definitely spam),
drop it right away. If it comes up with an indeterminate score,
apply the greylisting approach and delay it until later.
What's the point? You've
On Mon, 19 Jun 2006, Rick Macdougall wrote:
JamesDR wrote:
1) Message comes in, check against AWL, if sender/ip pair do not exist,
send the tempfail, if sender/ip pair do exist:
2) Check the average score against some threshold (say 4 points as a
figure.) If sender's score is over this
On Mon, 19 Jun 2006, Logan Shaw wrote:
Consider the case of a spammer whose software *does* retry, but
retries every two or three minutes until delivery is accepted or
PERMFAILed. I have seen this in my greylist logs. Do you really want
SA + AV + whatever to completely process this
26 matches
Mail list logo
