Milter-greylist

--- In milter-greylist@yahoogroups.com, Emmanuel Dreyfus <manu@...> wrote:
> So, what's the most-wanted-but-easy-to-implement features?
...
> More ideas? Opinions? Thoughts?


Hi.  I'm new to this list (subscription still pending) and new to
milter-greylist.  I did look around postings over the last 2 months,
and apologize if I'm raising something that has already been resolved,
but I didn't see anything exactly like this (but did see some close.)


The greylisting delay can hurt legitimate users, if they are part of
collaborative group. Milter-greylist has various features to permit
configured whitelisting, but it doesn't seem to have the one I'm think
would help my system:

Most of the people sending mail to that system are participating in
some (mailman-based) mailing lists.  They send from different
machines; even the same person does.  Worse, the membership of the
mailing lists varies over time.

This means that members of pre-approved communities -- by virtue of
their mailing list subscription -- are regularly having the postings
delayed.  In an active group discussion, having random postings show
up 30 minutes late can make a difference.

I am thinking that it would be good to have milter-greylist able to
query the membership of a mailing list and automatically accept mail
with an rfc2822.From header field address that is subscribed to the
destination mailing list.  This needs to be a dynamic query, in order
to guarantee that the subscription membership that is used is accurate.

Comments?

/Dave

> with an rfc2822.From header field address that is subscribed to the...
But that is a data stage, isn't it?
You can not do anything at the data stage but plain accept or hard fail.

Ondrej


Dave Crocker wrote:

>
> --- In milter-greylist@yahoogroups.com
> <mailto:milter-greylist%40yahoogroups.com>, Emmanuel Dreyfus
> <manu@...> wrote:
> > So, what's the most-wanted-but-easy-to-implement features?
> ...
> > More ideas? Opinions? Thoughts?
>
> Hi. I'm new to this list (subscription still pending) and new to
> milter-greylist. I did look around postings over the last 2 months,
> and apologize if I'm raising something that has already been resolved,
> but I didn't see anything exactly like this (but did see some close.)
>
> The greylisting delay can hurt legitimate users, if they are part of
> collaborative group. Milter-greylist has various features to permit
> configured whitelisting, but it doesn't seem to have the one I'm think
> would help my system:
>
> Most of the people sending mail to that system are participating in
> some (mailman-based) mailing lists. They send from different
> machines; even the same person does. Worse, the membership of the
> mailing lists varies over time.
>
> This means that members of pre-approved communities -- by virtue of
> their mailing list subscription -- are regularly having the postings
> delayed. In an active group discussion, having random postings show
> up 30 minutes late can make a difference.
>
> I am thinking that it would be good to have milter-greylist able to
> query the membership of a mailing list and automatically accept mail
> with an rfc2822.From header field address that is subscribed to the
> destination mailing list. This needs to be a dynamic query, in order
> to guarantee that the subscription membership that is used is accurate.
>
> Comments?
>
> /Dave
>
>

On Thu, Apr 10, 2008 at 7:32 AM, Dave Crocker <dhc2@...> wrote:
>  I am thinking that it would be good to have milter-greylist able to
>  query the membership of a mailing list and automatically accept mail
>  with an rfc2822.From header field address that is subscribed to the
>  destination mailing list.  This needs to be a dynamic query, in order
>  to guarantee that the subscription membership that is used is accurate.

Look at the urlcheck feature, you can implement pretty much anything with that.

-- 
/peter

On Thu, Apr 10, 2008 at 08:52:08AM +0200, Ondrej Valousek wrote:
> > with an rfc2822.From header field address that is subscribed to the...
> But that is a data stage, isn't it?
> You can not do anything at the data stage but plain accept or hard fail.

Well, this is just a limitation in milter-greylist: you could
do greylisting at DATA stage, but you would loose the abilitiy to
treat multiple recipients differently. And you would have to 
decide what to do with the following scenario:

First attempt: IP from A,B to D	
	-> tempfail, (IP, A, D) and (IP, B, D) are added to the greylist
Second attempt: IP from B,C to D	
	-> you should let B get through, but you should reject C ...

-- 
Emmanuel Dreyfus
manu@...

Well yes, That's a problem.
And besides: I do not think greylisting at the data is a wise thing anyway:
1. If you tempfail after data stage, the sender is more likely to treat
it as a permanent error
2. A lot more computing needed (you have to receive the whole message)

Once you are in the data stage, I would employ some spamassassin to
handle it.
Ondrej

Emmanuel Dreyfus wrote:

>
> On Thu, Apr 10, 2008 at 08:52:08AM +0200, Ondrej Valousek wrote:
> > > with an rfc2822.From header field address that is subscribed to the...
> > But that is a data stage, isn't it?
> > You can not do anything at the data stage but plain accept or hard fail.
>
> Well, this is just a limitation in milter-greylist: you could
> do greylisting at DATA stage, but you would loose the abilitiy to
> treat multiple recipients differently. And you would have to
> decide what to do with the following scenario:
>
> First attempt: IP from A,B to D
> -> tempfail, (IP, A, D) and (IP, B, D) are added to the greylist
> Second attempt: IP from B,C to D
> -> you should let B get through, but you should reject C ...
>
> -- 
> Emmanuel Dreyfus
> manu@... <mailto:manu%40netbsd.org>
>
>

Hi Dave, why don t you whitlist the mailinglist addreses? acl whitelist rcpt /.*@listserver .example .com/ or only some mailinglist acl whitelist rcpt