Am 04.08.2016 um 22:30 schrieb Chris:
> Greylisting is just one of several tools available to a system
> administrator for filtering out spam
as multiple described it does not
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße
I do not use postfix but I do greylist so I thought I would chime in
with my opinion.
Greylisting is just one of several tools available to a system
administrator for filtering out spam, like any of the other tools if
used incorrectly it will be problematic.
I do much cheaper filtering first
On Tue, 2 Aug 2016, Benny Pedersen wrote:
On 2016-08-02 20:00, John Hardin wrote:
Is there any way to use postscreen as a frontend filter for a sendmail
MTA?
content-filter works nicely in postfix, but that postscreen will not use
content-filter to help on its problem
postfix can use se
Am 02.08.2016 um 23:02 schrieb Benny Pedersen:
On 2016-08-02 20:00, John Hardin wrote:
Is there any way to use postscreen as a frontend filter for a sendmail
MTA?
content-filter works nicely in postfix
which is not the topic
but that postscreen will not use
content-filter to help on its
On 2016-08-02 21:27, Robert Schetterer wrote:
you may use a complete postfix server including postscreen etc "before"
sendmailbut then it might better to simply change to postfix in
total, but such setups are often use with MS exchange
if that can serve as a content-filter it could be used
On 2016-08-02 20:00, John Hardin wrote:
Is there any way to use postscreen as a frontend filter for a sendmail
MTA?
content-filter works nicely in postfix, but that postscreen will not use
content-filter to help on its problem
postfix can use sendmail as a content-filter
what goal ?
On 2 Aug 2016, at 14:00, John Hardin wrote:
On Tue, 2 Aug 2016, Bill Cole wrote:
What's special about the postscreen delay is:
1. It delays only the last line of a multi-line greeting, so it
catches MANY more bots than a simple delay.
2. It caches PASS results so even the very short (6s by
Am 02.08.2016 um 20:04 schrieb Reindl Harald:
>
>
> Am 02.08.2016 um 20:00 schrieb John Hardin:
>> On Tue, 2 Aug 2016, Bill Cole wrote:
>>
>>> What's special about the postscreen delay is:
>>>
>>> 1. It delays only the last line of a multi-line greeting, so it
>>> catches MANY more bots than a si
Am 02.08.2016 um 20:00 schrieb John Hardin:
On Tue, 2 Aug 2016, Bill Cole wrote:
What's special about the postscreen delay is:
1. It delays only the last line of a multi-line greeting, so it
catches MANY more bots than a simple delay.
2. It caches PASS results so even the very short (6s by
On Tue, 2 Aug 2016, Bill Cole wrote:
What's special about the postscreen delay is:
1. It delays only the last line of a multi-line greeting, so it catches MANY
more bots than a simple delay.
2. It caches PASS results so even the very short (6s by default) delay that
it imposes only hits the
Am 02.08.2016 um 18:55 schrieb Bill Cole:
Combined, this is why Sendmail and other MTA greeting delays are less
spectacularly effective than they used to be and less effective than
postscreen. The resource cost of prolonging every session to 6s is
untenable for busy machines, so bots that have
On 1 Aug 2016, at 15:53, Axb wrote:
On 01.08.2016 21:30, Vincent Fox wrote:
I keep seeing people say "well if you have postscreen, greylisting is
just dumb".
I think that's a bit too strong. Robust greylisting that accommodates
the reality of mail systems that share one sp
On 01 Aug 2016, at 11:02, Matus UHLAR - fantomas wrote:
>> On 31 Jul 2016, at 22:12, Benny Pedersen wrote:
>>> i bet greylist is cough invalid mailservers at the doorstep, it could be
>>> that postscreen is bad aswell ?
>
> On 01.08.16 07:46, @lbutlr wrote:
>> Sure, if by “invalid” you mean Ama
Am 02.08.2016 um 00:05 schrieb Benny Pedersen:
On 2016-08-01 19:02, Matus UHLAR - fantomas wrote:
while we're at it, I really don't understand why they do it like this.
what's the point behind changing IP address after each delivery attempt?
goal is to expose more networks ips to be blocked
On 2016-08-01 19:18, Larry Rosenman wrote:
Shared outbound spool, and the next available host sends it.
next host start a new greylist time frame to delay again
It's not nefarious, just load balancing.
yes misunderstanding what not to do
On 2016-08-01 19:02, Matus UHLAR - fantomas wrote:
while we're at it, I really don't understand why they do it like this.
what's the point behind changing IP address after each delivery
attempt?
goal is to expose more networks ips to be blocked at the recipient
server for abuse, ironical :)
Am 01.08.2016 um 23:36 schrieb sha...@shanew.net:
Others could probably add to that list, but that's just off the top of
my head. But, even if a spam source retries and successfully makes it
past the greylisting, the greylisting still provides potential
benefits, like:
- While it was wa
On Sun, 31 Jul 2016, Robert Schetterer wrote:
Greylisting was invented as an idea against bots. Its based on the idea
that bots "fire and forget" when they see a tmp error and dont get back.
But thats historic, bots are recoded, better antibot tecs were invented.
The only problem now
ot in the same league at all.
Between milter-greylist, and several measures, it covers quite a bit
at the first layer, before we have to get to the expensive SpamAssassin stuff.
The hate on greylisting seems a bit off to me. I realize it's not the most
effective tool in my toolbox, bu
On 01.08.2016 21:30, Vincent Fox wrote:
I keep seeing people say "well if you have postscreen, greylisting is just
dumb".
Well what is the equivalent for other MTA?
google for "Greet pause" and "Early talker"
afaik there's implementations for Sendmail
I keep seeing people say "well if you have postscreen, greylisting is just
dumb".
Well what is the equivalent for other MTA?
I still see a lot of spambots on PBL hosts, that never contact again. So the
blanket statement "bots are recoded" just doesn't jibe with wha
Am 01.08.2016 um 19:02 schrieb Matus UHLAR - fantomas:
On 31 Jul 2016, at 22:12, Benny Pedersen wrote:
i bet greylist is cough invalid mailservers at the doorstep, it could
be that postscreen is bad aswell ?
On 01.08.16 07:46, @lbutlr wrote:
Sure, if by “invalid” you mean Amazon, most bank
On 2016-08-01 12:02, Matus UHLAR - fantomas wrote:
On 31 Jul 2016, at 22:12, Benny Pedersen wrote:
i bet greylist is cough invalid mailservers at the doorstep, it could
be that postscreen is bad aswell ?
On 01.08.16 07:46, @lbutlr wrote:
Sure, if by “invalid” you mean Amazon, most banks, seve
On 31 Jul 2016, at 22:12, Benny Pedersen wrote:
i bet greylist is cough invalid mailservers at the doorstep, it could be that
postscreen is bad aswell ?
On 01.08.16 07:46, @lbutlr wrote:
Sure, if by “invalid” you mean Amazon, most banks, several airlines, large
mail services, and many many o
> On Aug 1, 2016, at 10:15 AM, Benny Pedersen wrote:
>
>>>
>>> i bet greylist is cough invalid mailservers at the doorstep, it could be
>>> that postscreen is bad aswell ?
>> Sure, if by “invalid” you mean Amazon, most banks, several airlines,
>> large mail services, and many many others.
>
>
always being a fail with
greylist
There is a reason that greylist software comes with default
exclusions, because greylisting is known to cause missed email if used
as designed.
postscreen dont care at all
take that
in historic stuff.
>> Yeah, that about sums it up. Greylisting never worked well, always
>> caused problems with lost email, and in 2016 is simply a bad idea. Not
>> just a not good idea, but a bad idea.
>
> back to basic then, why would a mta like postfix not deliver later
On 2016-08-01 05:55, @lbutlr wrote:
On 31 Jul 2016, at 01:06, Robert Schetterer wrote:
But thats historic, bots are recoded, better antibot tecs were
invented.
The only problem now is people still believe in historic stuff.
Yeah, that about sums it up. Greylisting never worked well, always
On 31 Jul 2016, at 01:06, Robert Schetterer wrote:
> But thats historic, bots are recoded, better antibot tecs were invented.
> The only problem now is people still believe in historic stuff.
Yeah, that about sums it up. Greylisting never worked well, always caused
problems with lost emai
+0200
>>>> Robert Schetterer wrote:
>>>>
>>>>>> I don't use postfix or postscreen.
>>>>> hm.. that does not fit the subject..why did you involved yourself ?
>>>>
>>>> I am sorry. I should have changed the
ed by a
local, rescursing resolver anyways and finally postfix-smtpd/postrey
have only to deal with a very low volume and the very expensive content
filter sees mostly ham
*if* a message makes it through postscreen and up to greylisting the
DNSWL and SPF results are cached anyways and re-used b
time. Caching DNS can probably help a bit,
but it will still require the occasional lookup now and then that take
a lot longer than a good greylisting implementation should ever do.
Actually, having a local (same machine or same LAN) caching DNS resolver
is extremely helpful relative to using a
creen.
hm.. that does not fit the subject..why did you involved yourself ?
I am sorry. I should have changed the thread subject.
you may get that quite better, i see
a lot of server greylisting useless ,only filling up others queues
waiting for a second slot ,so it may only cheap for you but no
d you involved yourself ?
I am sorry. I should have changed the thread subject.
you may get that quite better, i see
a lot of server greylisting useless ,only filling up others queues
waiting for a second slot ,so it may only cheap for you but not for
your partners
Dont slow down communication if you
ect..why did you involved yourself ?
>>
>> I am sorry. I should have changed the thread subject.
>>
>>> you may get that quite better, i see
>>> a lot of server greylisting useless ,only filling up others queues
>>> waiting for a second slot ,so it may
quite better, i see
a lot of server greylisting useless ,only filling up others queues
waiting for a second slot ,so it may only cheap for you but not for
your partners
Dont slow down communication if you dont need to
So what I didn't mention is that in our implementation, once an IP
address s
On Fri, 29 Jul 2016 22:39:15 +0200
Robert Schetterer wrote:
> > I don't use postfix or postscreen.
> hm.. that does not fit the subject..why did you involved yourself ?
I am sorry. I should have changed the thread subject.
> you may get that quite better, i see
> a lot o
On Mon, 3 Dec 2012 07:23:59 -0800
Gary Funck wrote:
> Since this is a Spam Assassin list: Is there a way of disabling
> grey listing, but still receiving some benefit from the principle
> that mail received from a first time or infrequent sender should
> be looked upon with some suspicion?
Person
On Mon, 2012-12-03 at 07:23 -0800, Gary Funck wrote:
> Since this is a Spam Assassin list: Is there a way of disabling
> grey listing, but still receiving some benefit from the principle
> that mail received from a first time or infrequent sender should
> be looked upon with some suspicion?
>
Yes.
>> We greylist after the end of DATA. This wastes bandwidth, but lets us
>> use the Subject: line as an additional mix in the greylisting tuple.
>> This catches ratware that retries in the face of greylisting, but
>> mutates the subject line with each retry.
> We
On 11/29/12 14:46:25, David F. Skoll wrote:
> We greylist after the end of DATA. This wastes bandwidth, but lets us
> use the Subject: line as an additional mix in the greylisting tuple.
> This catches ratware that retries in the face of greylisting, but
> mutates the subject line wit
On 11/29/2012 18:54, David F. Skoll wrote:
[My gut instinct says that a reasonable greylisting interval is too
short for most DNSBLs to react. Pyzor/Razor/DCC may be somewhat more
adept at reacting quickly.]
Something trap-driven like NIX is a candidate. No, it's not safe enough
to r
On 11/29/2012 17:37, John Levine wrote:
Does greylisting increase chances of bulk detectors (razor/pyzor/dcc) in
case of "yahoo like" spam sources?
No. A remarkable fraction of ratware still doesn't bother to retry,
so the most simple minded greylister will deter them. That&#x
he score for that message will be higher than it would the
> first time around, hopefully high enough to classify it as spam
> rather than a FN.
I would love to gather some hard data on this. Maybe a research
project for the future... since we do our greylisting post-DATA,
we could in princi
On Thu, 30 Nov 2012, John Levine wrote:
Does greylisting increase chances of bulk detectors (razor/pyzor/dcc) in
case of "yahoo like" spam sources?
No. A remarkable fraction of ratware still doesn't bother to retry,
so the most simple minded greylister will deter them.
>Does greylisting increase chances of bulk detectors (razor/pyzor/dcc) in
>case of "yahoo like" spam sources?
No. A remarkable fraction of ratware still doesn't bother to retry,
so the most simple minded greylister will deter them. That's why it's
useful. I&#x
On Thu, 29 Nov 2012 22:47:45 +0100
Axb wrote:
> boxes:
About 50 000
> rcpt domains:
About 2000
> rcpt users:
Lots. I don't have an exact figure.
> you guys are sending through greylisting.
This is on our machines. Our larger customers have significantly
higher numbers.
Regards,
David.
On Thu, 29 Nov 2012, David F. Skoll wrote:
On Thu, 29 Nov 2012 21:27:19 +0100
"Andrzej A. Filip" wrote:
Do you treat "yahoo like" spam sources in the same way?
With respect to greylisting, of course. If a machine passes greylisting
once, it's extremely likely
Just wondering how many
boxes:
rcpt domains:
rcpt users:
you guys are sending through greylisting.
Axb
PT properly.
>
> We greylist after the end of DATA. This wastes bandwidth, but lets us
> use the Subject: line as an additional mix in the greylisting tuple.
> This catches ratware that retries in the face of greylisting, but
> mutates the subject line with each retry.
>
> Al
On Thu, 29 Nov 2012 21:59:45 +0100
"Andrzej A. Filip" wrote:
> Does greylisting increase chances of bulk detectors (razor/pyzor/dcc)
> in case of "yahoo like" spam sources?
> [ based on your experience ]
I suppose it might, but I don't use razor, pyzor, dc
On 11/29/2012 09:53 PM, David F. Skoll wrote:
> On Thu, 29 Nov 2012 21:27:19 +0100
> "Andrzej A. Filip" wrote:
>
>> Do you treat "yahoo like" spam sources in the same way?
> With respect to greylisting, of course. If a machine passes greylisting once,
> i
On Thu, 29 Nov 2012 21:27:19 +0100
"Andrzej A. Filip" wrote:
> Do you treat "yahoo like" spam sources in the same way?
With respect to greylisting, of course. If a machine passes greylisting once,
it's extremely likely to pass it in future and it's an u
On 11/29/2012 09:31 PM, Dave Warren wrote:
> On 11/29/2012 12:27, Andrzej A. Filip wrote:
>> On 11/29/2012 08:46 PM, David F. Skoll wrote:
>>> [...]
>>> Also, once a given IP passes greylisting, we remember that and we don't
>>> greylist that server for
y failure.
>
> Many such servers use broken SMTP implementations that can't handle
> a 4xx code in response to RCPT properly.
>
> We greylist after the end of DATA. This wastes bandwidth, but lets us
> use the Subject: line as an additional mix in the greylisting tuple.
> Th
On 11/29/2012 12:27, Andrzej A. Filip wrote:
On 11/29/2012 08:46 PM, David F. Skoll wrote:
[...]
Also, once a given IP passes greylisting, we remember that and we don't
greylist that server for 40 days. If you have a large-enough user population,
this can greatly mitigate the problems c
On 11/29/2012 08:46 PM, David F. Skoll wrote:
> [...]
> Also, once a given IP passes greylisting, we remember that and we don't
> greylist that server for 40 days. If you have a large-enough user population,
> this can greatly mitigate the problems caused by initial greylisti
7;t handle
a 4xx code in response to RCPT properly.
We greylist after the end of DATA. This wastes bandwidth, but lets us
use the Subject: line as an additional mix in the greylisting tuple.
This catches ratware that retries in the face of greylisting, but
mutates the subject line with each retry
On 5/17/2011 4:56 AM, Per Jessen wrote:
David F. Skoll wrote:
On Tue, 17 May 2011 09:46:09 +0200
Per Jessen wrote:
The main/only problem I have with greylisting are otherwise legit
servers that don't do retries - usually unpatched Exchange 2003
servers.
I've never seen any Excha
David F. Skoll wrote:
> On Tue, 17 May 2011 09:46:09 +0200
> Per Jessen wrote:
>
>> The main/only problem I have with greylisting are otherwise legit
>> servers that don't do retries - usually unpatched Exchange 2003
>> servers.
>
> I've never s
On Tue, 17 May 2011 09:46:09 +0200
Per Jessen wrote:
> The main/only problem I have with greylisting are otherwise legit
> servers that don't do retries - usually unpatched Exchange 2003
> servers.
I've never seen any Exchange server of any version fail greylisting.
(Again
Giles Coochey wrote:
> This is not intended as a slag-off of greylisting, simply a statement
> that it requires constant maintenance if you are going to be sure that
> all legitimate mail is reaching its destination.
The main/only problem I have with greylisting are otherwise legit
ser
On Tue, 08 Feb 2011 17:04:37 +
Steve Freegard wrote:
> Sure - credit where it is due; I've you to the 'Thanks' section.
Thanks. And also, my apologies for posting to the list... that was supposed
to be a private message. :(
/me mutters something about email amateurs not understanding how e
Hi David,
On 08/02/11 15:57, David F. Skoll wrote:
Hi, Steve,
http://www.fsl.com/index.php/resources/whitepapers/99
Interesting. I think you should credit me for this:
"Once that has been proven then that â is exempted from further
greylisting for 40 days since it was last seen.&
On Tue, 08 Feb 2011 15:47:12 +
Steve Freegard wrote:
> See http://www.fsl.com/index.php/resources/whitepapers/99
"Once that has been proven then that 'hostid' is exempted from further
greylisting for 40 days since it was last seen."
:) Our CanIt system has been do
Hi, Steve,
> http://www.fsl.com/index.php/resources/whitepapers/99
Interesting. I think you should credit me for this:
"Once that has been proven then that â is exempted from further
greylisting for 40 days since it was last seen."
Our CanIt system has been doing that since at le
On 19/01/11 15:02, David F. Skoll wrote:
On Wed, 19 Jan 2011 09:56:47 -0500
Lee Dilkie wrote:
The second was that I've found that the other spam-catching filtering
is doing a much better job than it was years ago and turning off
greylisting didn't adversely affect the amount of spa
On 1/19/11 2:35 PM, "John Hardin" wrote:
> On Wed, 19 Jan 2011, Daniel McDonald wrote:
>
>> On 1/19/11 10:17 AM, "John Hardin" wrote:
>>
>>> On Wed, 19 Jan 2011, Lee Dilkie wrote:
>>>
Don't get me wrong, I liked GL but there are a number of big ISPs that
have quite long retry tim
On Wed, 19 Jan 2011, Daniel McDonald wrote:
On 1/19/11 10:17 AM, "John Hardin" wrote:
On Wed, 19 Jan 2011, Lee Dilkie wrote:
Don't get me wrong, I liked GL but there are a number of big ISPs that
have quite long retry timeouts (for some reason, sympatico comes to
mind) and it got to be too
On 1/19/2011 8:06 AM, Lee Dilkie wrote:
On 1/19/2011 10:02 AM, David F. Skoll wrote:
On Wed, 19 Jan 2011 09:56:47 -0500
Lee Dilkie wrote:
The second was that I've found that the other spam-catching filtering
is doing a much better job than it was years ago and turning off
greylisting d
>>>> The legitimate mail that passes through my mail server comes from
>>>> hosts / networks I might not hear from again for months, by which
>>>> time I have to potentially wait 24 hours for the greylisting / mail
>>>> server to try again.
>>
On 1/19/2011 9:25 AM, Matt wrote:
The legitimate mail that passes through my mail server comes from
hosts / networks I might not hear from again for months, by which
time I have to potentially wait 24 hours for the greylisting / mail
server to try again.
I run greylisting on an email server
On Wed, Jan 19, 2011 at 11:14:29AM -0600, Daniel McDonald wrote:
> On 1/19/11 10:17 AM, "John Hardin" wrote:
>
> > On Wed, 19 Jan 2011, Lee Dilkie wrote:
> >
> >> Don't get me wrong, I liked GL but there are a number of big ISPs that
> >> have quite long retry timeouts (for some reason, sympatic
>> The legitimate mail that passes through my mail server comes from
>> hosts / networks I might not hear from again for months, by which
>> time I have to potentially wait 24 hours for the greylisting / mail
>> server to try again.
I run greylisting on an email server wit
o be too annoying.
>
> ...and when you encounter a big ISP that does this, do you notify their
> postmaster so they can fix the problem?
Or add a grey-listing exception and publish it to the sqlgrey list so that
the rest of us can also add an exception?
I seldom have problems with large m
On Wed, 19 Jan 2011, Lee Dilkie wrote:
Don't get me wrong, I liked GL but there are a number of big ISPs that
have quite long retry timeouts (for some reason, sympatico comes to
mind) and it got to be too annoying.
...and when you encounter a big ISP that does this, do you notify their
postm
On 1/19/2011 10:02 AM, David F. Skoll wrote:
> On Wed, 19 Jan 2011 09:56:47 -0500
> Lee Dilkie wrote:
>
>> The second was that I've found that the other spam-catching filtering
>> is doing a much better job than it was years ago and turning off
>> greylisting di
On Wed, 19 Jan 2011 09:56:47 -0500
Lee Dilkie wrote:
> The second was that I've found that the other spam-catching filtering
> is doing a much better job than it was years ago and turning off
> greylisting didn't adversely affect the amount of spam that got
> through.
Tha
I recently gave up on greylisting after using it for years as well.
Two reasons really, one was the complaints from users (and I found that
they often asked folks to "send mail to me twice" to try and get mail to
"work better" and that was just embarrassing).
The second was
t with 'Hi, how are you, did you receive my
mail?'.
User education can go a long way. One of our (very large) customers
filters mail for about 900 000 email addresses and uses greylisting.
They've obviously decided the benefits outweigh the costs.
[...]
I wish everyone, using greyl
rt with 'Hi , how are you, did you receive my
> mail?'.
User education can go a long way. One of our (very large) customers
filters mail for about 900 000 email addresses and uses greylisting.
They've obviously decided the benefits outweigh the costs.
[...]
> I wish everyone, using
r 3rd scanning head
uses a grey list system that is less granular /24 , this does not.
Ah, I should mention that we use a /24 for greylisting for IPv4 and a
/64 for IPv6. On the other hand, we also add a hash of the subject
into the greylisting tuple so it becomes:
I recently gave up entire
ow are you, did you receive my mail?'.
Can you document that 'Most retry within minutes'?
I analyzed 1655 machines from my logs that successfully passed greylisting.
The mean retry time was about 13000 seconds, or about 3.6 hours.
The standard deviation was high at 45000 seconds (12
st system that is less granular /24 , this does not.
Ah, I should mention that we use a /24 for greylisting for IPv4 and a
/64 for IPv6. On the other hand, we also add a hash of the subject
into the greylisting tuple so it becomes:
{sender_address, recipient_address, sender_ip/24, subject_hash}
0
Giles Coochey wrote:
The legitimate mail that passes through my mail server comes from
hosts / networks I might not hear from again for months, by which
time I have to potentially wait 24 hours for the greylisting / mail
server to try again.
My point is I've never encountered a client tha
before is delayed 30 minutes or even a couple of hours.
> Can you document that 'Most retry within minutes'?
I analyzed 1655 machines from my logs that successfully passed greylisting.
The mean retry time was about 13000 seconds, or about 3.6 hours.
The standard deviation was high at
On 1/18/11 4:58 PM, David F. Skoll wrote:
On Tue, 18 Jan 2011 16:55:42 +0100
Giles Coochey wrote:
The legitimate mail that passes through my mail server comes from
hosts / networks I might not hear from again for months, by which
time I have to potentially wait 24 hours for the greylisting
On Tue, 18 Jan 2011 16:55:42 +0100
Giles Coochey wrote:
> The legitimate mail that passes through my mail server comes from
> hosts / networks I might not hear from again for months, by which
> time I have to potentially wait 24 hours for the greylisting / mail
> server to try agai
On 12/27/10 4:07 PM, "David F. Skoll" wrote:
> On Mon, 27 Dec 2010 13:36:39 -0800
> Ted Mittelstaedt wrote:
>
>> The real question is, do you get viruses that would make it past SA?
>
> I can't answer that because we scan for viruses before SA. I would
> guess yes. It would be more efficient
ss that your
> LEGITIMATE mail is ALSO a tiny percentage of your total received
> mail. ;-)
No, not really. Here are the statistics for 30 days' worth of mail for
messages that made it past greylisting:
- About 600 000 non-spam messages
- About 530 000 spam or suspected-spam message
On 12/27/2010 12:42 PM, David F. Skoll wrote:
On Mon, 27 Dec 2010 12:37:00 -0800
Ted Mittelstaedt wrote:
greylisting, though, is by far the best. But I have noticed an
increasing number of sites out there - and this is large sites - who
apparently are honked-off that people greylist, and
On Mon, 27 Dec 2010 12:37:00 -0800
Ted Mittelstaedt wrote:
> greylisting, though, is by far the best. But I have noticed an
> increasing number of sites out there - and this is large sites - who
> apparently are honked-off that people greylist, and they will bounce
> delivery of
On 2010-04-01 19:06, Adam Katz wrote:
For what it's worth, I reconfigured my greylisting relay from a
blanket delay to delaying only spamcop neighbors, anything that hits a
DNSBL, and any Windows *desktop* (using p0f).
I once tried that, had had to refrain from it. The groupware s
Matt wrote:
> I wrote a perl script that whitelists any servers from greylisting for
> 6 months that send a message that scores less then 1 by spamassassin.
> If it later sends a message that scores greater then 5 it is removed
> from the whitelist. Works great. After having a f
> basis that there is little point continually greylisting servers
> that you *know* will retry anyway.
>
> This approach works extremely well and after a few weeks normal
> usage very few legitimate mails are delayed by greylisting.
My grey time is 35 days, which is effe
>> For what it's worth, I reconfigured my greylisting relay from a
>> blanket delay to delaying only spamcop neighbors, anything that hits a
>> DNSBL, and any Windows *desktop* (using p0f).
>>
>> The move reduced the fatal delay of 80-90% of my incoming m
Adam Katz wrote:
For what it's worth, I reconfigured my greylisting relay from a
blanket delay to delaying only spamcop neighbors, anything that hits a
DNSBL, and any Windows *desktop* (using p0f).
The move reduced the fatal delay of 80-90% of my incoming mail down to
64%, which is p
Adam Katz wrote:
> matching p0f's results with the (perl-compatible) regular expression
> /Windows (?:XP|2000(?!SP4)|Vista)/
> will safely block only desktops.
Oops, that lost a space after the "2000" part. That should read:
/Windows (?:XP|2000 (?!SP4)|Vista)/
Also note that p0f is curre
> On 2010-03-30 01:29, Brent Kennedy wrote:
>> Graylisting does work.
Jonas Eckerman wrote:
> I know it works. That's why I said I like it because it stops spam.
> Been using my own implementation for years.
For what it's worth, I reconfigured my greylisting rela
On May 26, 2009, at 4:00 AM, Arvid Picciani wrote:
does this list have an online archive?
Yes. Google it.
1 - 100 of 244 matches
Mail list logo
