Greylist after DATA

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Greylist after DATA

Anders-19
Hi.

We are currently running SQLgrey with good results, but sometimes delayed
mails can be an annoyance. Also, there is some concern about us not being
able to recover affected mails.

For these reasons, I would like to greylist only after DATA. This way, we
could have the rejected mails in a quarantine area. Also, we could
greylist only above some SpamAssassin threshold.

I know that this could be done with a before-queue content filter, but I
have not been able to find any. Is there some recommended tool for this
setup (Postfix friendly, obviously)?

Before I go writing my own, is the lack of such a tool due to it being a
really bad idea? We have sufficient bandwidth, CPU and disk resources for
this setup, but I read that there might also be some compatibility
problems with tempfail after DATA. I have, however, not been able to find
any real data on the size of this problem.


Thanks for any help,
Anders.


Reply | Threaded
Open this post in threaded view
|

Re: Greylist after DATA

Ramprasad-5

On Mon, 2008-05-26 at 14:44 +0200, Anders wrote:

> Hi.
>
> We are currently running SQLgrey with good results, but sometimes delayed
> mails can be an annoyance. Also, there is some concern about us not being
> able to recover affected mails.
>
> For these reasons, I would like to greylist only after DATA. This way, we
> could have the rejected mails in a quarantine area. Also, we could
> greylist only above some SpamAssassin threshold.
>

That is an awful lot of processing. If you run SA and find it spam, why
not simply reject the message, instead of greylisting.
In case of a FP atleast the sender comes to know immediately


In any case if you use greylisting , you should be ready for delays. If
delays are annoying you cant use greylisting. Anyway , from personal
experience I found greylisting putting in too much of delays especially
for last hosted setups




Reply | Threaded
Open this post in threaded view
|

Re: Greylist after DATA

Henrik K
On Mon, May 26, 2008 at 06:53:45PM +0530, ram wrote:

>
> On Mon, 2008-05-26 at 14:44 +0200, Anders wrote:
> > Hi.
> >
> > We are currently running SQLgrey with good results, but sometimes delayed
> > mails can be an annoyance. Also, there is some concern about us not being
> > able to recover affected mails.
> >
> > For these reasons, I would like to greylist only after DATA. This way, we
> > could have the rejected mails in a quarantine area. Also, we could
> > greylist only above some SpamAssassin threshold.
> >
>
> That is an awful lot of processing. If you run SA and find it spam, why
> not simply reject the message, instead of greylisting.
> In case of a FP atleast the sender comes to know immediately

What if it doesn't score enough to reject but is suspicious?

I think the most used software for this complex scenarios is MIMEDefang. You
can do a lot of other nice things at DATA stage. If you are up to the
coding.

> In any case if you use greylisting , you should be ready for delays. If
> delays are annoying you cant use greylisting. Anyway , from personal
> experience I found greylisting putting in too much of delays especially
> for last hosted setups

Haven't you heard of selective greylisting by now? You can greylist dynamic
looking clients, suspicious helos, medium SA scores, etc.. there is no need
to greylist legimate looking clients (smtp|mta|mx) or whitelisted ones in
dnswl.org etc.

If you don't have local copies of every big list like spamhaus, it is a
friendly gesture to greylist everything suspicious first to save traffic.

Reply | Threaded
Open this post in threaded view
|

Re: Greylist after DATA

mouss-2
In reply to this post by Anders-19
Anders wrote:
> Hi.
>
> We are currently running SQLgrey with good results, but sometimes delayed
> mails can be an annoyance.


do not greylist all mail. greylisting should be done selectively. also,
a client that successfully retries should be whitelisted forever.

when I see abusive greylisting, I "bounce" the message and whitelist the
client and domain. my server has better things to do.

and with:

$ host 77.75.163.100
100.163.75.77.in-addr.arpa domain name pointer
77.75.163.100.customers.telelet.dk.
$ host 77.75.163.100.customers.telelet.dk
Host 77.75.163.100.customers.telelet.dk not found: 3(NXDOMAIN)

you get a REJECT here (generic rDNS gets a reject_unknown_client among
other things).


>  Also, there is some concern about us not being
> able to recover affected mails.
>
> For these reasons, I would like to greylist only after DATA. This way, we
> could have the rejected mails in a quarantine area. Also, we could
> greylist only above some SpamAssassin threshold.
>
> I know that this could be done with a before-queue content filter, but I
> have not been able to find any. Is there some recommended tool for this
> setup (Postfix friendly, obviously)?
>
> Before I go writing my own, is the lack of such a tool due to it being a
> really bad idea? We have sufficient bandwidth, CPU and disk resources for
> this setup, but I read that there might also be some compatibility
> problems with tempfail after DATA. I have, however, not been able to find
> any real data on the size of this problem.
>
>  


what's the point? did you do measures that show how much spam you'll block?

Reply | Threaded
Open this post in threaded view
|

Re: Greylist after DATA

Anders-19
mouss wrote:

> Anders wrote:

>> We are currently running SQLgrey with good results, but sometimes
>> delayed mails can be an annoyance.
>
> do not greylist all mail. greylisting should be done selectively. also,
> a client that successfully retries should be whitelisted forever.

I know that. Indeed, my question was about how to do selective greylisting
after DATA. SQLgrey does auto-whitelisting.


> when I see abusive greylisting, I "bounce" the message and whitelist the
> client and domain. my server has better things to do.

This part makes no sense to me. If you can whitelist, you are the one
doing the abusive greylisting?


> $ host 77.75.163.100
> 100.163.75.77.in-addr.arpa domain name pointer
> 77.75.163.100.customers.telelet.dk.
> $ host 77.75.163.100.customers.telelet.dk
> Host 77.75.163.100.customers.telelet.dk not found: 3(NXDOMAIN)
>
> you get a REJECT here (generic rDNS gets a reject_unknown_client among
> other things).

How you choose to lose mail is your prerogative.


> what's the point? did you do measures that show how much spam you'll
> block?

The point is to have greylisting while still receiving most mail without
delay.

In particular, mails from web applications are annoying to wait for. Some
of these applications are not even retrying.


Cheers,
Anders.


Reply | Threaded
Open this post in threaded view
|

Re: Greylist after DATA

mouss-2
Anders wrote:

> [snip]
>> what's the point? did you do measures that show how much spam you'll
>> block?
>>    
>
> The point is to have greylisting while still receiving most mail without
> delay.
>
> In particular, mails from web applications are annoying to wait for. Some
> of these applications are not even retrying.
>
>  

then you probably need to hack sqlgrey. (of couse, if you know the IPs
the connections come from, then you can just whitelist the IPs, but I
guess you don't know...).