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:27 -0800, Gary Funck wrote:
> On 11/29/12 10:44:54, John Hardin wrote:
> > You will probably want to put a little effort into maintaining lists
> > of regular correspondents who can bypass greylisting. There may be
> > tools to automate that, e.g. to whitelist someone a loc
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.
>> You will probably want to put a little effort into maintaining lists
>> of regular correspondents who can bypass greylisting. There may be
>> tools to automate that, e.g. to whitelist someone a local user has
>> sent mail to.
>
> Has anyone looked into the use of a DNS-based white listing servic
>> 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 volum
On 11/29/12 10:44:54, John Hardin wrote:
> You will probably want to put a little effort into maintaining lists
> of regular correspondents who can bypass greylisting. There may be
> tools to automate that, e.g. to whitelist someone a local user has
> sent mail to.
Has anyone looked into the use o
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.
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 bas
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.
On Thu, 29 Nov 2012 18:01:38 -0800 (PST)
John Hardin wrote:
> It's not so much the host being blacklisted, as a checksum of the
> spam being published by pyzor et. al., or for spamvertised websites
> in the spam being published by URIBLs, so that when the sender tries
> again the score for that m
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
>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 the
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 to pass it in future and it's
Just wondering how many
boxes:
rcpt domains:
rcpt users:
you guys are sending through greylisting.
Axb
>> I've never had any
>> complaints about delivery speed, but some senders have broken mail
>> servers that don't retry on receiving a temporary 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
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, dcc or anything similar
so I have no perso
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,
> it's extremely likely to pass it in future
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 utter waste of
time to greylist it.
Regard
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
>>>
Am 29.11.2012 20:46, schrieb David F. Skoll:
> On Thu, 29 Nov 2012 14:36:45 -0500
> vec...@vectro.org wrote:
>
>> I've never had any
>> complaints about delivery speed, but some senders have broken mail
>> servers that don't retry on receiving a temporary failure.
>
> Many such servers use broken
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 by
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 trea
On 11/29/2012 12:01, Ned Slider wrote:
Indeed. But do also play around with the delays in postgrey (--delay).
A minimal delay of 60 seconds is enough to force a retry and is
adequate - legit hosts will retry, non-legit hosts won't so a longer
delay is generally unnecessary.
This is only one
I'll expand a little on John's comments below
On 29/11/12 18:44, John Hardin wrote:
On Thu, 29 Nov 2012, Ed Flecko wrote:
I'll be sure to check into Postgrey.
Are there any special considerations to installing/configuring it or
is it simply a matter of installing, reading the docs and configu
On Thu, 29 Nov 2012 14:36:45 -0500
vec...@vectro.org wrote:
> I've never had any
> complaints about delivery speed, but some senders have broken mail
> servers that don't retry on receiving a temporary failure.
Many such servers use broken SMTP implementations that can't handle
a 4xx code in resp
> From: "John Hardin"
> I fully agree. When I purchase an air-line ticket, I want the mail
> immediately in my inbox.
>
> If the greylisting software replies a "4xx Please come back in 299
> seconds",
> the truth is that you will have to wait an undetermined amount of time,
> depending on the send
From: "John Hardin"
Some users are extremely allergic to any delays in their email; you may
have to maintain a list of exception destination addresses to keep them
happy, or for addresses where no delay is acceptable, e.g.
or
I fully agree. When I purchase an air-line ticket, I want the
Good thoughts...thank you John.
Ed
On Thu, 29 Nov 2012, Ed Flecko wrote:
I'll be sure to check into Postgrey.
Are there any special considerations to installing/configuring it or
is it simply a matter of installing, reading the docs and configuring?
The biggest consideration is not technical, it's managing the expectations
of
Am 29.11.2012 17:04, schrieb Ed Flecko:
> Gentlemen,
> Thank you for your feedback!
>
> I'll be sure to check into Postgrey.
>
> Are there any special considerations to installing/configuring it or
> is it simply a matter of installing, reading the docs and configuring?
>
> Ed
>
yes dont do gr
Gentlemen,
Thank you for your feedback!
I'll be sure to check into Postgrey.
Are there any special considerations to installing/configuring it or
is it simply a matter of installing, reading the docs and configuring?
Ed
Ed,
> I'm looking to set up a spam filtering server to replace our ISP's
> spam filtering service.
>
> I've seen this tutorial (
> ftp://orn.mpg.de/pub/unix/mail/Fairly-Secure_Anti-SPAM_Gateway_Using_SpamAssassin.html#antivirus
> ) and I'd be very interested in YOUR opinion; do you think,
> fundam
On 28/11/12 23:32, Ed Flecko wrote:
I'm looking to set up a spam filtering server to replace our ISP's
spam filtering service.
I've seen this tutorial (
ftp://orn.mpg.de/pub/unix/mail/Fairly-Secure_Anti-SPAM_Gateway_Using_SpamAssassin.html#antivirus
) and I'd be very interested in YOUR opinion;
I'm looking to set up a spam filtering server to replace our ISP's
spam filtering service.
I've seen this tutorial (
ftp://orn.mpg.de/pub/unix/mail/Fairly-Secure_Anti-SPAM_Gateway_Using_SpamAssassin.html#antivirus
) and I'd be very interested in YOUR opinion; do you think,
fundamentally, a server
35 matches
Mail list logo