Milter-greylist

racl whitelist spf pass
would do what you mentioned.
But the other feature you mentioned - i.e. greylisting to from+smtp_IP -
i.e. the some "light" version of the lazyaw option we have already would
be really cute.

Maybe already on Emmanuel's roadmap? :-)

I agree that even 10sec greylisting delay might be useful, but
definitely NOT with the lazyaw option. With the lazyaw option there is a
risk that the spammer who tries to send junk in a big amount, trying
systematically every recipient in your company will get eventually
autowhitelisted.

I certainly do now want to see autowhitelisted junk mails in my inbox.

Ondrej

Adam Katz wrote:
>
> > I have my greylisting set for 10 seconds and autowhitelisting for 30
> > days. The spammers who never try - well, they never retry. It doesn't
> > matter what the greylisting time is set for. Why needlessly delay the
> > MTAs that _are_ going to retry?
>
> What I'd really like to do is simplify the triplet ...
> so instead of "from@... <mailto:from%40sender.com> +
> smtp.sender.com + user@... <mailto:user%40greylisting.com>"
> we could have "[from] + smtp.sender.com"
> where "from" is only needed if sender.com has 4+ MX records
> (or some other simple check for a big company/service).
>
> I don't care about which of my users get the mail because my users are all
> aware of each other; the only case in which user@...
> <mailto:user%40greylisting.com> is of use
> is for a large-scale deployment like an ISP or university ... and even
> then, I might argue it's not worth the minimal gain, especially given
> other enterprise spam-fighting tools.
>
> Another potential feature would be to utilize SPF (though not blindly as
> the milter-greylist option does) in the following manner: if
> smtp.sender.com is listed in SPF, add all servers listed by SPF in the
> autowhitelisting. This would solve the issue created by redundant smtp
> servers (whose extreme case is exhibited by gmail as noted earlier).
>
> I unfortunately lack the time to help write such a modification :-(
>
> -Adam
>
>