Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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 ?

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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 spool a

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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: >>

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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 :)

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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 waiting

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

not 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, but it helps

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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 and H

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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 what I s

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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,

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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,

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

> 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

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

nly problem now is people still believe 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

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

On 2016-08-01 05:55, @lbutlr wrote: On 31 Jul 2016, at 01:06, Robert Schetterer <r...@sys4.de> 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

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

On 31 Jul 2016, at 01:06, Robert Schetterer <r...@sys4.de> 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 caus

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

5 +0200 >>>> Robert Schetterer <r...@sys4.de> 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 cha

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

ocal, 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 by spamasss

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

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 resol

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

ostfix 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 of server greylisting useless ,only filling up others queues waiting for a second slot ,so it may only

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

t..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 not for your partners Dont slow down communi

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

oes 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 secon

Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

ou 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 dont need to So what I didn't mention is that in our implementation, once

Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)

ter, 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

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

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 with each retry

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

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 use grey listing on our low volume server

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

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. If

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

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?

Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

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. Also, once a given IP passes

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

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 greylisting delays. Do you treat

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

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 caused

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

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. This catches ratware that retries in the face of greylisting, but mutates

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

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 40 days. If you have a large-enough user population

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

On Thu, 29 Nov 2012 21:27:19 +0100 Andrzej A. Filip andrzej.fi...@gmail.com 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 utter waste of time

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

On 11/29/2012 09:53 PM, David F. Skoll wrote: On Thu, 29 Nov 2012 21:27:19 +0100 Andrzej A. Filip andrzej.fi...@gmail.com 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

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

On Thu, 29 Nov 2012 21:59:45 +0100 Andrzej A. Filip andrzej.fi...@gmail.com 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, dcc or anything similar

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

. 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. Also, once a given IP passes greylisting, we remember that and we don't greylist

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

Just wondering how many boxes: rcpt domains: rcpt users: you guys are sending through greylisting. Axb

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

On Thu, 29 Nov 2012, David F. Skoll wrote: On Thu, 29 Nov 2012 21:27:19 +0100 Andrzej A. Filip andrzej.fi...@gmail.com 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

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

On Thu, 29 Nov 2012 22:47:45 +0100 Axb axb.li...@gmail.com 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

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

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've never seen any support for the theory

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

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. That's why it's useful

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

the 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 principle run all

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

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's why it's useful

Re: Greylisting (was Re: Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC ? Can I get your opinion?)

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 reject

greylisting

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 servers

Re: greylisting

On Tue, 17 May 2011 09:46:09 +0200 Per Jessen p...@computer.org 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, I do

Re: greylisting

David F. Skoll wrote: On Tue, 17 May 2011 09:46:09 +0200 Per Jessen p...@computer.org 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

Re: greylisting

On 5/17/2011 4:56 AM, Per Jessen wrote: David F. Skoll wrote: On Tue, 17 May 2011 09:46:09 +0200 Per Jessenp...@computer.org 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

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

On 19/01/11 15:02, David F. Skoll wrote: On Wed, 19 Jan 2011 09:56:47 -0500 Lee Dilkiel...@dilkie.com 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

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

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 least 2005

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

On Tue, 08 Feb 2011 15:47:12 + Steve Freegard st...@stevefreegard.com 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 doing

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

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. Our CanIt

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

On Tue, 08 Feb 2011 17:04:37 + Steve Freegard st...@stevefreegard.com 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

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

phone calls start with 'Hiname, 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

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

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 that I've found

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

On Wed, 19 Jan 2011 09:56:47 -0500 Lee Dilkie l...@dilkie.com 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. That's possibly

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

On 1/19/2011 10:02 AM, David F. Skoll wrote: On Wed, 19 Jan 2011 09:56:47 -0500 Lee Dilkie l...@dilkie.com 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

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

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

Re: Suspicious URL:Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

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 mailers. Most of my greylisting issues come

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

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 with several thousand email

Re: Suspicious URL:Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

On Wed, Jan 19, 2011 at 11:14:29AM -0600, Daniel McDonald wrote: On 1/19/11 10:17 AM, John Hardin jhar...@impsec.org 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,

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

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

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

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 with several thousand email

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

greylisting didn't adversely affect the amount of spam that got through. That's possibly true, but look at this. A greylisted message: mimedefang[17175]: p0I4xvRE017628: Filter time is 85ms A scanned message:mimedefang[17175]: p0I50ACP017683: Filter time is 906ms On a busy system, this can make

Re: Suspicious URL:Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

On Wed, 19 Jan 2011, Daniel McDonald wrote: On 1/19/11 10:17 AM, John Hardin jhar...@impsec.org 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

Re: Suspicious URL:Re: Suspicious URL:Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

On 1/19/11 2:35 PM, John Hardin jhar...@impsec.org wrote: On Wed, 19 Jan 2011, Daniel McDonald wrote: On 1/19/11 10:17 AM, John Hardin jhar...@impsec.org 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

Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

On Tue, 18 Jan 2011 16:55:42 +0100 Giles Coochey gi...@coochey.net 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

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

for the greylisting / mail server to try again. My point is I've never encountered a client that waits 24h to retry. Most retry within minutes and the longest I've seen is maybe 4h. RFC821/RFC2821/RFC5321 points out that a client has to wait a minimum of 30 minutes before a retry attempt should

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

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 45000 seconds (12.5

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

. Skoll wrote: On Tue, 18 Jan 2011 16:55:42 +0100 Giles Coocheygi...@coochey.net 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

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

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

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

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.5 hours

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

a day. Our 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

Re: Greylisting delay (was Re: Q about short-circuit over ruling blacklisting rule)

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 greylisting, would do what you did

Greylisting (was Re: Anti-Perl rant (was Re: Issuing rollback DBI Mysql))

On Mon, 27 Dec 2010 12:37:00 -0800 Ted Mittelstaedt t...@ipinc.net 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 mail

Re: Greylisting (was Re: Anti-Perl rant (was Re: Issuing rollback DBI Mysql))

On 12/27/2010 12:42 PM, David F. Skoll wrote: On Mon, 27 Dec 2010 12:37:00 -0800 Ted Mittelstaedtt...@ipinc.net 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

Re: Greylisting (was Re: Anti-Perl rant (was Re: Issuing rollback DBI Mysql))

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 messages - About 65 000 messages blocked

Re: Greylisting (was Re: Anti-Perl rant (was Re: Issuing rollback DBI Mysql))

On 12/27/10 4:07 PM, David F. Skoll d...@roaringpenguin.com wrote: On Mon, 27 Dec 2010 13:36:39 -0800 Ted Mittelstaedt t...@ipinc.net 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.

Re: on greylisting...

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 system

on greylisting...

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 relay from a blanket delay to delaying

Re: [SA] on greylisting...

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 currently

Re: on greylisting...

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 pretty

Re: on greylisting...

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 pretty reasonable given

Re: on greylisting...

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 effectively the same thing. By greylisting only

Re: on greylisting...

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 few months to learn

Re: opinions on greylisting and others

thanks for your responses. unfortunatly i lost all my local mail when my laptop exploded friday :( does this list have an online archive?

  1   2   3   >